Levél-tanúsítvány érvényes, a lánc lejárt: olvassa a mélységet

A lejárati hiba tartozhat egy kibocsátóhoz, nem a levélhez. Olvassa el az ellenőrzés mélységét és a bizalmi bemeneteket, mielőtt megújít egy tanúsítványt, amely még aktuálisnak tűnik.

Ellenőrzi a szerver tanúsítványát, hónapokat lát az órán, és a kliens mégis elutasítja a kapcsolatot lejárati üzenettel. Az olvasott dátum a levélhez tartozik, a panasz pedig valami mélyebbről szólhat az útvonalon. Az ellenőrzés egy láncot jár be, és a bejárás által kiválasztott bármely tanúsítvány meghiúsulhat a saját érvényességi ablakában. Olvassa el, melyik hiúsult meg, mielőtt bármit megújít.

A mélység megnevezi a meghiúsult tanúsítványt

Az OpenSSL diagnosztikájában a 0. mélység a céltanúsítvány, az 1. mélység pedig az azt aláíró kibocsátó, a nagyobb számok pedig a bizalmi horgony felé folytatódnak. Az 1. mélységben jelentett lejáratot nem cáfolja a levélen lévő aktuális notAfter, ezért a látható tanúsítvány újbóli ellenőrzése soha nem fogja megmagyarázni a hibát.

Jegyezze fel a meghiúsult tanúsítvány ujjlenyomatát a subjectjével együtt, mert különböző tanúsítványok ugyanazt a CA-nevet viselhetik. A keresztaláírás pontosan ezt a helyzetet teremti meg: ugyanaz a hatóság többször is megjelenik, eltérő érvényességi dátumokkal, és az ellenőrző azt választotta, amelyre nem számított. Az ismerős címke nem azonosító, és az ujjlenyomat az, ami megkülönböztet két azonos nevű objektumot.

Figyeljen az egynél több tanúsítvány-szerepkörrel rendelkező termékekre is. Az OpenVPN Access Serveren a webes felületeket védő tanúsítványok elkülönülnek a VPN-kapcsolatokhoz használtaktól, így egy admin oldalt megnyitó böngésző semmit sem bizonyít az alagút útvonaláról.

A bizalmi bemenetek nem azonosak a láncjelöltekkel

Adja meg az ellenőrzőnek a két bemenetet külön és kifejezetten. A bizalmi fájl az Ön által elfogadott horgonyokat tartalmazza; a nem megbízható köteg a lánc építéséhez felajánlott köztes tanúsítványokat. Ezek keverése az, ahogyan az emberek véletlenül köztes tanúsítványt léptetnek elő gyökérré, majd csodálkoznak, miért követi őket ugyanaz a hiba a gépek között.

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

Az alapértelmezett útvonal és tároló letiltása a -no-CApath -no-CAstore kapcsolóval őszinte tesztet tart: az eredmény akkor az Ön által megnevezett fájloktól függ, nem attól, amiben a munkaállomás véletlenül megbízik. Az OpenSSL ellenőrzési referenciája dokumentálja ezeket az opciókat és az általuk keltett diagnosztikát.

-show_chain kiírja a felépített láncot, amikor az ellenőrzés sikerül, ami hasznos annak megerősítésére, hogy az útvonal a szándékolt. Ha meghiúsul, tartsa meg a jelentett mélységet és subjectet; ez a két mező mondja meg a következő olvasónak, melyik tanúsítványt vizsgálja.

Amit ez nem tesz meg, az az egyes kliensek irányelvének újrakeltése. A pin, a célkorlátozás vagy az ügyfélspecifikus identitásellenőrzés a kliensben él, nem ebben a parancsban. Ezeket a beállításokat kell megnézni, amikor az ellenőrzés a szerveren sikerül, de a kapcsolat továbbra is meghiúsul. Tartsa külön a két diagnózist, különben egészséges tanúsítványt újít meg egy pinning-hibát kergetve.

Mit bizonyít az ellenőrzés, és mit hagy ki

Ez egy útvonal- és cél-ellenőrzés az Ön által szolgáltatott bizalmi fájl ellen. HTTPS névellenőrzéshez adja hozzá a várt gazdagépnevet a megfelelő opcióval; VPN-kapcsolathoz tartsa meg a kliens beállított identitásellenőrzéseit, és használja azt a bizalmi anyagot, amelyet az a kliens valóban olvas.

Amit a szerver küld, az jelöltek halmaza, nem az az útvonal, amelyet a kliense végül felépít. A helyi bizalom és a könyvtár építési szabályai egyaránt alakítják az eredményt, ezért ugyanaz a válasz az egyik gépen ellenőrizhető, a másikon meghiúsulhat. Hasonlítsa össze a meghiúsult kliens karbantartott bizalmi tárolóját és TLS-implementációját egy működő kliensével, mielőtt azonos értékelést feltételezne. Az ottani különbség sok „csak ezen a laptopon hibásodik meg” jelentést megmagyaráz.

Hogy az egyes tanúsítványok ablakát ne egyenként lássa, írja ki őket halmazként:

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

A második parancs subjecteket és kibocsátókat sorol fel anélkül, hogy minden fájlt kézzel dekódolna, így veszi észre az olyan köztes tanúsítványt, amelynek dátuma elmúlt, miközben a levél még jól néz ki.

Javítsa az útvonalat az ellenőrzés gyengítése nélkül

Ha lejárt köztes vagy elavult keresztaláírt tanúsítványt szolgáltatnak, szerezze be a kibocsátó jelenleg támogatott láncát, és telepítse a szolgáltatás dokumentált tanúsítvány-munkafolyamatán keresztül. Ha a kliensből hiányzik a szándékolt karbantartott horgony, frissítse a felügyelt bizalmi konfigurációját vagy a kliensszoftvert. Álljon ellen annak a rövidítésnek, hogy minden tanúsítványt gyökérnek jelöljön a kötegben csak az üzenet elhallgattatásához.

A gyökér kezelése megjegyzést érdemel, mert az összefoglalók gyakran eltúlozzák. Az RFC 5280 a horgonyt a várható útvonalon kívül álló bemenetként kezeli, míg az OpenSSL olyan érvényességi ellenőrzéseket dokumentál, amelyek tartalmazzák a gyökér CA tanúsítványát. Mindkét állítás igaz a saját rendszereikre; egy könyvtár gyökérlejárati viselkedésének minden kliensre való általánosítása magabiztos hibás válaszokat ad.

A változtatás után kényszerítsen friss hitelesítést az érintett kliensen, és erősítse meg, hogy az adott lejárati üzenet eltűnt. Csak akkor újítsa meg a levelet, ha maga a levél alkalmatlan. Az időellenőrzések letiltása vagy történelmi kereszttanúsítvány visszaállítása nem hoz létre érvényes aktuális útvonalat; csak késlelteti a következő meghibásodást.

Kapcsolódó cikkek