Odvolání certifikátu selhává: který host kam nedosáhne
Kontroly odvolání běží na zařízení, které ověřuje. Najděte distribuční bod CRL, otestujte dosažitelnost tohoto hostu a potom oddělte zastaralý seznam od odvolaného certifikátu.
Certifikáty mohou být uvnitř svého období platnosti, zatímco VPN stále hlásí selhání autentizace, a někdo usoudí, že certifikát je odvolán. To jsou tři různé skutečnosti. Data o odvolání musí stáhnout zařízení, které provádí ověření, z publikačního bodu uvedeného uvnitř samotného certifikátu. Když se toto zařízení k bodu nedostane, kontrola selže z důvodů nesouvisejících se stavem certifikátu.
Cestu k načtení vlastní ověřovatel
Začněte určením ověřovatele. Když notebook kontroluje certifikát brány, stahování provádí notebook; když brána kontroluje klientský certifikát, dělá to brána. Autentizační služba v back-endu může přidat třetího ověřovatele s vlastním síťovým umístěním. Každý má jinou trasu k internetu a jinou konfiguraci proxy. Důkazy shromážděné na pracovní stanici správce neříkají nic o serveru uvnitř DMZ.
Než cokoli změníte, zapište certifikát, ověřovatele, čas pokusu a přesný stavový kód.
Přečtěte si publikační bod z certifikátu
Certifikát uvádí, kde jeho stav sídlí. Čtěte tyto položky místo hádání adresy 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"První rozšíření vypisuje distribuční body CRL a druhé vypisuje metody přístupu k informacím o autoritě, které mohou pokrývat stav OCSP a načtení certifikátu vydavatele. To jsou různé mechanismy a odpovídač OCSP není soubor CRL. Publikační host bývá obyčejný webový server, nikoli stroj CA, protože offline vydavatel může podepsat CRL, který distribuuje jiný server. Proto je pravidlo firewallu popsané jako přístup k CA příliš vágní na to, aby se dalo implementovat nebo revidovat.
Otestujte načtení ze zařízení, které ověřuje
Proveďte test načtení v prostředí, které ověření skutečně provádí, se schváleným certifikátovým materiálem a bez soukromých klíčů.
certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crlSpuštění certutil ověří řetěz a oznámí, která načtení URL uspěla nebo selhala, zatímco volání curl testuje jednu publikační adresu ze stejného hostu a vrací pouze stavový kód. Neúspěšné načtení z dostupné adresy ukazuje na problémy s obsahem nebo podpisem; chyba připojení ukazuje na směrování, DNS nebo proxy. Uchovejte oba výsledky, protože jedno úspěšné načtení nedokazuje, že je celý řetěz použitelný. Změňte ukázkový host a cestu na distribuční bod nalezený v certifikátu.
Oddělte chybějící data od stavu odvolání
Čtyři výsledky vypadají zvenčí podobně: bod je nedostupný, seznam je zastaralý, seznam je podepsán nesprávným vydavatelem nebo je certifikát skutečně odvolán. Pouze poslední je stavový výsledek a pouze ten opravňuje odebrání přístupu. Ukládání do mezipaměti obraz dále komplikuje, protože dříve načtená data mohou skrývat nefunkční publikační cestu až do dalšího obnovení. Vypnutí kontroly odvolání, smazání nesouvisejících certifikátů nebo restart brány nahrazují diagnózu aktivitou.
Po opravě vynuťte novou autentizaci a potvrďte, že zamýšlené načtení stavu uspěje. Kde existuje kontrolovaná testovací identita, potvrďte, že je stále odmítána, protože dostupnost, která kontrolu odstraňuje, není oprava.