Ce este un lanț de certificate SSL? Cum funcționează

Un lanț de certificate SSL ajută browserele și alți clienți să verifice dacă certificatul digital al unui site web poate fi de încredere. Când vizitați un site web prin HTTPS, browserul dumneavoastră își verifică certificatul TLS pentru a confirma că identifică domeniul solicitat și că poate fi validat printr-o Autoritate de Certificare (CA) de încredere. Această verificare depinde adesea de un lanț de certificate care conectează certificatul site-ului web la un certificat rădăcină de încredere. Dacă lipsește un certificat intermediar sau lanțul nu poate fi validat, utilizatorii pot întâlni avertismente de securitate sau erori de conectare. Înțelegerea modului în care funcționează un lanț de certificate SSL îi ajută pe proprietarii de site-uri web, administratorii de sistem și profesioniștii în securitate să rezolve problemele legate de certificat și să mențină conexiuni HTTPS fiabile.

Ce este un lanț de certificate SSL?

Un lanț de certificate SSL, numit și un lanț de certificate de încredere, este o secvență de certificate digitale care stabilește o cale de la certificatul unui site web la o autoritate de certificare rădăcină de încredere. Deși SSL rămâne un termen comun, conexiunile HTTPS moderne folosesc Transport Layer Security (TLS).

Un lanț tipic conține trei tipuri de certificate: certificatul frunză al site-ului web, unul sau mai multe certificate intermediare și un certificat rădăcină. Certificatul de frunză identifică site-ul web sau serverul. Certificatele intermediare permit delegarea emiterii certificatelor, în timp ce certificatul rădăcină servește ca o ancoră de încredere atunci când clientul are încredere.

De exemplu, atunci când un browser se conectează la un site web HTTPS, validează certificatul site-ului web și încearcă să construiască o cale de încredere prin certificatele intermediare disponibile către un certificat rădăcină din magazinul său de încredere. De asemenea, verifică numele gazdei, datele de valabilitate, semnăturile digitale și alte cerințe aplicabile pentru certificat.

Un lanț de certificate valid ajută la stabilirea identității serverului în timpul strângerii de mână TLS. Cu toate acestea, nu dovedește că un site web este legitim, lipsit de programe malware sau operat de o organizație de încredere.

Cum funcționează lanțul de încredere al certificatelor SSL?

Lanțul de încredere de certificate permite browserelor și altor clienți să valideze certificatul unui site web folosind certificate emise de autorități de încredere. Fiecare certificat face legătura cu o autoritate emitentă, creând o cale de la certificatul site-ului web la o ancoră de încredere acceptabilă.

Pasul 1: Site-ul își prezintă certificatul

Când un browser se conectează la un site web prin HTTPS, serverul își prezintă certificatul de frunză în timpul strângerii de mână TLS. Acest certificat conține cheia publică a site-ului web, informații despre domeniu, detalii despre emitent, perioada de valabilitate și semnătura digitală.

Browserul verifică dacă numele de gazdă solicitat se potrivește cu intrările Subject Alternative Name (SAN) ale certificatului și dacă certificatul îndeplinește cerințele de validare aplicabile.

Pasul 2: Certificatul intermediar stabilește următoarea legătură

Certificatul site-ului web este de obicei emis de un CA intermediar, mai degrabă decât direct de un CA rădăcină. Clientul folosește cheia publică a certificatului intermediar pentru a verifica semnătura de pe certificatul de frunză.

Unele lanțuri conțin mai multe certificate intermediare. Fiecare link trebuie să îndeplinească regulile relevante de validare a certificatului pentru ca clientul să construiască o cale de încredere.

Pasul 3: Lanțul ajunge la o rădăcină de încredere

Un certificat rădăcină aparține unei autorități de certificare rădăcină și este de obicei autosemnat. Browserele și sistemele de operare mențin certificate rădăcină de încredere în conformitate cu propriile politici de încredere.

Clientul încearcă să conecteze certificatul frunză prin certificatele intermediare necesare la o rădăcină de încredere. În mod normal, serverul nu trebuie să trimită certificatul rădăcină deoarece clientul are deja informațiile sale de încredere.

Pasul 4: Clientul validează lanțul

Clientul verifică semnăturile certificatelor, perioadele de valabilitate, numele gazdei, constrângerile certificatului și alte cerințe aplicabile. În funcție de configurația sa, poate verifica și informațiile de revocare a certificatului.

