Отповикувањето сертификати не успева: кој домаќин до што не стигнува

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

Патот за преземање му припаѓа на валидаторот

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

Запишете ги сертификатот, валидаторот, времето на обидот и точниот статусен код пред да промените нешто.

Прочитајте ја точката за објавување од сертификатот

Сертификатот наведува каде живее неговиот статус. Читајте ги тие полиња наместо да погодувате адреса на CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

Првото проширување ги наведува точките за дистрибуција на CRL, а второто ги наведува методите за пристап до информациите за орган, кои можат да покријат статус преку OCSP и преземање на сертификатот на издавачот. Тоа се различни механизми, а одговорникот на OCSP не е датотека CRL. Домаќинот за објавување често е обичен веб-сервер, а не машината на CA, бидејќи издавачот што е офлајн може да потпише CRL што го дистрибуира друг сервер. Затоа правило на огнен ѕид опишано како пристап до CA е премногу нејасно за да се спроведе или прегледа.

Тестирајте го преземањето од уредот што валидира

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

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Извршувањето на certutil ја проверува веригата и известува кои преземања на URL успеале или не успеале, додека повикот на curl тестира една адреса за објавување од истиот домаќин и враќа само статусен код. Неуспешно преземање од достапна адреса укажува на проблеми со содржината или потписот; грешка при поврзување укажува на рутирање, DNS или прокси. Зачувајте ги двата резултати, бидејќи едно успешно преземање не докажува дека целата верига е употреблива. Заменете ги примерниот домаќин и патеката со точката за дистрибуција пронајдена во сертификатот.

Одвојте ги податоците што недостасуваат од статусот на отповикување

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

По поправката присилете нова автентикација и потврдете дека предвиденото преземање на статус успева. Каде што постои контролиран тест идентитет, потврдете дека тој сè уште се одбива, бидејќи достапноста што ја отстранува проверката не е поправка.