Intrekking van sertifikate misluk: watter gasheer wat nie kan bereik nie

Sertifikate kan binne hul geldigheidsvenster sit terwyl die VPN steeds 'n verifikasiefout rapporteer, en iemand maak die gevolgtrekking dat die sertifikaat ingetrek is. Dit is drie verskillende feite. Intrekkingsdata moet deur die toestel wat die validering doen, opgehaal word by 'n publikasie-eindpunt wat in die sertifikaat self genoem word. Wanneer daardie toestel nie die eindpunt kan bereik nie, misluk die kontrole om redes wat niks met die sertifikaat se status te doen het nie.

Die valideerder besit die ophaalroete

Begin deur die valideerder te identifiseer. Wanneer 'n skootrekenaar die gateway se sertifikaat kontroleer, doen die skootrekenaar die ophaling; wanneer die gateway 'n kliëntsertifikaat kontroleer, doen die gateway dit. 'n Verifikasiediens op die agtergrond kan 'n derde valideerder met sy eie netwerkposisie byvoeg. Elkeen het 'n ander roete na die internet en 'n ander proxy-konfigurasie. Bewyse wat op 'n administrateur se werkstasie ingesamel is, sê niks oor 'n bediener binne 'n DMZ nie.

Skryf die sertifikaat, die valideerder, die pogingstyd en die presiese statuskode neer voordat jy enigiets verander.

Lees die publikasie-eindpunt uit die sertifikaat

Die sertifikaat noem waar sy status woon. Lees daardie velde in plaas daarvan om 'n CA-adres te raai.

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

Die eerste uitbreiding lys CRL-verspreidingspunte, en die tweede lys metodes vir toegang tot gesag-inligting, wat OCSP-status en die ophaal van uitreiker-sertifikate kan dek. Dit is verskillende meganismes, en 'n OCSP-responder is nie 'n CRL-lêer nie. Die publikasiegasheer is dikwels 'n gewone webbediener eerder as die CA-masjien, want 'n aflyn uitreiker kan 'n CRL onderteken wat 'n ander bediener versprei. 'n Firewall-reël wat as toegang tot die CA beskryf word, is dus te vaag om te implementeer of te hersien.

Toets ophaling vanaf die toestel wat valideer

Voer die ophaaltoets uit in die omgewing wat werklik validering doen, met goedgekeurde sertifikaatmateriaal en geen private sleutels nie.

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

Die certutil-lopie verifieer die ketting en rapporteer watter URL-ophalings geslaag of misluk het, terwyl die curl-oproep een publikasie-adres vanaf dieselfde gasheer toets en slegs 'n statuskode teruggee. 'n Mislukte ophaling vanaf 'n bereikbare adres dui op inhoud- of handtekeningprobleme; 'n verbindingsfout dui op roetering, DNS of proxy. Hou albei resultate, want een suksesvolle ophaling bewys nie dat die hele ketting bruikbaar is nie. Verander die voorbeeldgasheer en -pad na die verspreidingspunt wat in die sertifikaat gevind is.

Skei ontbrekende data van ingetrekte status

Vier uitkomste lyk van buite dieselfde: die eindpunt is onbereikbaar, die lys is verouderd, die lys is deur die verkeerde uitreiker onderteken, of die sertifikaat is werklik ingetrek. Net die laaste een is 'n statusresultaat, en net dit regverdig die verwydering van toegang. Kasberging maak die prentjie verder ingewikkeld, want voorheen opgehaalde data kan 'n stukkende publikasieroete verberg tot die volgende verversing. Om intrekkingskontrole te deaktiveer, onverwante sertifikate te verwyder of die gateway te herbegin, vervang aktiwiteit vir 'n diagnose.

Nadat die fout reggemaak is, dwing 'n nuwe verifikasie af en bevestig dat die beoogde status-ophaling slaag. Waar 'n gekontroleerde toetsidentiteit bestaan, bevestig dat dit steeds verwerp word, want beskikbaarheid wat die kontrole verwyder, is nie 'n herstel nie.