Lövcertifikatet giltigt, kedjan har gått ut: läs djupet

Du kontrollerar serverns certifikat, ser månader kvar på klockan, och klienten vägrar fortfarande anslutningen med ett utgångsmeddelande. Datumet du läser tillhör lövet, och klagomålet kan handla om något djupare i vägen. Verifiering går genom en kedja, och vilket certifikat som helst som denna genomgång väljer kan misslyckas i sitt eget giltighetsfönster. Läs vilket som misslyckades innan du förnyar något.

Djupet namnger certifikatet som misslyckades

I OpenSSL-diagnostik är djup 0 målcertifikatet och djup 1 är utfärdaren som signerade det, med högre nummer som fortsätter mot förtroendeankaret. Ett utgångsdatum som rapporteras på djup 1 motsägs inte av ett aktuellt notAfter på lövet, så att kontrollera det synliga certifikatet igen kommer aldrig att förklara felet.

Anteckna fingeravtrycket för det misslyckade certifikatet tillsammans med dess subject, eftersom olika certifikat kan bära samma CA-namn. Korssignering skapar exakt den situationen: samma myndighet visas mer än en gång, med olika giltighetsdatum, och verifieraren valde den du inte förväntade dig. En bekant etikett är inte en identifierare, och ett fingeravtryck är det som skiljer två objekt som delar ett namn.

Var också uppmärksam på produkter med mer än en certifikatroll. På OpenVPN Access Server är certifikaten som skyddar webbgränssnitten åtskilda från dem som används för VPN-anslutningar, så en webbläsare som öppnar adminsidan bevisar ingenting om tunnelns väg.

Förtroendeinmatningar är inte samma sak som kedjekandidater

Ge verifieraren de två inmatningarna separat och uttryckligen. Förtroendefilen innehåller ankarna du accepterar; det icke betrodda paketet innehåller mellanliggande certifikat som erbjuds för att bygga vägen. Att blanda dem är hur folk av misstag befordrar ett mellanliggande certifikat till rot och sedan undrar varför samma fel följer dem mellan maskiner.

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

Att inaktivera standardvägen och -lagret med -no-CApath -no-CAstore håller testet ärligt: resultatet beror då på filerna du namngav, inte på vad arbetsstationen råkar lita på. OpenSSL:s verifieringsreferens dokumenterar dessa alternativ och den diagnostik de producerar.

-show_chain skriver ut den byggda kedjan när verifieringen lyckas, vilket är användbart för att bekräfta att vägen är den du avsåg. När den misslyckas, behåll det rapporterade djupet och subject; dessa två fält talar om för nästa läsare vilket certifikat som ska inspekteras.

Detta gör inte att återskapa varje klients policy. En pin, en syftesbegränsning eller en klientspecifik identitetskontroll lever i klienten, inte i det här kommandot. Det är inställningarna att inspektera när verifieringen lyckas på servern och anslutningen fortfarande misslyckas. Håll de två diagnoserna åtskilda, annars förnyar du ett friskt certifikat medan du jagar ett pinning-fel.

Vad kontrollen bevisar och vad den utelämnar

Detta är en väg- och syfteskontroll mot en förtroendefil du tillhandahållit. För en HTTPS-namnkontroll lägger du till det förväntade värdnamnet via rätt alternativ; för en VPN-anslutning behåller du klientens konfigurerade identitetskontroller och använder det förtroendematerial som klienten faktiskt läser.

Det en server skickar är en uppsättning kandidater, inte den väg din klient till slut bygger. Lokalt förtroende och bibliotekets konstruktionsregler formar båda resultatet, vilket är varför samma svar kan verifiera på en maskin och misslyckas på en annan. Jämför den misslyckade klientens underhållna förtroendelager och TLS-implementering med en fungerande klients innan du antar identisk bedömning. En skillnad där förklarar många rapporter om „bara den här bärbara datorn misslyckas“.

För att se varje certifikats fönster i stället för ett i taget, skriv ut dem som en uppsättning:

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

Det andra kommandot listar subject och utfärdare utan att avkoda varje fil för hand, så upptäcker du ett mellanliggande certifikat vars datum har passerat medan lövet fortfarande ser bra ut.

Reparera vägen utan att försvaga verifieringen

När ett utgånget mellanliggande certifikat eller ett föråldrat korssignerat certifikat tillhandahålls, skaffa utfärdarens nuvarande stödda kedja och distribuera den genom tjänstens dokumenterade certifikatarbetsflöde. När klienten saknar det avsedda underhållna ankaret, uppdatera dess hanterade förtroendekonfiguration eller klientprogramvaran. Motstå genvägen att markera varje certifikat i paketet som rot bara för att tysta meddelandet.

Hanteringen av roten förtjänar en notering, eftersom sammanfattningar ofta överdriver den. RFC 5280 behandlar ankaret som en inmatning utanför den prospektiva vägen, medan OpenSSL dokumenterar giltighetskontroller som inkluderar dess rot-CA-certifikat. Båda påståendena är sanna för deras egna system; att generalisera ett biblioteks rotutgångsbeteende till alla klienter ger självsäkra felaktiga svar.

Efter ändringen, tvinga en ny autentisering på den berörda klienten och bekräfta att det specifika utgångsmeddelandet är borta. Förnya lövet bara om lövet självt är olämpligt. Att inaktivera tidskontroller eller återställa ett historiskt korscertifikat ger inte en giltig aktuell väg; det skjuter bara upp nästa fel.