Укрштено потписана CA: кључ се поклапа, AKI веза не

Два CA сертификата могу имати исти јавни кључ и исти subject и ипак не бити заменљиви. Један је самопотписан, други је укрштено потписао стари корен, и њихова имена издавача, серијски бројеви и потписи се разликују. Лист може да се повеже конкретно са једним од њих преко свог Authority Key Identifier. Та веза остаје невидљива док клијент не изабере погрешан ланац и handshake не пропадне без очигледног разлога.

Обавите ових пет провера по реду: свака искључује другачији отказ.

Провера 1: нацртајте оба ланца пре него што дотакнете шаблон

Запишите путање. Стара популација верује Старом корену A, који је издао CA B, која је издала лист сервера. Нова популација директно верује самопотписаној CA B. Оба B сертификата носе исти кључ и subject, и баш зато човек који чита ред subject види једну CA тамо где клијент види две.

Укрштено потписана копија такође мора бити прави CA сертификат, са basic constraints и key usage који дозвољавају потписивање.

Провера 2: упоредите поља AKI, не само кључ

Име издавача листа мора да одговара subject-у B, и тај део обично важи. Authority Key Identifier је место где се две копије разилазе, јер може да носи идентификатор кључа, издавача сертификата и серијски број. Идентификатор кључа одговара обема копијама, пошто је кључ идентичан. Поља издавач и серија одговарају тачно једној, и зато ланац који се гради према самопотписаној копији може да пропадне према укрштено потписаној.

Прегледајте лист уместо да нагађате: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Затим упоредите оба кандидата са openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", и исту наредбу према самопотписаној копији.

Ако лист носи издавача и серијски број, ланац употпуњује само сертификат који те вредности описују, коју год копију клијент учитао.

Провера 3: мењајте политику издавања, никад потписане бајтове

Проширења живе унутар потписа. Додавање, уклањање или уређивање једног на постојећем листу није поправка, то је други сертификат и захтева поновно издавање. Промена припада политици издавања: authorityKeyIdentifier = keyid,issuer:always чини да нови листови носе везу специфичну за сертификат, док само keyid задржава лабавији облик који одговара намерном прелазу на укрштено потписивање. Одлучите који ваша PKI жели пре него што се потпише следећа серија.

Уређивање заједничког шаблона мења и сваки будући сертификат, не само сервер пред вама.

Провера 4: проверите сваку популацију поверења одвојено

Тестирајте стару путању и нову путању као одвојена покретања. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem вежба укрштено потписану руту, а иста наредба са новим кореном и без untrusted датотеке вежба самопотписану руту. Мешање оба корена у један пакет крије који је ланац изабран. Затим поновите са правим клијентима, јер VPN backend може да преферира ланац или да причврсти сертификат на начине које openssl не чини.

Доставите посредни сертификат кроз конфигурацију услуге коју клијент заиста чита, а не кроз вики страницу.

Провера 5: држите стару путању на сату повлачења

Укрштено потписивање по дизајну одржава стару путању поверења живим, што је и циљ и ризик. Оно не санира компромитован стари корен и не уклања тај корен ни из једног клијента. Запишите када стара путања престаје да даје поверење и потврдите да тај дан заиста долази.

Ако сваки клијент може да прихвати нови корен пре него што се листови померају, једноставно увођење са двоструким поверењем је једноставније од укрштеног потписивања и оставља једну ствар мање за повлачење.