Bladsertifikat gyldig, kjeda utløpt: les djupna

Du sjekkar sertifikatet til tenaren, ser månader att på klokka, og klienten nektar framleis tilkoplinga med ei utløpsmelding. Datoen du les, høyrer til bladet, og klaga kan handle om noko djupare i banen. Verifisering går gjennom ei kjede, og eit kva som helst sertifikat som denne gjennomgangen vel, kan feile i sitt eige gyldigheitsvindauge. Les kva som feila før du fornyar noko.

Djupna nemner sertifikatet som feila

I OpenSSL-diagnostikk er djupn 0 målsertifikatet og djupn 1 utstedaren som signerte det, med høgare tal som held fram mot tillitsankeret. Ein utløp rapportert på djupn 1 blir ikkje motseidd av eit gjeldande notAfter på bladet, så å kontrollere det synlege sertifikatet på nytt vil aldri forklare feilen.

Noter fingeravtrykket til sertifikatet som feila saman med subject, fordi ulike sertifikat kan bere same CA-namn. Krossignering skaper nøyaktig den situasjonen: same styresmakt viser seg meir enn éin gong, med ulike gyldigheitsdatoar, og verifiseraren valde den du ikkje venta. Ei kjend etikett er ikkje ein identifikator, og eit fingeravtrykk er det som skil to objekt som deler eit namn.

Ver òg merksam på produkt med meir enn éi sertifikatrolle. På OpenVPN Access Server er sertifikata som vernar nettgrensesnitta, skilde frå dei som blir brukte til VPN-tilkoplingar, så ein nettlesar som opnar admin-sida beviser ingenting om banen til tunnelen.

Tillitsinndata er ikkje det same som kjedekandidatar

Gi verifiseraren dei to inndataa separat og eksplisitt. Tillitsfila held ankerpunkta du godtek; den ikkje-kjende pakka held mellomliggjande sertifikat som blir tilbodne for å byggje banen. Å blande dei er korleis folk ved eit uhell forfremjar eit mellomliggjande sertifikat til rot og deretter lurer på kvifor same feil følgjer dei mellom maskinar.

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

Deaktivering av standardbanen og -lageret med -no-CApath -no-CAstore held testen ærleg: resultatet avheng då av filene du namngav, ikkje av kva arbeidsstasjonen tilfeldigvis stolar på. OpenSSL-verifiseringsreferansen dokumenterer desse vala og diagnostikken dei produserer.

-show_chain skriv ut den bygde kjeda når verifiseringa lukkast, noko som er nyttig for å stadfeste at banen er den du meinte. Når han feilar, hald den rapporterte djupna og subject; desse to felta fortel neste lesar kva sertifikat som skal granskast.

Det denne ikkje gjer, er å gjenskape politikken til kvar klient. Ein pin, ei føremålsavgrensing eller ein klienttilpassa identitetskontroll lever i klienten, ikkje i denne kommandoen. Det er innstillingane som må granskast når verifiseringa lukkast på tenaren og tilkoplinga framleis feilar. Hald dei to diagnosane skilde, elles fornyar du eit sunt sertifikat medan du jagar ein pinning-feil.

Kva kontrollen beviser og kva han utelèt

Dette er ein bane- og føremålskontroll mot ei tillitsfil du leverte. For ein HTTPS-namnekontroll legg du til det venta vertsnamnet via rett val; for ei VPN-tilkopling held du dei konfigurerte identitetskontrollane til klienten og brukar tillitsmaterialet som den klienten faktisk les.

Det ein tenar sender, er eit sett kandidatar, ikkje banen klienten din endar med å byggje. Lokal tillit og konstruksjonsreglane til biblioteket formar begge resultatet, difor kan same svar verifiserast på éin maskin og feile på ein annan. Samanlikn det vedlikehaldne tillitslageret og TLS-implementasjonen til den feilande klienten med ein fungerande klient, før du tek føre seg identisk vurdering. Ein skilnad der forklarer mange rapportar om „berre denne laptoppen feilar“.

For å sjå vindauget til kvart sertifikat i staden for eitt om gongen, skriv dei ut som eit sett:

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

Den andre kommandoen listar subject og utstedarar utan å dekode kvar fil for hand, slik oppdagar du eit mellomliggjande sertifikat der datoen er passert medan bladet framleis ser fint ut.

Reparer banen utan å svekkje verifiseringa

Når eit utløpt mellomliggjande sertifikat eller eit utdatert krossignert sertifikat blir levert, skaff den gjeldande støtta kjeda til utstedaren og rull henne ut gjennom den dokumenterte sertifikatarbeidsflyten til tenesta. Når klienten manglar det tiltenkte vedlikehaldne ankeret, oppdater den administrerte tillitskonfigurasjonen eller klientprogramvara. Motstå snarvegen med å merke kvart sertifikat i pakka som rot berre for å dempe meldinga.

Handteringa av rota fortener eit notat, fordi samandrag ofte overdriv henne. RFC 5280 behandlar ankeret som inndata utanfor den prospektive banen, medan OpenSSL dokumenterer gyldigheitskontrollar som inkluderer rot-CA-sertifikatet. Begge påstandane er sanne for sine eigne system; å generalisere rotutløpsåtferda til éit bibliotek til alle klientar gir sjølvsikre feil svar.

Etter endringa, tving ei ny autentisering på den råka klienten og stadfest at den spesifikke utløpsmeldinga er borte. Forny bladet berre om bladet sjølv er ueigna. Deaktivering av tidskontrollar eller attoppretting av eit historisk krossertifikat gir ikkje ein gyldig gjeldande bane; det utset berre neste feil.