Erori SSL: Ce sunt și cum să le remediezi

O eroare SSL este ceea ce afișează un browser atunci când nu poate deschide o conexiune criptată de încredere către un site web. În locul paginii pe care ați solicitat-o, obțineți un ecran de avertizare și un cod scurt scris cu majuscule mici, ceva de genul NET::ERR_CERT_AUTHORITY_INVALID sau SSL_ERROR_NO_CYPHER_OVERLAP.

Acel cod este partea utilă, și majoritatea ghidurilor îl trec cu vederea. „Eroare SSL” nu este un termen tehnic, și niciun standard nu îl definește. Este denumirea uzuală pentru o întreagă familie de defecțiuni diferite, motiv pentru care sfaturile generice, precum ștergerea memoriei cache, remediază unele dintre ele și nu fac absolut nimic pentru restul.

Ce Este de Fapt o Eroare SSL

Când încărcați o adresă care începe cu https://, browserul dumneavoastră și serverul rulează o negociere scurtă numită handshake TLS înainte ca vreun conținut al paginii să fie transmis. Handshake-ul stabilește o versiune de protocol și un set de algoritmi de criptare, iar serverul își dovedește identitatea printr-un certificat. Dacă vreo parte din acest proces eșuează, browserul refuză să continue și vă arată o eroare în loc de pagină.

Merită să facem distincția între SSL și TLS aici, pentru că denumirea creează confuzie reală. SSL este protocolul original, și fiecare versiune a acestuia a fost declarată depășită de ani buni. Ceea ce vorbește de fapt browserul dumneavoastră este TLS. Cuvântul „SSL” supraviețuiește în denumirile produselor, în directivele de configurare și în codurile de eroare, motiv pentru care încă îl vedeți pretutindeni. Când o pagină sau un browser spune SSL, aceasta înseamnă aproape întotdeauna TLS.

Acest lucru este important pentru depanare pentru că definiția populară a unei erori SSL este prea restrictivă. Veți citi frecvent că o eroare SSL înseamnă că browserul nu a putut verifica certificatul site-ului. Acest lucru este adevărat pentru un grup de aceste erori și fals pentru restul. Un server care răspunde pe portul HTTPS cu text simplu, necriptat, produce o eroare SSL și nici nu trimite deloc un certificat. Două mașini care nu pot conveni asupra unui set de criptare produc o eroare înainte ca certificatul să fie luat în considerare. A începe de la certificat atunci când certificatul nu a fost niciodată problema este cel mai frecvent motiv pentru care oamenii petrec ore întregi pentru o remediere de cinci minute.

Care Etapă a Conexiunii a Eșuat

Fiecare conexiune HTTPS parcurge aceeași secvență, iar o eroare SSL este simplu punctul în care această secvență s-a întrerupt. Determinarea etapei restrânge imediat cauza, pentru că fiecare etapă are un set complet diferit de explicații.

1. Conexiunea nu a devenit niciodată TLS. Browserul dumneavoastră a inițiat o conexiune, iar ce a fost primit înapoi nu era TLS, sau cealaltă parte a închis conexiunea înainte de finalizarea handshake-ului. Niciun certificat nu este implicat, și niciun certificat nu trebuie înlocuit.
2. Handshake-ul a eșuat în timpul negocierii. Ambele părți vorbeau TLS, dar nu au putut conveni asupra unei versiuni de protocol, a unui set de criptare, sau a site-ului care era solicitat. Handshake-ul se întrerupe înainte ca certificatul să fie validat, și adesea înainte ca acesta să fie trimis.
3. Certificatul a fost primit și respins. Acesta este grupul la care oamenii se referă atunci când spun „eroare SSL”. Expirarea, acoperirea nume de gazdă, lanțul de încredere, revocarea și puterea semnăturii se încadrează aici.
4. Handshake-ul a avut succes, dar ceva de după acesta a eșuat. Conexiunea criptată a fost stabilită corect, apoi un strat ulterior s-a defectat. Certificatul este confirmat ca fiind valid până în acest punct, așa că înlocuirea lui nu schimbă nimic.

Nu trebuie să ghiciți în ce etapă vă aflați. Codul de eroare vă spune, iar secțiunea următoare corelează fiecare cod cu etapa sa.

Găsiți-vă Eroarea

Citiți codul afișat sub mesajul de avertizare. În Chrome și Edge, acesta se află scris cu majuscule mici sub „Conexiunea dumneavoastră nu este privată”. În Firefox, poate fi necesar să deschideți detaliile avansate de pe pagina de avertizare. Apoi găsiți-l mai jos.

Etapa 1: conexiunea nu a devenit niciodată TLS

