Tilbakekalling av sertifikat feiler: hvilken vert kan ikke nå hva

Sertifikater kan ligge innenfor gyldighetsperioden mens VPN likevel rapporterer en autentiseringsfeil, og noen konkluderer med at sertifikatet er tilbakekalt. Det er tre forskjellige fakta. Tilbakekallingsdata må hentes av enheten som utfører valideringen, fra et publiseringsendepunkt som er navngitt inne i sertifikatet selv. Når den enheten ikke når endepunktet, feiler kontrollen av grunner som ikke har noe med sertifikatets status å gjøre.

Validereren eier hentestien

Begynn med å identifisere validereren. Når en laptop kontrollerer sertifikatet til gatewayen, er det laptopen som henter; når gatewayen kontrollerer et klientsertifikat, er det gatewayen som gjør det. En backend-autentiseringstjeneste kan legge til en tredje validerer med sin egen nettverksposisjon. Hver av dem har en annen rute til internett og en annen proxy-konfigurasjon. Bevis samlet inn på en administratørs arbeidsstasjon sier ingenting om en server inne i en DMZ.

Skriv ned sertifikatet, validereren, tidspunktet for forsøket og den nøyaktige statuskoden før du endrer noe.

Les publiseringsendepunktet fra sertifikatet

Sertifikatet angir hvor statusen ligger. Les disse feltene i stedet for å gjette en CA-adresse.

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ørste utvidelsen lister CRL-distribusjonspunkter, og den andre lister metoder for tilgang til utstederinformasjon, som kan dekke OCSP-status og henting av utstedersertifikat. Dette er forskjellige mekanismer, og en OCSP-responder er ikke en CRL-fil. Publiseringsverten er ofte en vanlig webserver og ikke CA-maskinen, fordi en frakoblet utsteder kan signere en CRL som en annen server distribuerer. En brannmurregel beskrevet som tilgang til CA-en er derfor for vag til å implementere eller gjennomgå.

Test henting fra enheten som validerer

Kjør hentetesten i miljøet som faktisk utfører valideringen, med godkjent sertifikatmateriale og uten private nøkler.

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

certutil-kjøringen verifiserer kjeden og rapporterer hvilke URL-hentinger som lyktes eller feilet, mens curl-kallet tester én publiseringsadresse fra samme vert og returnerer bare en statuskode. En mislykket henting fra en adresse som er tilgjengelig, peker på innholds- eller signaturproblemer; en tilkoblingsfeil peker på ruting, DNS eller proxy. Ta vare på begge resultatene, fordi én vellykket henting ikke beviser at hele kjeden er brukbar. Bytt ut eksempelverten og stien med distribusjonspunktet som ble funnet i sertifikatet.

Skill manglende data fra tilbakekalt status

Fire utfall ser like ut fra utsiden: endepunktet er utilgjengelig, listen er utdatert, listen er signert av feil utsteder, eller sertifikatet er virkelig tilbakekalt. Bare det siste er et statusresultat, og bare det rettferdiggjør å fjerne tilgang. Cache kompliserer bildet ytterligere, siden tidligere hentede data kan skjule en ødelagt publiseringssti frem til neste oppdatering. Å slå av tilbakekallingskontroll, slette ubeslektede sertifikater eller starte gatewayen på nytt erstatter aktivitet med en diagnose.

Etter rettelsen tvinger du frem en ny autentisering og bekrefter at den tiltenkte statushentingen lykkes. Der det finnes en kontrollert testidentitet, bekreft at den fortsatt avvises, fordi tilgjengelighet som fjerner kontrollen ikke er en reparasjon.