scop de certificat neacceptat: de ce eșuează CA intermediară

Scopul certificatului de server pare corect, cheia se potrivește, datele sunt în regulă, iar conexiunea eșuează în continuare cu unsupported certificate purpose. Detaliul care rezolvă acest lucru se află de obicei pe aceeași linie cu eroarea: o valoare de adâncime și un subject care numesc un certificat mai sus în lanț. Se execută două teste diferite, iar doar unul dintre ele privește certificatul final. Compararea lor explică de ce înlocuirea certificatului de server nu schimbă nimic.

Ce certificat a respins de fapt verificatorul

Un lanț nu este un singur obiect repetat de trei ori. Certificatul final poartă numele și cheia serverului, intermediarele îl leagă de o rădăcină, iar fiecare are propria perioadă de valabilitate, constrângeri și utilizări. Când eroarea numește o adâncime, acel număr identifică o poziție în lanțul construit de verificator, iar aceasta poate să nu fie poziția la care vă așteptați dacă serverul trimite un lanț neașteptat.

Citiți câmpurile certificatului la acea adâncime, nu ale certificatului pe care l-ați presupus vinovat. Cereți cele două extensii care restricționează emiterea în loc să afișați fiecare câmp, pentru că răspunsul este aproape întotdeauna într-una dintre ele. Ieșirea extensiilor este sigură de partajat; cheile private niciodată.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Dacă certificatul numit este un intermediar a cărui utilizare extinsă a cheii menționează ceva fără legătură cu autentificarea serverului TLS, restul eșecului urmează mecanic. Lanțul nu poate fi folosit pentru scopul cerut de OpenVPN.

Scopul certificatului final și politica lanțului sunt două teste

Testul certificatului final pune o întrebare îngustă: acest certificat de entitate finală permite autentificarea serverului pentru acest nume? Testul lanțului pune una mai largă: poate fiecare certificat din cale să servească acel scop? O autoritate de certificare autorizată să emită doar certificate de client va trece de propriile verificări de semnătură și tot va eșua la al doilea test, pentru că calea pe care o autorizează nu include scopul de care are nevoie aplicația. Cele două teste eșuează cu aceleași cuvinte și au remedii complet diferite.

De aceea un certificat final proaspăt emis, corect în fiecare câmp vizibil, poate eșua imediat. De aceea remedierea aparține de obicei profilului autorității emitente, nu configurației VPN.

Un EKU absent nu este un EKU restrictiv

RFC 5280 face extensia de utilizare extinsă a cheii opțională și, când este prezentă, restrictivă. Așadar un certificat CA fără extensie nu a spus „nu” autentificării serverului, în timp ce unul care listează doar un scop fără legătură a spus ceva foarte specific. Tratarea acestor două stări ca echivalente produce diagnosticul greșit și, mai rău, remedierea greșită. Distincția explică și de ce două autorități care arată similar într-o consolă se comportă complet diferit într-un lanț.

Nici comportamentul bibliotecilor nu este uniform aici. documentul OpenSSL despre opțiunile de verificare descrie propriul tratament al verificărilor de scop pe certificatele CA, iar acel tratament este o politică de implementare, nu o regulă pe care fiecare stivă TLS o urmează identic. Descrieți ce face verificatorul dumneavoastră și apoi confirmați cu versiunea pe care o rulați efectiv.

Reproduceți eșecul offline înainte de a reemite

O verificare offline scoate aplicația din ecuație. Dacă lanțul eșuează la fel cu același scop, problema este certificatul și nicio configurație de server nu o va ascunde. Dacă lanțul trece offline în timp ce serviciul încă refuză, aplicația cere alt scop sau folosește alt lanț decât cel testat.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain contează pentru că afișează calea construită de instrument, iar aceasta adesea nu este ordinea fișierelor pe care ați furnizat-o. Acea ieșire este cea mai rapidă cale de a descoperi că un al doilea intermediar este tras dintr-un depozit de încredere, că serverul trimite o variantă semnată încrucișat pe care nu ați intenționat-o sau că indicatorul de scop copiat dintr-un tutorial aparține altui rol decât cel deservit.

Corectați politica de emitere, nu apelul de verificare

Remedierea durabilă este un intermediar emis conform unei politici care permite scopurile pe care trebuie să le servească, cu constrângerea scrisă și revizuită. Adăugarea fiecărui scop la fiecare autoritate nu este o politică; elimină constrângerea care dădea sens extensiei și de obicei supraviețuiește incidentului care a provocat-o. O notă scurtă în profil care descrie ce roluri poate certifica autoritatea împiedică următoarea reemitere să repete aceeași dezbatere.

Dezactivarea verificării este cealaltă scurtătură tentantă și transformă o problemă de certificat într-o problemă de încredere. Păstrați verificarea scopului, corectați lanțul și rulați din nou aceeași verificare offline pentru a confirma că calea servește acum rolul dorit înainte de a atinge din nou serviciul.