• SSL_ERROR_RX_RECORD_TOO_LONG în Firefox înseamnă că serverul a răspuns unei solicitări HTTPS cu ceva care nu este TLS, aproape întotdeauna HTTP simplu servit pe portul 443. Este o problemă de configurare a serverului.
• PR_END_OF_FILE_ERROR în Firefox înseamnă că cealaltă parte a închis conexiunea înainte ca handshake-ul să se finalizeze. Cauza se află adesea între dumneavoastră și server, mai degrabă decât la vreuna dintre cele două capete.

Etapa 2: handshake-ul a eșuat în timpul negocierii

• ERR_SSL_PROTOCOL_ERROR este codul generic al Chrome pentru un handshake care a eșuat dintr-un motiv care nu a putut fi identificat cu precizie. Începeți aici dacă acesta este codul dumneavoastră, pentru că prima sarcină este restrângerea cauzei.
• SSL_ERROR_NO_CYPHER_OVERLAP este echivalentul din Firefox, la fel de general: apare pentru orice eșec fatal al handshake-ului raportat de server, indiferent de motivul real al serverului.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH este codul Chrome pentru aceeași clasă de eșec, generat pentru o listă scurtă și specifică de condiții de negociere.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT înseamnă că serverul a terminat intenționat handshake-ul pentru că numele de gazdă solicitat nu corespunde niciunui site configurat pe acesta. Nu se trimite niciun certificat, așa că certificatul nu este de vină.
• ERR_BAD_SSL_CLIENT_AUTH_CERT funcționează în direcția opusă față de toate celelalte erori de aici: site-ul a solicitat browserului dumneavoastră un certificat și l-a respins pe cel primit, sau nu a primit niciunul. Aceasta este într-adevăr remediată pe dispozitivul dumneavoastră.
• Eroarea Cloudflare 525 este un eșec de handshake pe un alt segment al traseului: între Cloudflare și serverul de origine din spatele acestuia, nu între browserul dumneavoastră și Cloudflare. Vizitatorii nu pot acționa pentru remediere.

Etapa 3: certificatul a fost primit și respins

Conexiunea dumneavoastră nu este privată este ecranul de avertizare al Chrome pentru întregul acest grup mai degrabă decât o cauză proprie, așa că dacă asta este tot ce aveți, citiți întâi codul de dedesubt.

Lanțul de încredere nu a putut fi construit. Browserul nu a putut asocia certificatul site-ului cu o rădăcină de încredere, de obicei pentru că serverul își trimite propriul certificat și omite certificatul intermediar de deasupra acestuia.

• NET::ERR_CERT_AUTHORITY_INVALID în Chrome și Edge.
• SEC_ERROR_UNKNOWN_ISSUER în Firefox, aceeași condiție sub o denumire diferită.
• Un certificat intermediar expirat, unde lanțul există, dar o legătură de mai sus a expirat.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, unde nu există niciun lanț pentru că certificatul s-a semnat singur.

Datele sau numele nu corespund. Certificatul este de încredere, dar nu se aplică acestui moment sau acestui nume de gazdă.

• NET::ERR_CERT_DATE_INVALID, unde certificatul a expirat sau nu este încă valid. Merită să știți că un ceas greșit pe propriul dispozitiv produce și acest lucru.
• NET::ERR_CERT_COMMON_NAME_INVALID, unde numele de gazdă nu este listat în certificat.
• DLG_FLAGS_SEC_CERT_CN_INVALID, aceeași problemă de nume de gazdă raportată de software construit pe vechea platformă web Windows, în principal modul Internet Explorer din Edge și aplicații de business specializate.

Certificatul este de încredere și valid, dar interzis dintr-un alt motiv.

• NET::ERR_CERT_REVOKED, unde Autoritatea de Certificare l-a anulat înainte de data expirării.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, unde certificatul nu a ajuns cu suficientă dovadă publică a emiterii.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, unde ceva din lanț este semnat cu SHA-1. Chrome actual poate raporta același certificat sub un cod diferit, dar condiția și remedierea rămân neschimbate.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, o coliziune în interiorul propriului depozit de certificate al Firefox, mai degrabă decât o defecțiune a conexiunii.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, care se aplică unui set foarte mic de domenii integrate în browser, așa că un site obișnuit nu îl poate produce.

Fișierul certificatului este eronat. Aceste două se găsesc pe server, nu într-un browser, și de obicei împiedică un site să servească deloc HTTPS.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, unde browserul nu a putut decoda certificatul trimis de server.
• O nepotrivire de modul, unde certificatul instalat nu corespunde cheii private instalate.

Etapa 4: handshake-ul a avut succes și ceva de după acesta a eșuat

Acestea sunt clasificate ca erori SSL din obișnuință. În fiecare caz, conexiunea criptată funcționa deja, așa că certificatul a fost validat cu succes, iar reemiterea lui nu va ajuta.