Dacă clientul creează o cale validă și verificările necesare trec, poate accepta certificatul serverului. În caz contrar, conexiunea poate produce un avertisment de certificat sau poate eșua.

Certificat rădăcină vs. certificat intermediar vs. certificat frunză

Fiecare certificat din lanț are un scop specific. Înțelegerea acestor diferențe ajută administratorii să configureze corect HTTPS și să depaneze erorile de certificat.

1. Certificat de frunză

Un certificat de frunză, numit și certificat de entitate finală, identifică un site web sau un server. Conține cheia publică, informațiile despre domeniu, emitentul, datele de valabilitate și semnătura digitală.

Serverul prezintă acest certificat clientului în timpul strângerii de mână TLS. Clientul își verifică identitatea și validitatea înainte de a-l accepta pentru conexiune.

2. Certificat intermediar

Un certificat intermediar aparține unei autorități de certificare subordonate care emite certificate sau delegă eliberarea unei alte autorități. Acesta conectează certificatul site-ului web la un certificat rădăcină de încredere.

CA intermediare permit CA rădăcină să-și păstreze cheile private mai izolate în timp ce delegă emiterea certificatelor. Dacă lipsește un certificat intermediar necesar și nu poate fi obținut printr-un alt mecanism disponibil, este posibil ca clientul să nu poată valida lanțul.

3. Certificat rădăcină

Un certificat rădăcină aparține unei autorități de certificare rădăcină și acționează ca o ancoră de încredere atunci când este acceptat de magazinul de încredere al unui client. În mod obișnuit, este autosemnat, dar faptul că este autosemnat nu face automat un certificat de încredere.

Clientul trebuie să recunoască rădăcina ca fiind de încredere în conformitate cu politica sa de încredere configurată.

Prin urmare, un lanț tipic urmează această cale:

Certificat de site → Certificat CA intermediar → Certificat rădăcină de încredere

Lanțul exact depinde de autoritatea de certificare, configurația serverului și certificatele disponibile pentru client.

Cum validează browserele un lanț de certificate SSL

Browserele validează lanțurile de certificate în timpul strângerii de mână TLS pentru a determina dacă identitatea serverului poate fi de încredere.

Verificare nume de gazdă

Browserul verifică dacă domeniul solicitat se potrivește cu intrările SAN ale certificatului. Un certificat eliberat pentruexemplu.compoate să nu acoperemagazin.exemplu.comcu excepția cazului în care este inclus numele de gazdă suplimentar sau un wildcard corespunzător.

O nepotrivire a numelui de gazdă poate declanșa un avertisment de browser sau poate cauza respingerea conexiunii.

Verificarea semnăturii digitale

Semnăturile digitale ajută clienții să verifice integritatea și autenticitatea certificatului în cadrul căii de certificare. Clientul folosește cheia publică a certificatului emitent pentru a verifica semnătura de pe certificatul care este examinat.

Operațiunile criptografice sunt esențiale pentru acest proces. Pentru o explicație similară, citiți ghidul CyberLad pentruhashing în securitatea cibernetică.

Expirarea certificatului

Certificatele au perioade de valabilitate definite deNu înainteșiNu Dupăcâmpuri. Clientul verifică dacă certificatele relevante sunt valabile la momentul verificării.

O frunză expirată sau un certificat intermediar poate împiedica validarea cu succes. Administratorii ar trebui să monitorizeze datele de expirare și să confirme că certificatele reînnoite au fost instalate corect.

Magazin de încredere și calea certificatului

Clientul încearcă să construiască o cale validă de la certificatul frunză prin certificatele intermediare până la o ancoră de încredere acceptabilă. De asemenea, verifică constrângerile aplicabile privind certificatele și cerințele cheie de utilizare.

Magazinele de încredere variază în funcție de sistemul de operare, browser și aplicație. Este posibil ca un certificat de încredere într-un mediu să nu fie de încredere în altul.

Revocarea certificatului

Certificatele pot fi revocate înainte de data de expirare dacă cheile lor private sunt compromise sau dacă alte condiții necesită revocare. Autoritățile de certificare pot publica informații de revocare prin Listele de revocare a certificatelor (CRL) sau Protocolul de stare a certificatelor online (OCSP).

Comportamentul de verificare a revocării variază de la un client la altul. Unii folosesc informații din cache sau mecanisme alternative, așa că validarea cu succes a lanțului nu înseamnă întotdeauna că fiecare client a efectuat verificări identice de revocare.

