Revocarea certificatelor eșuează: ce gazdă nu ajunge unde

Certificatele pot sta în interiorul ferestrei de valabilitate în timp ce VPN-ul tot raportează o eroare de autentificare, iar cineva concluzionează că certificatul este revocat. Sunt trei fapte diferite. Datele de revocare trebuie aduse de dispozitivul care face validarea, de la un punct de publicare numit în interiorul certificatului. Când acel dispozitiv nu ajunge la punct, verificarea eșuează din motive fără legătură cu starea certificatului.

Validatorul deține calea de aducere

Începeți prin a identifica validatorul. Când un laptop verifică certificatul gateway-ului, laptopul face aducerea; când gateway-ul verifică un certificat de client, gateway-ul o face. Un serviciu de autentificare din back-end poate adăuga un al treilea validator cu propria poziție în rețea. Fiecare are o rută diferită către internet și o configurație de proxy diferită. Dovezile adunate pe stația de lucru a unui administrator nu spun nimic despre un server dintr-o DMZ.

Notați certificatul, validatorul, momentul încercării și codul exact de stare înainte de a schimba ceva.

Citiți punctul de publicare din certificat

Certificatul numește unde se află starea lui. Citiți acele câmpuri în loc să ghiciți o adresă 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"

Prima extensie listează puncte de distribuție CRL, iar a doua listează metode de acces la informațiile emitentului, care pot acoperi starea OCSP și aducerea certificatului emitentului. Sunt mecanisme diferite, iar un respondent OCSP nu este un fișier CRL. Gazda de publicare este adesea un server web obișnuit, nu mașina CA, pentru că un emitent offline poate semna o CRL pe care o distribuie alt server. O regulă de firewall descrisă ca acces la CA este deci prea vagă pentru a fi implementată sau evaluată.

Testați aducerea de pe dispozitivul care validează

Rulați testul de aducere în mediul care face efectiv validarea, cu material de certificat aprobat și fără chei private.

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

Rularea certutil verifică lanțul și raportează ce aduceri de URL au reușit sau au eșuat, în timp ce apelul curl testează o singură adresă de publicare de pe aceeași gazdă și întoarce doar un cod de stare. O aducere eșuată de la o adresă accesibilă indică probleme de conținut sau de semnătură; o eroare de conexiune indică rutare, DNS sau proxy. Păstrați ambele rezultate, pentru că o aducere reușită nu dovedește că întregul lanț este utilizabil. Înlocuiți gazda și calea din exemplu cu punctul de distribuție găsit în certificat.

Separați datele lipsă de starea revocată

Patru rezultate arată la fel din exterior: punctul este inaccesibil, lista este veche, lista este semnată de emitentul greșit sau certificatul este într-adevăr revocat. Doar ultimul este un rezultat de stare și doar el justifică retragerea accesului. Cache-ul complică și mai mult imaginea, fiindcă datele aduse anterior pot ascunde o cale de publicare ruptă până la următoarea reîmprospătare. Dezactivarea verificării revocării, ștergerea certificatelor nelegate sau repornirea gateway-ului înlocuiesc diagnosticul cu activitate.

După remediere, forțați o autentificare nouă și confirmați că aducerea de stare dorită reușește. Unde există o identitate de test controlată, confirmați că este încă respinsă, fiindcă disponibilitatea care elimină verificarea nu este o reparare.