Bladsertifikaat geldig, ketting verval: Lees die diepte

Jy kyk na die bediener-sertifikaat, sien nog maande op die klok, en die kliënt weier steeds die verbinding met 'n vervalboodskap. Die datum wat jy lees, hoort aan die blaar, en die klag kan oor iets dieper in die pad gaan. Verifikasie loop 'n ketting, en enige sertifikaat wat dié loop kies, kan sy eie geldigheidsvenster misloop. Lees watter een gefaal het voordat jy enigiets hernu.

Die diepte noem die sertifikaat wat gefaal het

In OpenSSL-diagnostiek is diepte 0 die teikensertifikaat en diepte 1 die uitreiker wat dit onderteken het, met hoër getalle wat verder na die vertrouensanker lei. 'n Verval wat by diepte 1 gerapporteer word, word nie weerspreek deur 'n huidige notAfter op die blaar nie, so om die sigbare sertifikaat weer te ondersoek sal die fout nooit verduidelik nie.

Teken die mislukte sertifikaat se vingerafdruk saam met sy onderwerp aan, want verskillende sertifikate kan dieselfde CA-naam dra. Kruisondertekening skep presies dié situasie: dieselfde owerheid verskyn meer as een keer, met verskillende geldigheidsdatums, en die verifieerder het die een gekies wat jy nie verwag het nie. 'n Bekende etiket is nie 'n identifiseerder nie, en 'n vingerafdruk is wat twee voorwerpe met dieselfde naam onderskei.

Let ook op produkte met meer as een sertifikaatrol. Op OpenVPN Access Server is die sertifikate wat die webkoppelvlakke beskerm apart van dié wat vir VPN-verbindings gebruik word, so 'n blaaier wat die administrasiebladsy oopmaak, bewys niks oor die tonnel se pad nie.

Vertrouensinsette is nie dieselfde as kettingkandidate nie

Gee die verifieerder die twee insette afsonderlik en uitdruklik. Die vertrouenslêer hou die ankers wat jy aanvaar; die onvertroude bondel hou tussenliggende sertifikate wat vir die bou van die pad aangebied word. Om hulle te meng is hoe mense per ongeluk 'n tussenliggende sertifikaat tot 'n wortel bevorder en dan wonder hoekom dieselfde fout hulle tussen masjiene volg.

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

Om die verstekpad en -stoor met -no-CApath -no-CAstore te deaktiveer, hou die toets eerlik: die resultaat hang dan van die lêers wat jy genoem het af, nie van wat die werkstasie toevallig vertrou nie. Die OpenSSL-verifikasieverwysing dokumenteer dié opsies en die diagnostiek wat hulle lewer.

-show_chain druk die geboude ketting wanneer verifikasie slaag, wat nuttig is om te bevestig dat die pad die een is wat jy bedoel het. Wanneer dit misluk, hou die gerapporteerde diepte en onderwerp; dié twee velde sê vir die volgende leser watter sertifikaat om te ondersoek.

Wat dit nie doen nie, is om elke kliënt se beleid te herskep. 'n Pen, 'n doelbeperking of 'n kliëntspesifieke identiteitskontrole woon in die kliënt, nie in hierdie opdrag nie. Dit is die instellings om te ondersoek wanneer verifikasie op die bediener slaag en die verbinding steeds misluk. Hou die twee diagnoses apart, anders hernu jy 'n gesonde sertifikaat terwyl jy 'n vaspenfout jaag.

Wat die toets bewys en wat dit weglaat

Dit is 'n pad-en-doel-toets teen 'n vertrouenslêer wat jy verskaf het. Vir 'n HTTPS-naamtoets voeg die verwagte gasheernaam deur die gepaste opsie by; vir 'n VPN-verbinding hou die kliënt se gekonfigureerde identiteitskontroles en gebruik die vertrouensmateriaal wat daardie kliënt werklik lees.

Wat 'n bediener stuur, is 'n stel kandidate, nie die pad wat jou kliënt uiteindelik sal bou nie. Plaaslike vertroue en die biblioteek se konstruksiereëls vorm albei die resultaat, daarom kan dieselfde antwoord op een masjien verifieer en op 'n ander misluk. Vergelyk die mislukkende kliënt se onderhoue vertrouensstoor en TLS-implementering met dié van 'n werkende kliënt voordat jy identiese evaluering aanneem. 'n Verskil daar verklaar baie verslae van „net hierdie skootrekenaar misluk”.

Om elke sertifikaat se venster eerder as een op 'n slag te sien, druk hulle as 'n stel:

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

Daardie tweede opdrag lys onderwerpe en uitreikers sonder om elke lêer met die hand te dekodeer, dit is hoe jy 'n tussenliggende sertifikaat raaksien wie se datum verby is terwyl die blaar nog goed lyk.

Herstel die pad sonder om verifikasie te verswak

Wanneer 'n verstreke tussenliggende of 'n verouderde kruisondertekende sertifikaat verskaf word, kry die uitreiker se tans ondersteunde ketting en ontplooi dit deur die diens se gedokumenteerde sertifikaatwerkvloei. Wanneer die kliënt die beoogde onderhoue anker kort, werk sy bestuurde vertrouenskonfigurasie of die kliëntesagteware by. Weerstaan die kortpad om elke sertifikaat in die bondel as 'n wortel te merk net om die boodskap stil te maak.

Wortelhantering verdien 'n nota, want opsommings oordryf dit dikwels. RFC 5280 behandel die anker as 'n inset wat buite die voornemende pad lê, terwyl OpenSSL geldigheidskontroles dokumenteer wat sy wortel-CA-sertifikaat insluit. Albei stellings is waar vir hul eie stelsels; om een biblioteek se wortelvervalgedrag na elke kliënt te veralgemeen, lewer selfversekerde verkeerde antwoorde.

Ná die verandering, forseer 'n vars verifikasie op die geaffekteerde kliënt en bevestig dat die spesifieke vervalboodskap weg is. Hernu die blaar net as die blaar self ongeskik is. Om tydkontroles te deaktiveer of 'n historiese kruissertifikaat te herstel, lewer nie 'n geldige huidige pad nie; dit stel net die volgende mislukking uit.