La revocació de certificats falla: quin amfitrió no arriba a què

Els certificats poden estar dins de la seva finestra de validesa mentre la VPN encara informa d'una fallada d'autenticació, i algú conclou que el certificat està revocat. Són tres fets diferents. Les dades de revocació les ha d'obtenir el dispositiu que fa la validació, des d'un punt de publicació indicat dins del mateix certificat. Quan aquest dispositiu no pot arribar al punt, la comprovació falla per motius que no tenen res a veure amb l'estat del certificat.

El validador és qui fa la descàrrega

Comenceu identificant el validador. Quan un portàtil comprova el certificat de la passarel·la, la descàrrega la fa el portàtil; quan la passarel·la comprova un certificat de client, la fa la passarel·la. Un servei d'autenticació de fons pot afegir un tercer validador amb la seva pròpia posició de xarxa. Cadascun té una ruta diferent a internet i una configuració de proxy diferent. Les proves recollides a l'estació de treball de l'administrador no diuen res sobre un servidor dins d'una DMZ.

Anoteu el certificat, el validador, l'hora de l'intent i el codi d'estat exacte abans de canviar res.

Llegiu el punt de publicació del certificat

El certificat indica on viu el seu estat. Llegiu aquests camps en lloc d'endevinar una adreça de 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"

La primera extensió llista punts de distribució de CRL, i la segona llista mètodes d'accés a la informació de l'autoritat, que poden cobrir l'estat OCSP i l'obtenció del certificat emissor. Són mecanismes diferents, i un responedor OCSP no és un fitxer CRL. L'amfitrió de publicació sovint és un servidor web normal i no la màquina de la CA, perquè un emissor fora de línia pot signar una CRL que distribueix un altre servidor. Per tant, una regla de tallafoc descrita com a accés a la CA és massa vaga per implementar-la o revisar-la.

Proveu la descàrrega des del dispositiu que valida

Executeu la prova de descàrrega a l'entorn que realment fa la validació, amb material de certificat aprovat i sense claus privades.

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

L'execució de certutil verifica la cadena i informa quines descàrregues d'URL han reeixit o fallat, mentre que la crida curl prova una adreça de publicació des del mateix amfitrió i només retorna un codi d'estat. Una descàrrega fallida des d'una adreça accessible apunta a problemes de contingut o de signatura; un error de connexió apunta a encaminament, DNS o proxy. Conserveu tots dos resultats, perquè una descàrrega correcta no demostra que tota la cadena sigui utilitzable. Canvieu l'amfitrió i el camí de l'exemple pel punt de distribució trobat al certificat.

Separeu les dades absents de l'estat revocat

Quatre resultats semblen iguals des de fora: el punt no és accessible, la llista és obsoleta, la llista està signada per l'emissor equivocat o el certificat realment està revocat. Només l'últim és un resultat d'estat, i només aquest justifica retirar l'accés. La memòria cau complica encara més el panorama, perquè les dades obtingudes abans poden amagar una ruta de publicació trencada fins al següent refresc. Desactivar la comprovació de revocació, esborrar certificats no relacionats o reiniciar la passarel·la substitueixen el diagnòstic per activitat.

Després de la correcció, forceu una autenticació nova i confirmeu que la descàrrega d'estat prevista té èxit. On hi hagi una identitat de prova controlada, confirmeu que encara es rebutja, perquè una disponibilitat que elimina la comprovació no és una reparació.