Листовият сертификат е валиден, веригата е изтекла: прочетете дълбочината

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

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

Дълбочината назовава сертификата, който се е провалил

В диагностиката на OpenSSL дълбочина 0 е целевият сертификат, а дълбочина 1 е издателят, който го е подписал; по-високите числа продължават към котвата за доверие. Изтекъл срок, отчетен на дълбочина 1, не се опровергава от текущ notAfter на листа, затова повторната проверка на видимия сертификат никога няма да обясни грешката.

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

Внимавайте и за продукти с повече от една роля на сертификата. В OpenVPN Access Server сертификатите, които защитават уеб интерфейсите, са отделни от тези за VPN връзки, така че браузър, който отваря администраторската страница, не доказва нищо за пътя на тунела.

Входните данни за доверие не са същото като кандидатите за веригата

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

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Изключването на пътя и хранилището по подразбиране с -no-CApath -no-CAstore прави теста честен: резултатът тогава зависи от файловете, които сте посочили, а не от това, на което работната станция случайно се доверява. Справочникът за проверка на OpenSSL документира тези опции и диагностиката, която те произвеждат.

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

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

Какво доказва проверката и какво пропуска

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

Това, което сървърът изпраща, е набор от кандидати, а не пътят, който вашият клиент накрая ще изгради. Локалното доверие и правилата за изграждане на библиотеката оформят резултата, затова един и същ отговор може да се провери на една машина и да се провали на друга. Сравнете поддържаното хранилище за доверие и TLS реализацията на неуспелия клиент с тези на работещ клиент, преди да приемете идентична оценка. Разлика там обяснява много доклади „само този лаптоп се проваля“.

За да видите прозореца на всеки сертификат, вместо един по един, отпечатайте ги като набор:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

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

Поправете пътя, без да отслабвате проверката

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

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

След промяната принудете засегнатия клиент да направи нова автентикация и потвърдете, че конкретното съобщение за изтекъл срок е изчезнало. Подновете листа само ако самият лист е неподходящ. Изключването на проверките за време или възстановяването на исторически кръстосан сертификат не създава валиден текущ път; то само отлага следващия провал.

Подобни статии