Tilbakekalling av sertifikat feilar: kva vert kan ikkje nå kva

Sertifikat kan ligge innanfor gyldigheitsperioden medan VPN likevel rapporterer ein autentiseringsfeil, og nokon konkluderer med at sertifikatet er tilbakekalla. Det er tre ulike faktum. Tilbakekallingsdata må hentast av eininga som gjer valideringa, frå eit publiseringsendepunkt som er namngjeve inne i sertifikatet sjølv. Når den eininga ikkje når endepunktet, feilar kontrollen av grunnar som ikkje har noko med statusen til sertifikatet å gjere.

Validatora eig hentestien

Byrja med å identifisere validatora. Når ein laptop kontrollerer sertifikatet til gatewayen, er det laptopen som hentar; når gatewayen kontrollerer eit klientsertifikat, er det gatewayen som gjer det. Ein backend-autentiseringsteneste kan leggje til ein tredje validator med sin eigen nettverksposisjon. Kvar av dei har ei anna rute til internett og ein annan proxy-konfigurasjon. Prov samla inn på arbeidsstasjonen til ein administrator seier ingenting om ein tenar inne i ein DMZ.

Skriv ned sertifikatet, validatora, tidspunktet for forsøket og den nøyaktige statuskoden før du endrar noko.

Les publiseringsendepunktet frå sertifikatet

Sertifikatet oppgir kvar statusen ligg. Les desse felta i staden for å gjette ei 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 utvidinga listar CRL-distribusjonspunkt, og den andre listar metodar for tilgang til utvidarinformasjon, som kan dekkje OCSP-status og henting av utvidarsertifikat. Dette er ulike mekanismar, og ein OCSP-svarar er ikkje ei CRL-fil. Publiseringsverten er ofte ein vanleg webserver og ikkje CA-maskina, fordi ein fråkopla utvidar kan signere ei CRL som ein annan tenar distribuerer. Ein brannmurregel som er skildra som tilgang til CA-en, er derfor for vag til å implementere eller gjennomgå.

Test henting frå eininga som validerer

Køyr hentetesten i miljøet som faktisk gjer valideringa, med godkjent sertifikatmateriale og utan private nøklar.

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

certutil-køyringa stadfester kjeda og rapporterer kva URL-hentingar som lukkast eller feila, medan curl-kallet testar éi publiseringsadresse frå same vert og returnerer berre ein statuskode. Ei mislukka henting frå ei adresse som er tilgjengeleg, peikar på innhalds- eller signaturproblem; ein tilkoplingsfeil peikar på ruting, DNS eller proxy. Ta vare på begge resultata, fordi éi vellukka henting ikkje beviser at heile kjeda er brukbar. Bytt ut eksempelverten og stien med distribusjonspunktet som vart funne i sertifikatet.

Skil manglande data frå tilbakekalla status

Fire utfall ser like ut frå utsida: endepunktet er utilgjengeleg, lista er utdatert, lista er signert av feil utvidar, eller sertifikatet er verkeleg tilbakekalla. Berre det siste er eit statusresultat, og berre det rettferdiggjer å fjerne tilgang. Cache gjer biletet endå meir komplisert, sidan tidlegare henta data kan skjule ein øydelagd publiseringssti fram til neste oppdatering. Å slå av tilbakekallingskontroll, slette urelaterte sertifikat eller starte gatewayen på nytt erstattar aktivitet med ein diagnose.

Etter rettinga tvingar du fram ein ny autentisering og stadfester at den tiltenkte statushentinga lukkast. Der det finst ein kontrollert testidentitet, stadfest at han framleis vert avvist, fordi tilgjenge som fjernar kontrollen ikkje er ein reparasjon.