Листот сертификат валиден, ланецот истечен: прочитајте ја длабочината

Грешка за истек може да му припаѓа на издавач, а не на листот. Прочитајте ја длабочината на проверка и влезовите на доверба пред да обновите сертификат што сѐ уште изгледа актуелен.

Ги проверувате сертификатот на серверот, гледате дека на часовникот има уште месеци, а клиентот сѐ уште ја одбива врската со порака за истек. Датумот што го читате му припаѓа на листот, а жалбата може да е за нешто подлабоко во патеката. Проверката поминува низ ланец, и секој сертификат што ќе го избере оваа прошетка може да не успее во сопствениот прозорец на важност. Прочитајте кој не успеа пред да обновите нешто.

Длабочината го именува сертификатот што не успеа

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

Запишете го отпечатокот на неуспешниот сертификат заедно со неговиот subject, бидејќи различни сертификати можат да го носат истото име на 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 го печати изградениот ланец кога проверката успева, што е корисно за да се потврди дека патеката е онаа што ја намеривте. Кога таа не успева, задржете ја пријавената длабочина и subject; тие две полиња му кажуваат на следниот читател кој сертификат да го прегледа.

Ова не го прави тоа што не го прави — не ја репродуцира политиката на секој клиент. Pin, ограничување на целта или проверка на идентитет специфична за клиентот живее во клиентот, а не во оваа команда. Тоа се поставките што треба да се прегледаат кога проверката на серверот успева и врската сѐ уште не успева. Држете ги двете дијагнози одделени, инаку ќе обновите здрав сертификат додека бркате грешка со pinning.

Што докажува проверката и што испушта

Ова е проверка на патека и цел против датотека за доверба што ја доставивте. За проверка на име преку HTTPS, додајте го очекуваното име на домаќин преку соодветната опција; за VPN врска, задржете ги конфигурираните проверки на идентитет на клиентот и користете го материјалот за доверба што тој клиент навистина го чита.

Она што серверот го праќа е множество кандидати, а не патеката што вашиот клиент на крајот ќе ја изгради. Локалната доверба и правилата за градење на библиотеката и двете го обликуваат резултатот, затоа истиот одговор може да се провери на една машина и да не успее на друга. Споредете го одржуваното складиште на доверба и TLS имплементацијата на клиентот што не успева со оние на работен клиент пред да претпоставите идентична проценка. Разликата таму објаснува многу извештаи „само овој лаптоп не успева“.

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

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

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

Поправете ја патеката без да ја ослабнете проверката

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

Ракувањето со коренот заслужува забелешка, бидејќи резимеата често го преувеличуваат. RFC 5280 го третира сидрото како влез што стои надвор од предвидената патека, додека OpenSSL документира проверки на важност што го вклучуваат неговиот корен CA сертификат. Двете тврдења се точни за нивните сопствени системи; генерализирањето на однесувањето при истек на коренот од една библиотека на секој клиент дава уверени погрешни одговори.

По промената, присилете го засегнатиот клиент на нова автентикација и потврдете дека конкретната порака за истек ја нема. Обновете го листот само ако самиот лист е несоодветен. Оневозможувањето на проверките на време или враќањето на историски вкрстен сертификат не создава валидна тековна патека; само го одложува следниот неуспех.

Поврзани статии