Intrekking van certificaten mislukt: welke host kan wat niet bereiken

Certificaten kunnen binnen hun geldigheidsperiode staan terwijl de VPN toch een authenticatiefout meldt, en iemand concludeert dat het certificaat is ingetrokken. Dat zijn drie verschillende feiten. Intrekkingsgegevens moeten worden opgehaald door het apparaat dat de validatie uitvoert, van een publicatie-eindpunt dat in het certificaat zelf staat. Als dat apparaat het eindpunt niet kan bereiken, mislukt de controle om redenen die niets met de status van het certificaat te maken hebben.

De validator bezit het ophaalpad

Begin met het vaststellen van de validator. Als een laptop het certificaat van de gateway controleert, haalt de laptop de gegevens op; als de gateway een clientcertificaat controleert, doet de gateway dat. Een back-end-authenticatiedienst kan een derde validator toevoegen met een eigen netwerkpositie. Elk heeft een andere route naar internet en een andere proxyconfiguratie. Bewijs dat op de werkplek van een beheerder is verzameld, zegt niets over een server in een DMZ.

Noteer het certificaat, de validator, het tijdstip van de poging en de exacte statuscode voordat je iets wijzigt.

Lees het publicatie-eindpunt uit het certificaat

Het certificaat noemt waar de status staat. Lees die velden in plaats van een CA-adres te raden.

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

De eerste extensie noemt CRL-distributiepunten en de tweede noemt methoden voor toegang tot uitgeverinformatie, die de OCSP-status en het ophalen van het uitgevercertificaat kunnen omvatten. Dat zijn verschillende mechanismen, en een OCSP-responder is geen CRL-bestand. De publicatiehost is vaak een gewone webserver en niet de CA-machine, omdat een offline uitgever een CRL kan ondertekenen die een andere server verspreidt. Een firewallregel die wordt beschreven als toegang tot de CA is daarom te vaag om te implementeren of te beoordelen.

Test het ophalen vanaf het apparaat dat valideert

Voer de ophaaltest uit in de omgeving die daadwerkelijk valideert, met goedgekeurd certificaatmateriaal en zonder prive-sleutels.

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

De certutil-run verifieert de keten en meldt welke URL-ophalingen zijn geslaagd of mislukt, terwijl de curl-aanroep een publicatieadres vanaf dezelfde host test en alleen een statuscode teruggeeft. Een mislukte ophaling vanaf een bereikbaar adres wijst op inhouds- of handtekeningproblemen; een verbindingsfout wijst op routering, DNS of proxy. Bewaar beide resultaten, want een geslaagde ophaling bewijst niet dat de hele keten bruikbaar is. Vervang de voorbeeldhost en het pad door het distributiepunt dat in het certificaat is gevonden.

Onderscheid ontbrekende gegevens van ingetrokken status

Vier uitkomsten lijken van buitenaf op elkaar: het eindpunt is onbereikbaar, de lijst is verouderd, de lijst is ondertekend door de verkeerde uitgever, of het certificaat is echt ingetrokken. Alleen de laatste is een statusresultaat, en alleen die rechtvaardigt het intrekken van toegang. Caching maakt het beeld nog ingewikkelder, omdat eerder opgehaalde gegevens een kapot publicatiepad kunnen verbergen tot de volgende verversing. Het uitschakelen van de intrekkingscontrole, het verwijderen van niet-verwante certificaten of het herstarten van de gateway vervangen een diagnose door activiteit.

Forceer na de reparatie een nieuwe authenticatie en bevestig dat het bedoelde statusophalen slaagt. Waar een gecontroleerde testidentiteit bestaat, bevestig dat die nog steeds wordt geweigerd, want beschikbaarheid die de controle wegneemt is geen herstel.