Bladcertifikat gyldigt, kæde udløbet: Læs dybden

Du tjekker servercertifikatet, ser måneder tilbage på uret, og klienten afviser stadig forbindelsen med en udløbsmeddelelse. Den dato, du læser, tilhører bladet, og klagen kan handle om noget dybere i stien. Verifikation går gennem en kæde, og ethvert certifikat, som denne gennemgang vælger, kan fejle i sit eget gyldighedsvindue. Læs hvilket der fejlede, før du fornyer noget.

Dybden navngiver det certifikat, der fejlede

I OpenSSL-diagnostik er dybde 0 målcertifikatet, og dybde 1 er den udsteder, der signerede det, mens højere tal fortsætter mod tillidsankeret. En udløbsfejl rapporteret på dybde 1 modsiges ikke af et aktuelt notAfter på bladet, så at kontrollere det synlige certifikat igen vil aldrig forklare fejlen.

Notér det fejlede certifikats fingeraftryk sammen med dets subject, fordi forskellige certifikater kan bære det samme CA-navn. Krydssignering skaber præcis den situation: den samme myndighed optræder mere end én gang med forskellige gyldighedsdatoer, og verifikatoren valgte den, du ikke forventede. Et velkendt mærke er ikke en identifikator, og et fingeraftryk er det, der skelner to objekter, der deler et navn.

Vær også opmærksom på produkter med mere end én certifikatrolle. På OpenVPN Access Server er certifikaterne, der beskytter webgrænsefladerne, adskilt fra dem, der bruges til VPN-forbindelser, så en browser, der åbner admin-siden, beviser intet om tunnelens sti.

Tillidsinput er ikke det samme som kædekandidater

Giv verifikatoren de to input separat og eksplicit. Tillidsfilen indeholder de ankere, du accepterer; den ikke-betroede pakke indeholder mellemliggende certifikater, der tilbydes til at bygge stien. At blande dem er, hvordan folk ved et uheld forfremmer et mellemliggende certifikat til en rod og derefter undrer sig over, hvorfor den samme fejl følger dem mellem maskiner.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Deaktivering af standardstien og -lageret med -no-CApath -no-CAstore holder testen ærlig: resultatet afhænger så af de filer, du navngav, snarere end af hvad arbejdsstationen tilfældigvis stoler på. OpenSSL-verifikationsreferencen dokumenterer disse muligheder og den diagnostik, de producerer.

-show_chain udskriver den byggede kæde, når verifikationen lykkes, hvilket er nyttigt til at bekræfte, at stien er den, du havde til hensigt. Når den fejler, behold den rapporterede dybde og det rapporterede subject; disse to felter fortæller den næste læser, hvilket certifikat der skal undersøges.

Det, dette ikke gør, er at genskabe hver klients politik. Et pin, en formålsbegrænsning eller et klientspecifikt identitetstjek lever i klienten, ikke i denne kommando. Det er de indstillinger, der skal undersøges, når verifikationen lykkes på serveren, og forbindelsen stadig fejler. Hold de to diagnoser adskilt, ellers fornyer du et sundt certifikat, mens du jager en pinning-fejl.

Hvad kontrollen beviser, og hvad den udelader

Dette er et sti- og formålstjek mod en tillidsfil, du selv har leveret. Til et HTTPS-navnetjek tilføjer du det forventede værtsnavn via den relevante mulighed; til en VPN-forbindelse beholder du klientens konfigurerede identitetstjek og bruger det tillidsmateriale, som klienten faktisk læser.

Det, en server sender, er et sæt kandidater, ikke den sti, din klient ender med at bygge. Lokal tillid og bibliotekets konstruktionsregler former begge resultatet, hvilket er grunden til, at det samme svar kan verificere på én maskine og fejle på en anden. Sammenlign den fejlende klients vedligeholdte tillidslager og TLS-implementering med en fungerende klients, før du antager identisk evaluering. En forskel der forklarer mange rapporter om „kun denne laptop fejler“.

For at se hvert certifikats vindue i stedet for ét ad gangen, udskriv dem som et sæt:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Den anden kommando viser subjecter og udstedere uden at afkode hver fil manuelt, og det er sådan, du spotter et mellemliggende certifikat, hvis dato er passeret, mens bladet stadig ser fint ud.

Reparer stien uden at svække verifikationen

Når et udløbet mellemliggende certifikat eller et forældet krydssigneret certifikat leveres, skaf udstederens aktuelt understøttede kæde og implementer den via tjenestens dokumenterede certifikatworkflow. Når klienten mangler det tilsigtede vedligeholdte anker, opdater dens administrerede tillidskonfiguration eller klientsoftwaren. Modstå genvejen at markere hvert certifikat i pakken som en rod blot for at stoppe meddelelsen.

Håndtering af roden fortjener en note, fordi oversigter ofte overdriver den. RFC 5280 behandler ankeret som et input uden for den prospektive sti, mens OpenSSL dokumenterer gyldighedstjek, der inkluderer dets rod-CA-certifikat. Begge udsagn er sande for deres egne systemer; at generalisere ét biblioteks rodudløbsadfærd til alle klienter giver selvsikre forkerte svar.

Efter ændringen skal du tvinge en frisk godkendelse på den berørte klient og bekræfte, at den specifikke udløbsmeddelelse er væk. Forny kun bladet, hvis bladet selv er uegnet. Deaktivering af tidskontroller eller gendannelse af et historisk krydcertifikat giver ikke en gyldig aktuel sti; det udsætter blot den næste fejl.