Tilbagekaldelse af certifikater fejler: hvilken vært der ikke kan nå hvad

Certifikater kan ligge inden for deres gyldighedsperiode, mens VPN stadig rapporterer en godkendelsesfejl, og nogen konkluderer, at certifikatet er tilbagekaldt. Det er tre forskellige fakta. Tilbagekaldelsesdata skal hentes af den enhed, der udfører valideringen, fra et publiceringsendepunkt, der er nævnt inde i certifikatet selv. Når den enhed ikke kan nå endepunktet, fejler kontrollen af grunde, der intet har med certifikatets status at gøre.

Valideringen ejer hentestien

Begynd med at identificere valideringen. Når en bærbar computer kontrollerer gatewayens certifikat, er det den bærbare, der henter; når gatewayen kontrollerer et klientcertifikat, er det gatewayen, der gør det. En godkendelsestjeneste i baggrunden kan tilføje en tredje validator med sin egen netværksposition. Hver har en anden rute til internettet og en anden proxykonfiguration. Beviser indsamlet på en administratorkonto siger intet om en server inde i en DMZ.

Skriv certifikatet, valideringen, forsøgstidspunktet og den præcise statuskode ned, før du ændrer noget.

Læs publiceringspunktet fra certifikatet

Certifikatet angiver, hvor dets status ligger. Læs de felter i stedet for at gætte 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 udvidelse angiver CRL-distributionspunkter, og den anden angiver metoder til adgang til myndighedsoplysninger, som kan dække OCSP-status og hentning af udstederens certifikat. Det er forskellige mekanismer, og en OCSP-responder er ikke en CRL-fil. Publiceringsværten er ofte en almindelig webserver frem for CA-maskinen, fordi en offline udsteder kan signere en CRL, som en anden server distribuerer. Derfor er en firewallregel beskrevet som adgang til CA for vag til at blive implementeret eller gennemgået.

Test hentning fra den enhed, der validerer

Kør hentetesten i det miljø, der faktisk udfører validering, med godkendt certifikatmateriale og uden private nøgler.

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

certutil-kørslen verificerer kæden og rapporterer, hvilke URL-hentninger der lykkedes eller fejlede, mens curl-kaldet tester én publiceringsadresse fra den samme vært og kun returnerer en statuskode. En mislykket hentning fra en tilgængelig adresse peger på problemer med indhold eller signatur; en forbindelsesfejl peger på routing, DNS eller proxy. Gem begge resultater, fordi en vellykket hentning ikke beviser, at hele kæden er brugbar. Skift eksempelværten og stien til det distributionspunkt, der findes i certifikatet.

Skel manglende data fra tilbagekaldt status

Fire udfald ser ens ud udefra: endepunktet er utilgængeligt, listen er forældet, listen er signeret af den forkerte udsteder, eller certifikatet er virkelig tilbagekaldt. Kun det sidste er et statusresultat, og kun det berettiger at fjerne adgang. Caching gør billedet endnu mere kompliceret, fordi tidligere hentede data kan skjule en brudt publiceringssti indtil næste opdatering. At deaktivere tilbagekaldelseskontrol, slette urelaterede certifikater eller genstarte gatewayen erstatter alle diagnosen med aktivitet.

Efter rettelsen skal du tvinge en ny godkendelse og bekræfte, at den tilsigtede statusshentning lykkes. Hvor der findes en kontrolleret testidentitet, skal du bekræfte, at den stadig afvises, fordi tilgængelighed, der fjerner kontrollen, ikke er en reparation.