Кръстосано подписан CA: ключът съвпада, обвързването по AKI — не

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

Изпълнете тези пет проверки по ред: всяка от тях изключва различен отказ.

Проверка 1: начертайте двете вериги, преди да пипате шаблона

Запишете пътищата. Старата популация се доверява на Стар корен A, който е издал CA B, който е издал листа на сървъра. Новата популация се доверява директно на самоподписания CA B. И двата сертификата B носят един и същ ключ и субект, поради което човек, който чете реда на субекта, вижда един CA там, където клиентът вижда два.

Кръстосано подписаното копие също трябва да е истински CA сертификат, с basic constraints и key usage, които позволяват подписване.

Проверка 2: сравнете полетата на AKI, а не само ключа

Името на издателя на листа трябва да съвпада със субекта на 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 бекенд може да предпочете верига или да закачи сертификат по начини, които openssl не прави.

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

Проверка 5: дръжте стария път на часовник за извеждане от експлоатация

Кръстосаното подписване пази стар път на доверие жив по замисъл, което е едновременно смисълът и рискът. То не отстранява компрометиран стар корен и не премахва този корен от нито един клиент. Запишете кога старият път спира да дава доверие и потвърдете, че този ден наистина идва.

Ако всеки клиент може да приеме новия корен, преди листовете да се преместят, обикновеното внедряване с двойно доверие е по-просто от кръстосаното подписване и оставя едно нещо по-малко за извеждане.