Неподдържана цел на сертификата: защо междинният CA се проваля

Сертификатът на сървъра изглежда с правилна цел, ключът съвпада, датите са наред, а връзката все още се проваля с unsupported certificate purpose. Детайлът, който решава това, обикновено е на същия ред като грешката: стойност за дълбочина и субект, които посочват сертификат по-горе във веригата. Изпълняват се два различни теста и само единият от тях е за крайния сертификат. Сравняването им обяснява защо подмяната на сървърния сертификат не променя нищо.

Кой сертификат всъщност отхвърли проверяващият

Веригата не е един обект, повторен три пъти. Крайният сертификат носи името и ключа на сървъра, междинните го свързват с корен, а всеки има свой срок на валидност, ограничения и предназначения. Когато грешката посочва дълбочина, това число идентифицира позиция във веригата, която проверяващият е изградил, и тя може да не е позицията, която очаквате, ако сървърът изпраща неочаквана верига.

Четете полетата на сертификата на тази дълбочина, а не на сертификата, който сте приели за виновен. Поискайте двете разширения, които ограничават издаването, вместо да извеждате всички полета, защото отговорът почти винаги е в едно от тях. Изходът от разширенията е безопасен за споделяне; частните ключове — никога.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Ако посоченият сертификат е междинен, чието разширено използване на ключ споменава нещо несвързано с удостоверяването на TLS сървър, останалата част от неуспеха следва механично. Веригата не може да се използва за целта, която OpenVPN поиска.

Цел на крайния сертификат и политика на веригата са два теста

Тестът на крайния сертификат задава тесен въпрос: позволява ли този краен сертификат удостоверяване на сървър за това име? Тестът на веригата задава по-широк: може ли всеки сертификат в пътя да служи на тази цел? Сертификатен орган, на който е разрешено да издава само клиентски сертификати, ще премине собствените си проверки на подписа и пак ще се провали на втория тест, защото пътят, който разрешава, не включва целта, от която приложението се нуждае. Двата теста се провалят с едни и същи думи и имат напълно различни поправки.

Ето защо току-що издаден краен сертификат, правилен във всяко видимо поле, може да се провали веднага. Ето защо и поправката обикновено принадлежи на профила на издаващия орган, а не на конфигурацията на VPN.

Липсващ EKU не е ограничаващ EKU

RFC 5280 прави разширението за използване на ключ незадължително и, когато присъства, ограничаващо. Затова CA сертификат без разширението не е казал „не“ на удостоверяването на сървър, докато такъв, който изброява само несвързана цел, е казал нещо доста конкретно. Третирането на тези две състояния като еквивалентни дава грешна диагноза и, по-лошо, грешна поправка. Разграничението обяснява и защо два органа, които изглеждат еднакво в конзола, се държат напълно различно във верига.

Поведението на библиотеките тук също не е еднакво. Документът на OpenSSL за опциите за проверка описва собствената си обработка на проверките на целта за CA сертификати и тази обработка е политика на реализацията, а не правило, което всеки TLS стек следва по идентичен начин. Опишете какво прави вашият проверяващ и след това го потвърдете с версията, която действително използвате.

Възпроизведете неуспеха офлайн, преди да преиздавате

Офлайн проверката премахва приложението от въпроса. Ако веригата се проваля по същия начин при същата цел, проблемът е сертификатът и никаква сървърна конфигурация няма да го скрие. Ако веригата минава офлайн, а услугата все още отказва, приложението иска различна цел или използва различна верига от тестваната.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain е важен, защото отпечатва пътя, който инструментът е изградил, а той често не е редът на файловете, който сте подали. Този изход е най-бързият начин да откриете, че втори междинен сертификат се издърпва от хранилище за доверие, че сървърът изпраща кръстосано подписан вариант, който не сте предвидили, или че флагът за цел, копиран от урок, принадлежи на друга роля, различна от обслужваната.

Поправете политиката на издаване, а не извикването за проверка

Трайната поправка е междинен сертификат, издаден по политика, която разрешава целите, на които трябва да служи, с записано и прегледано ограничение. Добавянето на всяка цел към всеки орган не е политика; то премахва ограничението, което правеше разширението смислено, и обикновено надживява инцидента, който го предизвика. Кратка бележка в профила, описваща кои роли органът може да удостоверява, пречи следващото преиздаване да повтори същия спор.

Изключването на проверката е другата изкушаваща кратка пътека и превръща проблема със сертификат в проблем с доверие. Оставете проверката на целта на място, поправете веригата и изпълнете отново същата офлайн проверка, за да потвърдите, че пътят вече служи на предвидената роля, преди да докоснете услугата отново.