Certificat frunză valid, lanț expirat: citește adâncimea

Verifici certificatul serverului, vezi luni rămase pe ceas, iar clientul refuză în continuare conexiunea cu un mesaj de expirare. Data pe care o citești aparține frunzei, iar plângerea poate fi despre ceva mai adânc în cale. Verificarea parcurge un lanț, iar orice certificat selectat de această parcurgere poate eșua în propria fereastră de valabilitate. Citește care a eșuat înainte de a reînnoi ceva.

Adâncimea numește certificatul care a eșuat

În diagnosticul OpenSSL, adâncimea 0 este certificatul țintă, iar adâncimea 1 este emitentul care l-a semnat, numerele mai mari continuând spre ancora de încredere. O expirare raportată la adâncimea 1 nu este contrazisă de un notAfter actual pe frunză, așa că reverificarea certificatului vizibil nu va explica niciodată eroarea.

Notează amprenta certificatului eșuat împreună cu subjectul său, deoarece certificate diferite pot purta același nume CA. Semnarea încrucișată produce exact acea situație: aceeași autoritate apare mai mult de o dată, cu date de valabilitate diferite, iar verificatorul a ales-o pe cea la care nu te așteptai. O etichetă familiară nu este un identificator, iar o amprentă este ceea ce distinge două obiecte care împart un nume.

Fii atent și la produsele cu mai mult de un rol de certificat. Pe OpenVPN Access Server, certificatele care protejează interfețele web sunt separate de cele folosite pentru conexiunile VPN, așa că un browser care deschide pagina de administrare nu dovedește nimic despre calea tunelului.

Intrările de încredere nu sunt aceleași cu candidații lanțului

Oferă verificatorului cele două intrări separat și explicit. Fișierul de încredere conține ancorele pe care le accepți; pachetul neîncrezut conține certificate intermediare oferite pentru construirea căii. Amestecarea lor este modul în care oamenii promovează accidental un intermediar la rădăcină și apoi se întreabă de ce aceeași eroare îi urmează între mașini.

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

Dezactivarea căii și a depozitului implicite cu -no-CApath -no-CAstore menține testul onest: rezultatul depinde atunci de fișierele pe care le-ai numit, nu de ceea ce stația de lucru se încrede din întâmplare. Referința de verificare OpenSSL documentează aceste opțiuni și diagnosticul pe care îl produc.

-show_chain tipărește lanțul construit când verificarea reușește, ceea ce este util pentru a confirma că calea este cea dorită. Când eșuează, păstrează adâncimea și subjectul raportate; aceste două câmpuri îi spun următorului cititor ce certificat să inspecteze.

Ceea ce nu face aceasta este să reproducă politica fiecărui client. Un pin, o restricție de scop sau o verificare de identitate specifică clientului trăiește în client, nu în această comandă. Acelea sunt setările de inspectat când verificarea reușește pe server și conexiunea încă eșuează. Ține cele două diagnostice separate, altfel vei reînnoi un certificat sănătos urmărind o eroare de pinning.

Ce dovedește verificarea și ce lasă deoparte

Aceasta este o verificare de cale și scop împotriva unui fișier de încredere pe care l-ai furnizat. Pentru o verificare de nume HTTPS, adaugă numele de gazdă așteptat prin opțiunea potrivită; pentru o conexiune VPN, păstrează verificările de identitate configurate ale clientului și folosește materialul de încredere pe care acel client îl citește efectiv.

Ce trimite un server este un set de candidați, nu calea pe care clientul tău o va construi în final. Încrederea locală și regulile de construire ale bibliotecii modelează ambele rezultatul, de aceea același răspuns poate fi verificat pe o mașină și poate eșua pe alta. Compară depozitul de încredere întreținut și implementarea TLS a clientului care eșuează cu cele ale unui client funcțional înainte de a presupune o evaluare identică. O diferență acolo explică multe rapoarte „doar acest laptop eșuează“.

Pentru a vedea fereastra fiecărui certificat în loc de unul pe rând, tipărește-le ca un set:

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

Acea a doua comandă listează subjecturi și emitenți fără a decodifica fiecare fișier manual, așa observi un intermediar a cărui dată a trecut în timp ce frunza încă pare în regulă.

Repară calea fără a slăbi verificarea

Când este furnizat un intermediar expirat sau un certificat semnat încrucișat învechit, obține lanțul actual suportat al emitentului și implementează-l prin fluxul de lucru documentat al certificatelor serviciului. Când clientului îi lipsește ancora întreținută dorită, actualizează configurația sa de încredere gestionată sau software-ul clientului. Rezistă scurtăturii de a marca fiecare certificat din pachet ca rădăcină doar pentru a reduce la tăcere mesajul.

Tratarea rădăcinii merită o notă, deoarece rezumatele o exagerează adesea. RFC 5280 tratează ancora ca o intrare situată în afara căii prospective, în timp ce OpenSSL documentează verificări de valabilitate care includ certificatul său CA rădăcină. Ambele afirmații sunt adevărate pentru sistemele lor; generalizarea comportamentului de expirare a rădăcinii unei biblioteci la fiecare client produce răspunsuri greșite cu încredere.

După modificare, forțează o autentificare nouă pe clientul afectat și confirmă că mesajul de expirare specific a dispărut. Reînnoiește frunza doar dacă frunza însăși este nepotrivită. Dezactivarea verificărilor de timp sau restaurarea unui certificat încrucișat istoric nu produce o cale actuală validă; doar întârzie următorul eșec.