Erori comune ale lanțului de certificate SSL și cauzele lor

Erorile de lanț de certificate apar atunci când un client nu poate valida certificatul prezentat de un server. Identificarea erorii specifice este esențială, deoarece fiecare problemă necesită o remediere diferită.

1. Lanț de certificate incomplet

Un lanț incomplet apare atunci când serverul nu oferă un certificat intermediar necesar și clientul nu poate construi o cale de încredere folosind alte certificate disponibile.

Cauzele comune includ lipsa certificatelor intermediare, pachetele de certificate incorecte și modificările de configurare în urma unei migrări de server.

Cum se remediază:Obțineți certificatele intermediare corecte de la autoritatea dvs. de certificare și configurați serverul să prezinte certificatul de frunză urmat de intermediarii necesari.

2. Autoritate de certificare neîncrezătoare

Un client poate respinge un lanț atunci când nu poate conecta certificatul la o ancoră de încredere acceptabilă. Acest lucru se poate întâmpla cu certificate autosemnate sau certificate CA private care nu au fost instalate în depozitul de încredere al clientului.

Cum se remediază:Utilizați un CA de încredere public pentru site-urile web publice. Pentru aplicațiile interne, distribuiți certificatul rădăcină al organizației printr-un proces aprobat de gestionare a încrederii. Nu instalați niciodată un certificat rădăcină necunoscut doar pentru a ocoli un avertisment.

3. Certificat expirat

O frunză expirată sau un certificat intermediar poate împiedica validarea cu succes.

Cum se remediază:Verificați datele de valabilitate, reînnoiți sau înlocuiți certificatul afectat și asigurați-vă că lanțul de certificate actualizat este instalat la fiecare punct de terminare TLS relevant.

4. Numele gazdei nu se potrivește

O nepotrivire a numelui de gazdă apare atunci când domeniul solicitat nu este acoperit de intrările SAN ale certificatului.

Cum se remediază:Instalați un certificat care acoperă numele de gazdă solicitat. Examinați setările gazdei virtuale, indicația numelui serverului (SNI) și legăturile certificatelor de echilibrare a încărcăturii.

5. Pachet de certificate incorect

Un server poate prezenta un certificat intermediar greșit sau un pachet de certificate comandat incorect.

Cum se remediază:Comparați emitentul certificatului frunză cu certificatele intermediare configurate. Corectați pachetul și testați configurația serverului înainte de a reîncărca serviciul.

6. Revocare sau alte eșecuri de validare

Un certificat poate eșua validarea deoarece a fost revocat sau nu îndeplinește o altă cerință de certificat aplicabilă.

Cum se remediază:Verificați starea certificatului și consultați instrucțiunile CA emitente. Înlocuiți un certificat revocat și investigați cauza. Dezactivarea verificării certificatului nu este o soluție sigură.

Cum să verificați un lanț de certificate SSL

Puteți inspecta lanțul de certificate al unui site web public utilizând un serviciu de testare online sau instrumente de linie de comandă.

Metoda 1: Folosiți SSL Labs

Qualys SSL Labs SSL Server Test analizează serverele TLS accesibile public și raportează problemele legate de certificat și de configurare.

1. Deschideți pagina de testare SSL Labs.

2. Introduceți domeniul pe care doriți să îl inspectați.

3. Rulați testul și așteptați analiza.

4. Examinați detaliile certificatului și informațiile lanțului.

5. Investigați avertismentele despre încredere, expirare, intermediari lipsă sau validarea numelui de gazdă.

SSL Labs este util pentru testarea externă fără a instala software suplimentar. Evitați să trimiteți nume de gazdă sau sisteme interne sensibile, cu excepția cazului în care politicile organizației dvs. permit utilizarea unui serviciu extern.

Metoda 2: Inspectați certificatele cu OpenSSL

OpenSSL poate afișa certificate prezentate de un server în timpul unei conexiuni TLS. Aleargă:

openssl s_client -connect example.com:443 \
  -servername example.com \
  -showcerts

Înlocuieșteexemplu.comcu domeniul tinta.

Cel-conectațiopțiunea specifică destinația și portul. Cel-nume serveropțiunea trimite numele de gazdă prin SNI, în timp ce-certe de spectacolafișează certificatele trimise de server.

Important:Afișarea certificatelor nu dovedește că lanțul este de încredere. Utilizați opțiunile de verificare pentru a verifica calea certificatului și numele gazdei.

