Вкрстено потпишана 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: држете ја старата патека на часовник за повлекување

Вкрстеното потпишување ја одржува старата патека на доверба жива по дизајн, што е и целта и ризикот. Тоа не санира компромитиран стар корен и не го отстранува тој корен од ниту еден клиент. Запишете кога старата патека престанува да дава доверба и потврдете дека тој ден навистина доаѓа.

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