Återkallelse av certifikat misslyckas: vilken värd som inte når vad

Certifikat kan ligga inom sin giltighetsperiod medan VPN ändå rapporterar ett autentiseringsfel, och någon drar slutsatsen att certifikatet är återkallat. Det är tre olika fakta. Återkallelsedata måste hämtas av enheten som utför valideringen, från en publiceringsslutpunkt som anges i certifikatet. När den enheten inte når slutpunkten misslyckas kontrollen av skäl som inte har med certifikatets status att göra.

Valideraren äger hämtningsvägen

Börja med att identifiera valideraren. När en bärbar dator kontrollerar gatewayens certifikat är det den bärbara datorn som hämtar; när gatewayen kontrollerar ett klientcertifikat gör gatewayen det. En autentiseringstjänst i bakgrunden kan lägga till en tredje validerare med egen nätverksposition. Var och en har en annan väg till internet och en annan proxykonfiguration. Bevis som samlats in på en administratörs arbetsstation säger ingenting om en server inne i en DMZ.

Skriv ned certifikatet, valideraren, tidpunkten för försöket och den exakta statuskoden innan du ändrar något.

Läs publiceringsslutpunkten från certifikatet

Certifikatet anger var dess status finns. Läs dessa fält i stället för att gissa en CA-adress.

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

Den första utökningen listar CRL-distributionspunkter och den andra listar metoder för åtkomst till utgivarinformation, som kan omfatta OCSP-status och hämtning av utgivarcertifikat. Det är olika mekanismer, och en OCSP-svarare är inte en CRL-fil. Publiceringsvärden är ofta en vanlig webbserver och inte CA-maskinen, eftersom en offline-utgivare kan signera en CRL som en annan server distribuerar. En brandväggsregel som beskrivs som åtkomst till CA är därför för vag för att implementera eller granska.

Testa hämtning från enheten som validerar

Kör hämtningstestet i den miljö som faktiskt utför valideringen, med godkänt certifikatmaterial och utan privata nycklar.

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

Körningen av certutil verifierar kedjan och rapporterar vilka URL-hämtningar som lyckades eller misslyckades, medan curl-anropet testar en publiceringsadress från samma värd och returnerar bara en statuskod. En misslyckad hämtning från en nåbar adress pekar på problem med innehåll eller signatur; ett anslutningsfel pekar på routing, DNS eller proxy. Spara båda resultaten, eftersom en lyckad hämtning inte bevisar att hela kedjan är användbar. Byt ut exempelvärden och sökvägen mot den distributionspunkt som hittades i certifikatet.

Skilj saknade data från återkallad status

Fyra utfall ser likadana ut utifrån: slutpunkten går inte att nå, listan är inaktuell, listan är signerad av fel utgivare eller certifikatet är verkligen återkallat. Bara det sista är ett statusresultat, och bara det motiverar att åtkomsten tas bort. Cachelagring komplicerar bilden ytterligare, eftersom tidigare hämtade data kan dölja en trasig publiceringsväg fram till nästa uppdatering. Att stänga av återkallelsekontrollen, radera orelaterade certifikat eller starta om gatewayen ersätter en diagnos med aktivitet.

Efter åtgärden tvingar du fram en ny autentisering och bekräftar att den avsedda statushämtningen lyckas. Där en kontrollerad testidentitet finns, bekräfta att den fortfarande avvisas, eftersom tillgänglighet som tar bort kontrollen inte är en reparation.