Metoda 3: Verificați lanțul și numele gazdei

Rulați următoarea comandă pentru a solicita verificarea certificatului și verificarea numelui de gazdă:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_return_error \
  -verify_hostname example.com

Căutați un rezultat de verificare reușit, cum ar fiVerificați codul de returnare: 0 (ok). Ieșirea exactă depinde de versiunea OpenSSL, de depozitul de încredere și de setările de verificare.

Cel-verify_return_erroropțiunea face ca erorile de verificare să fie returnate în loc să permită comenzii să continue după ele. Vezidocumentația oficială OpenSSL s_client.

Metoda 4: Inspectați detaliile emitentului și expirării

Dacă ați salvat certificatul de frunză ca fișier PEM, rulați:

openssl x509 -in certificate.pem -noout \
  -subiect -emitent -date

Aceasta afișează subiectul certificatului, emitentul și datele de valabilitate. Utilizați rezultatul pentru a verifica dacă emitentul corespunde CA așteptată și dacă certificatul se află în perioada de valabilitate a acestuia.

Cum să remediați un lanț de certificate SSL incomplet

Repararea unui lanț incomplet implică, în general, identificarea intermediarului lipsă, obținerea pachetului corect de certificate, configurarea punctului final TLS și testarea rezultatului.

Pasul 1: Identificați intermediarul lipsă

Rulați comanda OpenSSL de mai sus sau utilizați SSL Labs pentru a examina lanțul. Verificați ce certificate trimite serverul și dacă clientul poate construi o cale de încredere.

Eșecul verificării nu înseamnă întotdeauna că lipsește un intermediar. De asemenea, investigați expirarea, nepotrivirile numelor de gazdă și problemele legate de depozitul de încredere.

Pasul 2: Obțineți pachetul de certificate corecte

Descărcați certificatele intermediare necesare de pe site-ul oficial al autorității dvs. de certificare sau de pe portalul de gestionare a certificatelor. Confirmați că certificatele corespund emitentului certificatului dvs. de frunză.

Certificatul rădăcină este în mod normal deja disponibil în depozitul de încredere al clientului și, în general, nu trebuie să fie inclus în pachetul de certificate al serverului.

Pasul 3: Configurați Nginx

Pentru Nginx, fișierul de certificat ar trebui să conțină mai întâi certificatul de frunză, urmat de certificatele intermediare necesare.

server {
    asculta 443 ssl;
    nume_server example.com;

    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
}

Căile sunt exemple. Utilizați locațiile corecte pentru mediul dvs. și asigurați-vă că cheia privată este protejată de permisiunile corespunzătoare.

Testați configurația înainte de a reîncărca Nginx:

sudo nginx -t

Pasul 4: Verificați Apache și alte puncte finale TLS

Configurațiile Apache pot folosiSSLCertificateFilesă furnizeze certificatul de frunză și certificatele intermediare necesare. Urmați documentația pentru versiunea și implementarea dvs. Apache.

Dacă HTTPS se termină la un proxy invers, o rețea de livrare de conținut, un firewall pentru aplicații web sau un echilibrator de încărcare, verificați certificatul instalat la nivelul respectiv. Actualizarea numai a serverului de origine nu va remedia un certificat incorect furnizat de un proxy separat.

Pasul 5: Verificați remedierea

După ce ați făcut modificările, rulați din nou OpenSSL și SSL Labs. Confirmați că serverul prezintă certificatele așteptate și că clientul poate valida lanțul și numele de gazdă.

Pentru mediile cu mai multe servere sau puncte de terminare TLS, testați fiecare punct final relevant. Un rezultat de succes pe un server nu garantează că toate punctele finale au aceeași configurație.

Cele mai bune practici pentru lanțul de certificate SSL

Utilizați autorități de certificare de încredere

Utilizați CA de încredere public pentru site-urile web publice. Pentru aplicațiile interne, distribuiți încrederea CA privată în siguranță către clienții autorizați.

Reînnoire și monitorizare automată

Utilizați instrumente de gestionare a certificatelor acolo unde sunt acceptate și alertați administratorii înainte ca certificatele să expire. Verificați dacă certificatele reînnoite sunt efectiv implementate și furnizate de punctele finale relevante.

Protejați cheile private

Restricționați accesul la cheile private de certificat, stocați-le în siguranță și evitați expunerea lor în jurnale sau arhive publice. Dacă o cheie este compromisă, înlocuiți certificatul afectat și urmați procedurile adecvate de răspuns la incident și de revocare.

