Listni certifikat veljaven, veriga potekla: preberite globino

Napaka zaradi poteka lahko pripada izdajatelju, ne listu. Preberite globino preverjanja in vhode zaupanja, preden obnovite certifikat, ki je še videti veljaven.

Preverite certifikat strežnika, vidite, da je na uri še mesecev, in odjemalec vseeno zavrne povezavo s sporočilom o poteku. Datum, ki ga berete, pripada listu, in pritožba se lahko nanaša na nekaj globljega na poti. Preverjanje prehodi verigo in kateri koli certifikat, ki ga ta prehod izbere, lahko ne uspe v svojem lastnem oknu veljavnosti. Preberite, kateri ni uspel, preden karkoli obnovite.

Globina poimenuje certifikat, ki ni uspel

V diagnostiki OpenSSL je globina 0 ciljni certifikat, globina 1 pa izdajatelj, ki ga je podpisal, pri čemer višje številke nadaljujejo proti sidru zaupanja. Potek, sporočen na globini 1, ni v nasprotju z veljavnim notAfter na listu, zato ponovno preverjanje vidnega certifikata nikoli ne bo pojasnilo napake.

Zabeležite odtis neuspelega certifikata skupaj z njegovim subject, saj lahko različni certifikati nosijo isto ime CA. Križno podpisovanje ustvari točno to situacijo: ista oblast se pojavi več kot enkrat, z različnimi datumi veljavnosti, in preverjevalec je izbral tistega, ki ga niste pričakovali. Znana oznaka ni identifikator, odtis pa je tisto, kar loči dva objekta z istim imenom.

Bodite pozorni tudi na izdelke z več kot eno vlogo certifikata. V OpenVPN Access Server so certifikati, ki ščitijo spletne vmesnike, ločeni od tistih za VPN povezave, zato brskalnik, ki odpre skrbniško stran, ne dokaže ničesar o poti tunela.

Vhodi zaupanja niso isto kot kandidati verige

Preverjevalcu dajte oba vhoda ločeno in izrecno. Datoteka zaupanja vsebuje sidra, ki jih sprejmete; nezaupanja vreden sveženj vsebuje vmesne certifikate, ponujene za gradnjo poti. Njihovo mešanje je način, kako ljudje pomotoma povzdignejo vmesni certifikat v korenino in se nato sprašujejo, zakaj jih ista napaka spremlja med računalniki.

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

Onemogočanje privzete poti in shrambe z -no-CApath -no-CAstore ohranja test pošten: rezultat je potem odvisen od datotek, ki ste jih navedli, ne od tega, čemur delovna postaja slučajno zaupa. Referenca za preverjanje OpenSSL dokumentira te možnosti in diagnostiko, ki jo ustvarjajo.

-show_chain izpiše zgrajeno verigo, ko preverjanje uspe, kar je koristno za potrditev, da je pot tista, ki ste jo nameravali. Ko ne uspe, obdržite sporočeno globino in subject; ti dve polji povesta naslednjemu bralcu, kateri certifikat pregledati.

Česar to ne počne, je razmnoževanje politike vsakega odjemalca. Pin, omejitev namena ali preverjanje identitete, specifično za odjemalca, živi v odjemalcu, ne v tem ukazu. To so nastavitve, ki jih je treba pregledati, ko preverjanje na strežniku uspe, povezava pa vseeno ne uspe. Držite diagnozi ločeno, sicer boste obnovili zdrav certifikat, medtem ko lovite napako pripenjanja.

Kaj preverjanje dokaže in kaj izpusti

To je preverjanje poti in namena proti datoteki zaupanja, ki ste jo priskrbeli. Za preverjanje imena HTTPS dodajte pričakovano ime gostitelja z ustrezno možnostjo; za VPN povezavo obdržite konfigurirana preverjanja identitete odjemalca in uporabite gradivo zaupanja, ki ga ta odjemalec resnično bere.

Kar strežnik pošlje, je nabor kandidatov, ne pot, ki jo bo vaš odjemalec na koncu zgradil. Lokalno zaupanje in pravila gradnje knjižnice oblikujejo rezultat, zato se lahko isti odgovor preveri na enem računalniku in ne uspe na drugem. Primerjajte vzdrževano shrambo zaupanja in implementacijo TLS neuspelega odjemalca s tistimi delujočega, preden domnevate enako oceno. Razlika tam pojasni veliko poročil „samo ta prenosnik ne uspe“.

Da bi videli okno vsakega certifikata namesto enega za drugim, jih izpišite kot nabor:

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

Ta drugi ukaz navaja subjecte in izdajatelje brez ročnega dekodiranja vsake datoteke, tako opazite vmesni certifikat, katerega datum je že potekel, medtem ko je list še videti v redu.

Popravite pot, ne da bi oslabili preverjanje

Ko je priskrbljen potekel vmesni ali zastarel križno podpisan certifikat, pridobite trenutno podprto verigo izdajatelja in jo namestite po dokumentiranem delovnem toku certifikatov storitve. Ko odjemalcu manjka predvideno vzdrževano sidro, posodobite njegovo upravljano konfiguracijo zaupanja ali programsko opremo odjemalca. Uprite se bližnjici, da vsak certifikat v svežnju označite kot korenino samo zato, da utišate sporočilo.

Ravnanje s korenino si zasluži opombo, ker jo povzetki pogosto pretiravajo. RFC 5280 obravnava sidro kot vhod, ki stoji zunaj predvidene poti, medtem ko OpenSSL dokumentira preverjanja veljavnosti, ki vključujejo njegov korenski certifikat CA. Obe trditvi veljata za njihove lastne sisteme; posploševanje vedenja poteka korenine ene knjižnice na vsakega odjemalca daje samozavestno napačne odgovore.

Po spremembi vsilite novo overjanje na prizadetem odjemalcu in potrdite, da je določeno sporočilo o poteku izginilo. Obnovite list le, če je sam list neprimeren. Onemogočanje časovnih preverjanj ali obnavljanje zgodovinskega križnega certifikata ne ustvari veljavne trenutne poti; le odloži naslednjo napako.

Sorodni članki