strongSwan send_cert: када се шаље IKE сертификат
send_cert одређује да ли peer шаље свој сертификат, док send_certreq тражи од друге стране да га пошаље. Проверите дневнике пре него што промените поверење примаоца.
Пролази бележе грешке провере аутентичности повезане са сертификатима, а први инстинкт је додати примаоцу још један CA. То претпоставља да је сертификат стигао и да је одбијен. Друга могућност је да никада није послат, а о томе одлучује политика везе пошиљаоца. Утврдите која се од те две ствари догодила пре него што промените поверење.
Чиме send_cert заправо управља
Провера аутентичности сертификатом захтева да сертификат крајњег ентитета друге стране стигне на другу страну кроз IKE размену или кроз претходно провизионисање. У swanctl поставка везе send_cert управља тиме да ли ова крајња тачка укључује свој сертификатни терет: никада, увек или ifasked. Подразумевано ifasked га шаље као одговор на захтев за сертификат од стране peera. Тражење сертификата је засебна поставка, јер тражити од друге стране њен сертификат није исто што и нудити сопствени.
Старије 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 приказује које су везе заиста успостављене. Дневник додаје детаље преговарања: да ли је примљен захтев за сертификат и да ли је сертификатни терет отишао. Општа грешка провере аутентичности не указује на проблем са доставом, зато потражите конкретну размену пре него што било шта закључите. Забележите временску ознаку покушаја како би прозор дневника покрио цело руковање.
Поверење примаоца је засебна одлука
Достава и поверење су различита својства, а решавање једног не решава друго. Прималац мора имати предвиђено сидро поверења, примити употребљив ланац и одговарати очекиваном идентитету peera. Сертификат крајњег ентитета који стигне без свог посредничког сертификата и даље пада на строгој провери ланца. Насупрот томе, инсталација CA нимало не присиљава peera да уопште пошаље свој сертификат.
openssl x509 -in peer-chain.pem -noout -subject -issuer -dates
Преглед показује који је издавалац потписао сертификат и када истиче, а томе мора одговарати сидро примаоца. Верујте издаваоцу CA који поседује инсталација, а не сваком посредничком сертификату у ланцу, јер подизање сваког посредничког сертификата у корен проширује поверење далеко изван једног peera. Оставите проверу идентитета активном, јер веза која успева само са искљученом валидацијом није поправка. Где је ланац непотпун, поправите провизионисање, а не политику пошиљаоца.
Мењајте пошиљаоца само са доказима
Када дневник покаже да сертификат никада није послат, а прималац га је заиста затражио, send_cert на always је оправдана промена за ту везу. Примените је у swanctl конфигурацији, поново учитајте везе и успоставите нову сесију уместо да поново користите постојећи SA. Потврдите да се сертификатни терет сада појављује и да га прималац прихвата према предвиђеном сидру. Ако се ништа не промени, грешка је ипак била на страни поверења и поставка пошиљаоца није била узрок.
Запишите уочену размену, сидро и резултујућу верификацију у запис о променама. Поправка сертификата која се не може описати тим појмовима је случајност.