Bladsertifikat gyldig, kjeden utløpt: les dybden

Du sjekker serverens sertifikat, ser måneder igjen på klokken, og klienten nekter fortsatt tilkoblingen med en utløpsmelding. Datoen du leser, tilhører bladet, og klagen kan handle om noe dypere i banen. Verifisering går gjennom en kjede, og ethvert sertifikat som denne gjennomgangen velger, kan feile i sitt eget gyldighetsvindu. Les hvilket som feilet før du fornyer noe.

Dybden navngir sertifikatet som feilet

I OpenSSL-diagnostikk er dybde 0 målsertifikatet og dybde 1 er utstederen som signerte det, mens høyere tall fortsetter mot tillitsankeret. En utløpsfeil rapportert på dybde 1 motsies ikke av et gjeldende notAfter på bladet, så å kontrollere det synlige sertifikatet på nytt vil aldri forklare feilen.

Noter fingeravtrykket til sertifikatet som feilet sammen med subject, fordi ulike sertifikater kan bære samme CA-navn. Kryssignering skaper nøyaktig den situasjonen: samme myndighet vises mer enn én gang, med ulike gyldighetsdatoer, og verifisereren valgte den du ikke forventet. En kjent etikett er ikke en identifikator, og et fingeravtrykk er det som skiller to objekter som deler et navn.

Vær også oppmerksom på produkter med mer enn én sertifikatrolle. På OpenVPN Access Server er sertifikatene som beskytter nettgrensesnittene atskilt fra dem som brukes til VPN-tilkoblinger, så en nettleser som åpner admin-siden beviser ingenting om tunnelens bane.

Tillitsinndata er ikke det samme som kjedekandidater

Gi verifisereren de to inndataene separat og eksplisitt. Tillitsfilen inneholder ankerne du aksepterer; den ikke-klarerte pakken inneholder mellomliggende sertifikater som tilbys for å bygge banen. Å blande dem er hvordan folk ved et uhell forfremmer et mellomliggende sertifikat til rot og deretter lurer på hvorfor samme feil følger dem mellom maskiner.

$ 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 holder testen ærlig: resultatet avhenger da av filene du navnga, ikke av hva arbeidsstasjonen tilfeldigvis stoler på. OpenSSL-verifiseringsreferansen dokumenterer disse valgene og diagnostikken de produserer.

-show_chain skriver ut den bygde kjeden når verifiseringen lykkes, noe som er nyttig for å bekrefte at banen er den du mente. Når den feiler, behold den rapporterte dybden og subject; disse to feltene forteller neste leser hvilket sertifikat som skal undersøkes.

Det dette ikke gjør, er å gjenskape hver klients policy. En pin, en formålsbegrensning eller en klientspesifikk identitetskontroll lever i klienten, ikke i denne kommandoen. Det er innstillingene som må undersøkes når verifiseringen lykkes på serveren og tilkoblingen fortsatt feiler. Hold de to diagnosene atskilt, ellers fornyer du et sunt sertifikat mens du jager en pinning-feil.

Hva kontrollen beviser og hva den utelater

Dette er en bane- og formålskontroll mot en tillitsfil du leverte. For en HTTPS-navnekontroll legger du til det forventede vertsnavnet via riktig alternativ; for en VPN-tilkobling beholder du klientens konfigurerte identitetskontroller og bruker tillitsmaterialet som den klienten faktisk leser.

Det en server sender, er et sett kandidater, ikke banen klienten din ender med å bygge. Lokal tillit og bibliotekets konstruksjonsregler former begge resultatet, derfor kan samme svar verifiseres på én maskin og feile på en annen. Sammenlign den feilende klientens vedlikeholdte tillitslager og TLS-implementasjon med en fungerende klients, før du antar identisk vurdering. En forskjell der forklarer mange rapporter om „bare denne laptopen feiler“.

For å se hvert sertifikats vindu i stedet for ett om gangen, skriv dem ut som et sett:

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

Den andre kommandoen lister subjecter og utstedere uten å dekode hver fil for hånd, slik oppdager du et mellomliggende sertifikat hvis dato er passert mens bladet fortsatt ser fint ut.

Reparer banen uten å svekke verifiseringen

Når et utløpt mellomliggende sertifikat eller et utdatert kryssignert sertifikat leveres, skaff utstederens gjeldende støttede kjede og distribuer den gjennom tjenestens dokumenterte sertifikatarbeidsflyt. Når klienten mangler det tiltenkte vedlikeholdte ankeret, oppdater den administrerte tillitskonfigurasjonen eller klientprogramvaren. Motstå snarveien med å merke hvert sertifikat i pakken som rot bare for å dempe meldingen.

Håndtering av roten fortjener en merknad, fordi sammendrag ofte overdriver den. RFC 5280 behandler ankeret som en inndata utenfor den prospektive banen, mens OpenSSL dokumenterer gyldighetskontroller som inkluderer rot-CA-sertifikatet. Begge utsagnene er sanne for sine egne systemer; å generalisere én biblioteks rotutløpsatferd til alle klienter gir selvsikre feil svar.

Etter endringen, tving en ny autentisering på den berørte klienten og bekreft at den spesifikke utløpsmeldingen er borte. Forny bladet bare hvis bladet selv er uegnet. Deaktivering av tidskontroller eller gjenoppretting av et historisk kryssertifikat gir ikke en gyldig gjeldende bane; det utsetter bare neste feil.