• ERR_SSL_BAD_RECORD_MAC_ALERT înseamnă că serverul a primit date criptate care nu au putut fi verificate, ceea ce se întâmplă după handshake, sub cheile de sesiune. Ceva de pe traseu corupe sau rescrie traficul.
• ERR_QUIC_PROTOCOL_ERROR este un eșec al QUIC, transportul care se află sub HTTP/3. Nu este o problemă de certificat, iar cauza obișnuită este un firewall sau un VPN care filtrează UDP.
• ERR_SPDY_PROTOCOL_ERROR este un eșec la nivelul HTTP/2, care se află peste un handshake TLS finalizat.
• Conținutul mixt este cazul particular: pagina s-a încărcat perfect prin HTTPS, apoi a solicitat o resursă prin HTTP simplu. Nu produce deloc o pagină de eroare, doar un lacăt retrogradat și scripturi sau imagini lipsă.

Erori denumite după un dispozitiv, nu după o etapă

Două platforme produc suficiente particularități proprii pentru a merita tratate separat, pentru că aceeași condiție de bază se comportă diferit pe acestea.

• Erori SSL pe iPhone și iPad, inclusiv mesajul „A apărut o eroare SSL și nu se poate realiza o conexiune securizată către server”. Setarea de dată și oră este primul lucru de verificat.
• Erori de conexiune SSL pe Android, unde Chrome și alte aplicații consultă depozite de încredere diferite, iar un certificat intermediar lipsă provoacă mai multe probleme decât pe un desktop.

Coduri care nu mai apar

Trei coduri sunt încă descrise pe larg, dar au fost eliminate din browserele care le produceau, așa că dacă citiți sfaturi despre unul dintre ele, verificați data acestuia. Condițiile din spatele a două dintre ele încă există sub alte denumiri.

• NET::ERR_CERT_SYMANTEC_LEGACY a fost eliminat în Chrome 136, lansat în aprilie 2025.
• ERR_SSL_VERSION_INTERFERENCE a fost eliminat în Chrome 76 în 2019, deși interferența pe care o descria încă se produce și acum apare diferit.
• ERR_SPDY_PROTOCOL_ERROR a fost redenumit ERR_HTTP2_PROTOCOL_ERROR în Chrome 77, tot în 2019. Eșecul pe care îl descrie este încă actual, motiv pentru care este listat sub etapa patru de mai sus.

Dacă Vizitați Site-ul

Majoritatea erorilor SSL trebuie remediate de site-ul web, și niciun efort pe propriul dispozitiv nu le va schimba. Există o listă scurtă de excepții reale, și merită să o parcurgeți înainte de a concluziona că site-ul este defect.

• Verificați ceasul. Validarea certificatului compară datele certificatului cu ora proprie a dispozitivului dumneavoastră. Un ceas greșit cu luni sau ani face ca fiecare certificat să pară invalid, și aceasta este cea mai frecventă cauză de pe partea vizitatorului.
• Încercați o a doua rețea. Trecerea de la Wi-Fi la date mobile, sau invers, vă spune în câteva secunde dacă ceva din rețea interceptează traficul. Wi-Fi-ul public și cel din hoteluri sunt vinovați frecvenți.
• Dezactivați temporar scanarea HTTPS. Produsele antivirus și proxy-urile corporative inspectează traficul criptat prin substituirea propriilor certificate. Când o fac defectuos, obțineți o eroare SSL pe site-uri care funcționează perfect altundeva.
• Încercați o fereastră privată și un alt browser. Dacă eroarea apare într-un browser și nu în altul, cauza este de obicei locală, într-o extensie sau în date stocate. Dacă apare în toate, este vorba de site.

Dacă nimic din acestea nu ajută, problema se află pe server, iar răspunsul sincer este că nu o puteți remedia. Acest lucru se aplică integral erorii Cloudflare 525, unde eșecul se produce pe o conexiune din care browserul dumneavoastră nu face parte.

Browserele oferă într-adevăr o modalitate de a continua dincolo de majoritatea avertismentelor de certificat, și merită să fie clar ce costă acest lucru. Continuarea îi spune browserului să accepte o conexiune a cărei identitate nu a putut fi verificată, ceea ce înseamnă că nu aveți nicio garanție că vorbiți cu site-ul pe care l-ați tastat, mai degrabă decât cu ceva intermediar. Acesta este un compromis acceptabil pe un server de testare pe care îl controlați. Nu este acceptabil pe nimic în care veți introduce o parolă sau un detaliu de plată. Unele erori nu oferă deloc o cale de continuare, și acest lucru este deliberat, nu o defecțiune.

Dacă Administrați Site-ul Web

Diagnosticați înainte de a schimba orice. Reinstalarea unui certificat care nu a fost niciodată problema este modul obișnuit în care o oră se transformă într-o după-amiază.

