strongSwan send_cert: кога се изпраща IKE сертификатът

Шлюзовете записват грешки при удостоверяване, свързани със сертификати, и първият инстинкт е да се добави още един CA към получателя. Това предполага, че сертификатът е пристигнал и е бил отхвърлен. Другата възможност е никога да не е бил изпратен, а това определя политиката за връзка на изпращача. Установете кой от двата случая се е случил, преди да промените доверието.

Какво всъщност управлява send_cert

Удостоверяването със сертификат изисква сертификатът на крайния обект на отсрещната страна да достигне до нея чрез IKE обмена или чрез предварително осигуряване. В swanctl настройката за връзка send_cert управлява дали тази крайна точка включва своя сертификатен товар: никога, винаги или ifasked. Стойността по подразбиране ifasked го изпраща в отговор на заявка за сертификат от peer-а. Заявката за сертификат е отделна настройка, защото да поискате от другата страна нейния сертификат не е същото като да предложите своя.

По-старите инсталации с ipsec.conf използваха leftsendcert и rightsendcert, а тези имена съответстват на локални и отдалечени роли, а не директно на swanctl.

Прочетете един опит, преди да промените връзката

Диагностицирайте от един контролиран опит, а не от общото впечатление, че участват сертификати. И политиката, и активната асоциация могат да бъдат прегледани.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Списъкът с връзки показва конфигурираната стойност send_cert, а списъкът със SA показва кои връзки действително са установени. Дневникът добавя подробности за преговорите: дали е получена заявка за сертификат и дали е изпратен сертификатен товар. Общата грешка при удостоверяване не показва проблем с доставянето, затова потърсете конкретния обмен, преди да заключите нещо. Запишете времевия отпечатък на опита, за да обхване прозорецът на дневника цялото ръкостискане.

Доверието на получателя е отделно решение

Доставянето и доверието са различни свойства и отстраняването на едното не отстранява другото. Получателят трябва да притежава предвидената котва на доверие, да получи използваема верига и да отговаря на очакваната идентичност на peer-а. Сертификат на краен обект, който пристига без своя междинен сертификат, все още се проваля при строга проверка на веригата. Обратно, инсталирането на CA изобщо не принуждава peer-а да изпрати своя сертификат.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Прегледът показва кой издател е подписал сертификата и кога изтича, и на това трябва да отговаря котвата на получателя. Доверете се на издаващия CA, който инсталацията притежава, а не на всеки междинен сертификат във веригата, защото повишаването на всеки междинен сертификат до корен разширява доверието далеч отвъд един peer. Оставете проверката на идентичността активна, защото връзка, която успява само с изключена валидация, не е поправка. Където веригата е непълна, поправете осигуряването, а не политиката на изпращача.

Променяйте изпращача само с доказателства

Когато дневникът показва, че сертификатът никога не е бил изпратен, а получателят наистина го е поискал, send_cert на always е оправдана промяна за тази връзка. Приложете я в конфигурацията на swanctl, презаредете връзките и установете нова сесия, вместо да използвате отново съществуващия SA. Потвърдете, че сертификатният товар вече се появява и че получателят го приема спрямо предвидената котва. Ако нищо не се промени, грешката все пак е била от страната на доверието и настройката на изпращача не е била причината.

Запишете наблюдавания обмен, котвата и произтичащата верификация в записа за промени. Поправка на сертификат, която не може да се опише с тези понятия, е случайност.