Validați după modificări de configurare

Testați lanțul de certificate după reînnoiri, migrări de server, modificări ale echilibrului de încărcare sau actualizări de proxy invers. Verificați potrivirea numelui de gazdă, expirarea, construcția lanțului și erorile de verificare.

Mențineți un inventar de certificate

Înregistrați proprietarii de certificate, domeniile, CA emitente, datele de expirare, locațiile de implementare și metodele de reînnoire. Un inventar centralizat ajută echipele să găsească rapid serviciile afectate în timpul întreruperilor.

Monitorizați certificatele terților

Problemele legate de certificate pot afecta serviciile de care depinde organizația dvs., nu doar propriul site web. Monitorizați punctele finale TLS externe importante, inclusiv furnizorii de identitate, gateway-urile de plată și API-urile. CyberLad explică acest risc mai larg înCinci riscuri de la terți Scannerul dvs. de vulnerabilități nu poate vedea.

Utilizați configurații TLS securizate

Un lanț de certificate valid este doar o parte a securității HTTPS. Utilizați versiuni TLS acceptate, setări criptografice adecvate și practici securizate de gestionare a cheilor. Un certificat de încredere nu garantează că o aplicație nu are vulnerabilități.

Concluzie

Un lanț de certificate SSL este o parte esențială a securității HTTPS, deoarece permite browserelor și altor clienți să valideze certificatul unui site web printr-o cale către o autoritate de certificare de încredere. Înțelegerea certificatelor frunză, intermediare și rădăcină îi ajută pe administratori să depaneze lanțurile incomplete, certificatele expirate și erorile de încredere. Monitorizarea regulată, configurarea corectă a serverului, gestionarea securizată a cheilor private și verificarea după implementare ajută la menținerea conexiunilor TLS fiabile. Urmând aceste practici, proprietarii de site-uri web și profesioniștii în securitate pot reduce întreruperile legate de certificate și pot îmbunătăți fiabilitatea infrastructurii lor HTTPS.

Întrebări frecvente

Ce este un lanț de certificate SSL?

Un lanț de certificate SSL este o secvență de certificate digitale care stabilește o cale de la certificatul unui site web la o autoritate de certificare rădăcină de încredere. Acesta include de obicei certificatul de frunză și unul sau mai multe certificate intermediare.

Care este diferența dintre un certificat rădăcină și un certificat intermediar?

Un certificat rădăcină acționează ca o ancoră de încredere atunci când este acceptat de client. Un certificat intermediar deleagă emiterea certificatului și conectează certificatul frunză la rădăcina de încredere.

Un server web trebuie să trimită certificatul rădăcină?

De obicei, nu. Serverul trimite în mod normal certificatul de frunză și certificatele intermediare necesare. În general, clientul are deja certificatul său rădăcină de încredere în magazinul său de încredere.

Cum pot verifica un lanț de certificate SSL?

UtilizațiSSL Labspentru a inspecta un site web public sau a rulaopenssl s_clientpentru a examina certificatele prezentate de un server. Includeți opțiunile de verificare a numelui de gazdă și a certificatului atunci când verificați dacă lanțul poate fi de încredere.

Ce cauzează un lanț de certificate SSL incomplet?

Cea mai frecventă cauză este lipsa unui certificat intermediar. Pachetele de certificate incorecte, configurațiile învechite și setările TLS inconsecvente pe servere pot împiedica, de asemenea, clienții să construiască o cale de certificare validă.

Cum repar un lanț de certificate incomplet?

Obțineți certificatele intermediare corecte de la CA, configurați serverul să prezinte certificatul de frunză urmat de intermediarii necesari și testați configurația actualizată. Pașii precisi depind de software-ul serverului și de punctul de terminare TLS.

Este un lanț de certificate SSL la fel cu un certificat SSL?

Nu. Un certificat conține informații despre identitatea unui site web și cheia publică. Lanțul este secvența de certificate folosită pentru a stabili o cale de încredere de la acel certificat la o ancoră de încredere acceptabilă.

Un lanț de certificate valid înseamnă că un site web este sigur?

Nu. Un lanț valid ajută la verificarea identității certificate a unui site web conform politicii de încredere a clientului. Nu garantează că site-ul web este legitim, lipsit de programe malware sau protejat împotriva vulnerabilităților aplicațiilor.