Începeți cu o verificare externă

Verificați domeniul cu SSL Checker al nostru. Acesta raportează ce trimite serverul efectiv către lumea exterioară, ceea ce frecvent nu este ceea ce se află în fișierul de configurare. Un lanț care pare complet pe disc, dar ajunge incomplet la browser, este cea mai frecventă constatare, și este cauza din spatele atât a NET::ERR_CERT_AUTHORITY_INVALID, cât și a SEC_ERROR_UNKNOWN_ISSUER.

Puteți vedea același lucru din linia de comandă. Aceasta afișează fiecare certificat oferit de server, în ordinea în care le oferă:

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

Citiți lista de certificate din acel rezultat, nu linia Verify return code de la final. Acea linie este mult mai puțin informativă decât pare: raportează doar verdictul OpenSSL asupra lanțului, ignoră numele de gazdă cu excepția cazului în care solicitați explicit verificarea, și afișează 0 (ok) chiar și atunci când serverul nu a trimis deloc un certificat pentru că handshake-ul a fost întrerupt. Dacă rezultatul spune no peer certificate available în loc să afișeze o linie subject=, nimic nu a fost verificat și eșecul s-a produs mai devreme.

Verificați datele și numele de gazdă

Aceste două reprezintă o mare parte din respingerile de certificat. Pentru a citi fereastra de valabilitate a certificatului pe care îl servește serverul:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Browserele compară numele de gazdă cu extensia subjectAltName și ignoră complet Common Name, așa că acesta este câmpul de inspectat pe un fișier de certificat local:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Pentru a face OpenSSL să aplice verificarea numelui de gazdă pe care o aplică un browser, adăugați marcatorul, mai degrabă decât să presupuneți că un rezultat curat o acoperă:

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

Pe macOS aceste comenzi necesită atenție. openssl-ul livrat cu macOS este LibreSSL, și respinge -verify_hostname complet și raportează un rezultat sănătos pe unele lanțuri într-adevăr defecte. Instalați OpenSSL prin Homebrew, apoi rulați din nou openssl version pentru a confirma ce binar apelați efectiv. Dacă încă raportează LibreSSL, PATH-ul dumneavoastră găsește mai întâi copia de sistem, așa că apelați /opt/homebrew/bin/openssl cu calea sa completă.

Apoi remediați și verificați

Ce trebuie schimbat rezultă din etapă, iar ghidurile individuale la care se face legătura mai sus poartă pașii specifici platformei. Trei remedieri acoperă majoritatea cazurilor:

• Serviți lanțul complet. Concatenați certificatul dumneavoastră și certificatele intermediare furnizate de Autoritatea de Certificare în fișierul spre care indică serverul dumneavoastră. Nu puneți cheia privată în acel fișier.
• Reînnoiți înainte de expirare, și automatizați acest lucru. Durata de viață a certificatelor se reduce, așa că orice reînnoit manual va fi în cele din urmă reînnoit cu întârziere. Automatizarea ACME elimină termenul limită.
• Acoperiți fiecare nume de gazdă pe care îl serviți efectiv. Un certificat pentru un domeniu nu acoperă subdomeniile sale decât dacă este un certificat wildcard sau le listează.

Testați întotdeauna configurația înainte de a reîncărca serviciul, și rulați din nou verificarea ulterior din afara propriei rețele. O remediere confirmată doar în browserul în care ați testat nu este confirmată, pentru că acel browser poate reține un rezultat memorat în cache.

Cum să Preveniți Erorile SSL

Aproape fiecare eroare SSL pe un site web funcțional provine dintr-unul din trei lucruri: un certificat expirat, un lanț care nu a fost niciodată complet, sau o configurare care a derapat. Toate trei sunt prevenibile.

• Automatizați reînnoirea. Durata maximă de viață a certificatelor se reduce în etape în următorii câțiva ani, iar reînnoirea manuală nu mai este practică cu mult timp înainte de finalul acestei perioade. Automatizați acum, nu atunci când se defectează.
• Monitorizați expirarea independent. Un reminder în calendar eșuează atunci când persoana părăsește compania. O verificare externă care vă alertează cu săptămâni înainte nu eșuează.
• Verificați din nou după fiecare modificare. Migrările de server, schimbările de CDN și actualizările panoului de control rescriu în tăcere configurația certificatului. Verificați din exterior după aceea.
• Testați pe un telefon, nu doar pe un desktop. Platformele mobile sunt mai stricte cu privire la lanțurile incomplete, așa că o problemă de lanț apare adesea pe un telefon în timp ce desktopul pare în regulă.
• Instalați corect de la prima dată. Tutorialele noastre de instalare acoperă pașii pentru lanț și legare pe fiecare platformă, iar majoritatea erorilor de lanț provin din momentul instalării.

Întrebări Frecvente