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. Потврдете дека сертификатниот товар сега се појавува и дека примачот го прифаќа кон предвиденото сидро. Ако ништо не се промени, грешката сепак била на страната на довербата и поставката на праќачот не била причината.

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