Eroarea ERR_SSL_VERSION_OR_CIPHER_MISMATCH: ce înseamnă și cum se rezolvă

ERR_SSL_VERSION_OR_CIPHER_MISMATCH înseamnă că browserul și serverul nu au putut conveni asupra unei versiuni TLS compatibile și a unei suite de cifrare în timpul strângerii de mână SSL/TLS (handshake), astfel că browserul refuză să stabilească o conexiune HTTPS. În termeni practici, fie dispozitivul tău este prea vechi pentru setările TLS ale site-ului, fie configurația TLS a site-ului este defectă sau prea strictă. În experiența noastră rulând stive de găzduire în producție, această eroare este una dintre cele mai rapid de diagnosticat atunci când urmezi o listă de verificare strictă în loc să ștergi cache-uri la întâmplare.

Acest ghid îți arată un flux de lucru pas cu pas pentru a confirma unde se află problema (dispozitiv vizitator vs configurație server), cum să o reproduci cu instrumente de linie de comandă și cum să o repari pe setările comune de găzduire (Nginx, Apache și proxy-uri inverse). Include, de asemenea, câteva capcane operaționale pe care le vedem în timpul migrărilor, reînnoirilor AutoSSL și întăririi securității.

Ce înseamnă de fapt această eroare

Când deschizi https://domeniultau.com, browserul tău inițiază un handshake TLS. Browserul trimite un ClientHello care listează versiunile de protocol suportate (de exemplu TLS 1.2, TLS 1.3) și o listă de suite de cifrare pe care este dispus să le folosească. Serverul alege o versiune de protocol și o suită de cifrare din acea listă și răspunde cu un ServerHello, apoi lanțul de certificate, apoi detaliile schimbului de chei.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH apare atunci când acea negociere eșuează pentru că nu există suprapunere. Cele mai comune motive sunt:

• Serverul permite doar protocoale vechi (TLS 1.0 sau TLS 1.1) pe care browserele moderne refuză să le folosească.
• Serverul permite doar protocoale și cifruri moderne, dar un client vechi (OS vechi, dispozitiv încorporat, runtime Java vechi) nu le poate vorbi.
• Lista de cifruri a serverului este configurată greșit și ajunge să nu permită niciun cifru utilizabil pentru tipul de cheie ales (RSA vs ECDSA) sau build-ul OpenSSL.
• Un proxy invers sau un load balancer termină TLS cu o politică diferită decât se așteaptă backend-ul.
• Un middlebox (VPN, inspecție SSL antivirus, proxy corporativ) interferează și strică handshake-ul.

Distincție importantă: această eroare nu este aceeași cu o problemă de încredere a certificatului, cum ar fi un certificat expirat. Poți avea un certificat perfect valid și totuși să vezi ERR_SSL_VERSION_OR_CIPHER_MISMATCH dacă politica TLS a serverului este incompatibilă.

Mai întâi, află cine este defect

Înainte de a atinge configurația serverului, confirmă dacă problema este specifică unui dispozitiv sau se întâmplă global. Acest lucru contează deoarece reparația diferă complet.

1. Testează de pe alt dispozitiv și rețea: Deschide același URL de pe telefon folosind date mobile. Apoi încearcă dintr-un al doilea browser pe laptop. Dacă site-ul funcționează altundeva, serverul tău este probabil în regulă și dispozitivul sau rețeaua ta este problema.
2. Întreabă un resolver neutru: Dacă eroarea a început imediat după o schimbare DNS sau migrare, verifică mai întâi propagarea DNS. Un IP greșit poate trimite vizitatorii către un server vechi cu TLS învechit.
3. Verifică dacă doar un subdomeniu eșuează: exemplu.com funcționează, dar www.exemplu.com eșuează. Asta indică adesea o nepotrivire SNI sau vhost.

În coada noastră de suport, cel mai rapid indiciu este recunoașterea tiparelor. Dacă doar un utilizator raportează eroarea, este de obicei o problemă locală de stivă TLS. Dacă mai mulți utilizatori o raportează de pe diferiți ISP, este de obicei configurația TLS server-side sau o problemă de terminare proxy.

Reparații pentru vizitatori (client-side)

Dacă nu controlezi website-ul (sau suspectezi că propriul tău dispozitiv este excepția), acestea sunt reparațiile care rezolvă majoritatea cazurilor client-side.

1) Actualizează browserul și sistemul de operare

Site-urile moderne necesită de obicei TLS 1.2 sau TLS 1.3. Sistemele de operare vechi livrează biblioteci TLS și magazine rădăcină învechite. Actualizarea Chrome sau Firefox ajută, dar stiva cripto a OS-ului contează încă pe multe platforme. Dacă OS-ul tău este end-of-life, așteaptă-te la eșecuri de negociere TLS pe tot mai multe website-uri în timp.

2) Golește starea SSL (Windows) și repornește browserul

Windows memorează starea SSL și certificatele. Dacă configurația TLS a site-ului s-a schimbat recent, starea memorată învechită poate declanșa eșecuri ciudate de handshake. Golește starea SSL, apoi reîncearcă.

Pe Windows: Control Panel -> Internet Options -> Tab-ul Content -> Clear SSL state. Apoi închide complet browserul și redeschide-l.

3) Dezactivează VPN, proxy și scanarea HTTPS antivirus (temporar)

Unii clienți VPN și suite antivirus efectuează inspecție HTTPS. Ele interceptează TLS, emit un certificat local, apoi re-criptează traficul către destinație. Dacă politica lor cripto este învechită sau are bug-uri, ele strică negocierea și vezi ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Dezactivează aceste instrumente temporar pentru un test curat, apoi reactivează-le și ajustează setările dacă confirmi că ele au cauzat eroarea.

4) Comută pe un resolver DNS curat (test de sanitate)

Acest lucru nu repară direct negocierea TLS, dar ajută când DNS-ul ISP-ului tău te trimite către serverul greșit în timpul unei migrări. Ca un test rapid, setează DNS pe un resolver public, golește cache-ul DNS, apoi reîncearcă. Dacă eroarea dispare, probabil ai ajuns la un endpoint diferit cu o politică TLS diferită.

Reparații pentru proprietarii de site-uri (server-side)

Dacă deții site-ul și mai mulți vizitatori raportează problema, trateaz-o ca un incident de producție. O nepotrivire TLS blochează toate conversiile, autentificările, finalizările de comenzi și apelurile API prin HTTPS. Scopul este să identifici care endpoint termină TLS, apoi să validezi versiunile de protocol și suitele de cifrare suportate.

Pasul 1: Identifică endpoint-ul TLS real

Multe configurații nu termină TLS pe aceeași mașină care rulează aplicația web. Configurațiile comune includ un proxy invers în fața Apache, un load balancer în fața mai multor servere web, sau un panou de control de găzduire care gestionează șabloanele vhost. Trebuie să confirmi unde se întâmplă handshake-ul TLS înainte de a schimba configurațiile.

• Dacă folosești un proxy invers, verifică configurația sa mai întâi. Proxy-ul deține de obicei portul 443.
• Dacă folosești găzduire partajată, stiva platformei gestionează TLS (adesea prin AutoSSL). Modificările tale trebuie să se alinieze cu șabloanele platformei.
• Dacă folosești un VPS cu propriul Nginx sau Apache, deții întreaga politică TLS.

Insight operațional: în timpul migrărilor, echipele testează adesea serverul backend direct, apoi uită că traficul de producție lovește un endpoint TLS diferit. Proxy-ul ar putea rula încă OpenSSL vechi sau o politică de cifrare veche, chiar dacă backend-ul este modern.

Pasul 2: Reprodu handshake-ul din linia de comandă

Folosește OpenSSL pentru a testa exact ce negociază serverul și ce refuză. Include întotdeauna SNI cu -servername, altfel s-ar putea să lovești vhost-ul implicit și să obții rezultate înșelătoare.

# Test de handshake TLS de bază (cu SNI)
openssl s_client -connect domeniultau.com:443 -servername domeniultau.com

# Forțează TLS 1.2
openssl s_client -connect domeniultau.com:443 -servername domeniultau.com -tls1_2

# Forțează TLS 1.3
openssl s_client -connect domeniultau.com:443 -servername domeniultau.com -tls1_3

Ce să cauți în rezultat:

• Protocol: arată TLSv1.2 sau TLSv1.3 dacă negocierea a reușit.
• Cipher: arată suita de cifrare negociată.
• Cod de retur verificare: ar trebui să fie 0 (ok) pentru un lanț de încredere, dar chiar și cu un cod diferit de zero handshake-ul se poate completa încă. Acest articol se concentrează pe cazurile în care handshake-ul nu se completează.

Dacă TLS 1.2 eșuează și TLS 1.3 eșuează, probabil ai un listener TLS defect, căi greșite de certificat/cheie sau o problemă de proxy pe portul 443. Dacă TLS 1.2 funcționează dar TLS 1.3 eșuează, s-ar putea să ai o problemă de compatibilitate OpenSSL sau o nepotrivire de politică TLS 1.3. Dacă TLS 1.3 funcționează dar TLS 1.2 eșuează, probabil ai dezactivat TLS 1.2 și ai stricat clienții și integrările mai vechi.

Pasul 3: Confirmă protocoalele și cifrurile suportate

Browserele nu îți arată o listă ordonată cu ce suportă serverul. Folosește instrumente server-side sau scanere externe pentru a enumera protocoalele și cifrurile. Dacă preferi un instrument local, instalează testssl.sh pe o mașină Linux și rulează-l împotriva domeniului tău. Dacă preferi o verificare web rapidă, folosește un scaner TLS care listează suportul protocolului și suitele de cifrare.

Insight operațional: nu copia șiruri de cifruri aleatorii din postări de blog vechi. Vedem asta constant. Adminii lipesc o listă de cifruri pe care build-ul lor OpenSSL nu o suportă, reîncarcă Nginx și accidental se lasă cu o listă goală de cifruri pentru TLS 1.2. Serverul pornește, dar clienții nu pot negocia.

Cele mai comune cauze rădăcină server-side (și reparații)

Mai jos sunt cauzele rădăcină pe care le vedem cel mai des în mediile reale de găzduire, cu reparații care se aplică stivelor tipice de VPS și găzduire web.

Cauza 1: Serverul suportă doar TLS vechi (TLS 1.0 sau TLS 1.1)

Acest lucru se întâmplă pe servere vechi care nu au primit niciodată actualizări de întărire TLS, sau pe stive blocate pe pachete OS antice. Browserele moderne refuză să negocieze cu TLS 1.0 și TLS 1.1 pe majoritatea configurațiilor, deci handshake-ul eșuează și primești eroarea de nepotrivire.

Reparație: Activează TLS 1.2 și TLS 1.3, apoi reîncarcă serverul web. Pe Nginx:

# În interiorul blocului server relevant sau blocului http
ssl_protocols TLSv1.2 TLSv1.3;

Apoi reîncarcă Nginx în siguranță:

nginx -t && systemctl reload nginx

Pe Apache (mod_ssl), configurează SSLProtocol pentru a permite versiuni moderne și a dezactiva pe cele vechi:

# Exemplu Apache 2.4
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Dacă nu poți activa TLS modern din cauza constrângerilor OS, tratează acea mașină ca un risc de securitate și migrează. O soluție temporară este să plasezi un proxy invers modern în față, să termini TLS acolo și să faci proxy către backend printr-o rețea privată, dar planifică retragerea stivei vechi.

Cauza 2: Ai dezactivat TLS 1.2 și ai stricat integrările

Echipele întăresc uneori TLS permițând doar TLS 1.3. Asta poate fi în regulă pentru browsere moderne, dar poate strica aplicații mobile mai vechi, dispozitive încorporate, clienți API mai vechi și unele medii enterprise care încă se bazează pe TLS 1.2.

Reparație: Activează atât TLS 1.2 cât și TLS 1.3 dacă nu ai un mediu client foarte controlat:

ssl_protocols TLSv1.2 TLSv1.3;

Insight operațional: dacă rulezi un API folosit de terți, păstrează TLS 1.2 activat chiar dacă propriul frontend folosește TLS 1.3. Reduce overhead-ul de suport și evită întreruperile silențioase pentru clienți.

Cauza 3: Lista suitei de cifrare este goală sau incompatibilă

Un șir de cifruri prea strict sau defect poate elimina toate cifrurile TLS 1.2 utilizabile. Nginx și Apache pot porni încă, dar clienții nu pot negocia un cifru comun. Acest lucru se întâmplă adesea după o schimbare de întărire grăbită sau un copy-paste dintr-o configurație care vizează o versiune OpenSSL diferită.

Reparație: Folosește o politică de suită de cifrare rezonabilă pentru TLS 1.2 și permite implicitele TLS 1.3. Pentru Nginx, configurează cifrurile TLS 1.2 și preferă cifrurile serverului:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

Apoi validează și reîncarcă:

nginx -t && systemctl reload nginx

Pentru Apache, asigură-te că SSLCipherSuite nu este excesiv de restrictivă și că nu ai dezactivat toate cifrurile RSA în timp ce folosești un certificat RSA, sau ai dezactivat toate opțiunile ECDSA în timp ce folosești un certificat doar ECDSA.

Cauza 4: Nepotrivire SNI sau vhost (certificat și politică greșite)

Acest lucru apare când exemplu.com funcționează dar www.exemplu.com eșuează, sau când domeniul eșuează doar pe un IP în spatele unui load balancer. Fără o mapare Server Name Indication (SNI) corectă, serverul prezintă un vhost implicit. Acel vhost implicit poate avea TLS învechit, fișiere de certificat lipsă sau o politică de cifrare diferită.

Reparație: Confirmă că vhost-ul TLS include server_name corect și căile certificatului pentru fiecare hostname pe care îl servești, inclusiv www, api și orice subdomenii. Apoi testează cu SNI explicit:

openssl s_client -connect domeniultau.com:443 -servername www.domeniultau.com -tls1_2

Insight operațional: când echipele adaugă rapid un subdomeniu nou, uită uneori să emită sau să atașeze un certificat acelui vhost. Serverul apoi revine la un bloc TLS implicit și browserul raportează o nepotrivire sau eșec de handshake.

Cauza 5: Proxy invers și backend-ul nu sunt de acord asupra așteptărilor TLS

Dacă termini TLS pe un proxy invers (Nginx, HAProxy, sau un edge gestionat) și trimiți mai departe către un backend, backend-ul nu mai gestionează TLS pentru traficul public. Dar echipele încă schimbă configurațiile TLS backend și se așteaptă ca comportamentul public să se schimbe. Proxy-ul invers rămâne endpoint-ul TLS real și păstrează politica veche.

Reparație: Aplică schimbările de protocol și cifru TLS pe proxy-ul care ascultă pe 443. Apoi verifică cu openssl s_client de pe o mașină externă. De asemenea asigură-te că proxy-ul se conectează corect la backend. Dacă proxy-ul folosește HTTPS către backend, trebuie să aliniezi setările TLS la ambele capete.

Cauza 6: Stiva cripto a OS-ului tău este prea veche pentru configurația ta

Chiar dacă configurația serverului tău web arată corect, implementarea TLS subiacentă contează. Nginx și Apache se bazează pe OpenSSL (sau biblioteca TLS a platformei). Dacă distro-ul tău livrează un build OpenSSL vechi, s-ar putea să nu primești suport TLS 1.3, cifruri moderne sau curbe moderne.

Reparație: Actualizează pachetele OS, sau migrează sarcina de lucru pe o versiune OS curentă. Dacă rulezi sarcini critice de afaceri, nu trata actualizările OS ca fiind opționale. Suportul TLS învechit devine o întrerupere vizibilă pentru clienți, nu doar o îngrijorare de securitate.

Checklist rapid pentru un incident de producție

Dacă site-ul tău este picat pentru vizitatori cu ERR_SSL_VERSION_OR_CIPHER_MISMATCH, folosește acest flux de incident. Este conceput să minimizeze ghicitul.

1. Confirmă aria de acoperire: Eșuează pe multiple dispozitive și rețele?
2. Confirmă că DNS indică către serverul așteptat: Indicarea greșită trimite adesea clienții către o cutie veche cu TLS moștenit.
3. Identifică endpoint-ul TLS: Server direct, proxy invers, load balancer sau platformă de găzduire.
4. Rulează teste openssl conștiente de SNI: tls1_2 și tls1_3, înregistrează Protocol și Cipher.
5. Verifică jurnalele de eroare ale serverului web: Caută eșecuri de handshake și erori de încărcare certificat.
6. Validează sintaxa configurației: nginx -t sau apachectl configtest înainte de reîncărcare.
7. Revino dacă este necesar: Dacă o schimbare de întărire a cauzat întreruperea, revino la ultima politică TLS bună cunoscută, apoi întărește din nou mai atent.

Insight operațional: păstrează un fragment TLS "ultim bun cunoscut" în controlul versiunii. Când cineva face o schimbare agresivă de cifru la 2 AM, vrei o cale de revenire curată.

Cum previne ServerSpan de obicei acest lucru

Pe platformele de găzduire gestionată, această clasă de întrerupere TLS vine de obicei din editări manuale ad-hoc și șabloane inconsistente. Pe găzduirea web ServerSpan, platforma include Auto-SSL și o stivă standardizată astfel încât nu ajungi cu un vhost pe TLS modern și altul blocat pe setări moștenite. Acea consistență este ceea ce previne situațiile "funcționează pe un subdomeniu dar nu pe celălalt" când găzduiești site-uri multiple.

Dacă rulezi propriul VPS și vrei aceeași consistență, tratează TLS ca parte a întăririi tale de bază. Folosește o politică Nginx sau Apache predictibilă, testează după fiecare schimbare și păstrează configurațiile sub controlul versiunii. Dacă vrei o echipă practică să auditeze și să repare întregul lanț (politică TLS, implementare certificat, terminare proxy și reînnoiri), explorează serviciile de administrare Linux sau mută site-urile de producție pe găzduire web gestionată unde platforma se ocupă de părțile repetitive și tu te concentrezi pe afacerea ta.

Dacă planifici momentan o migrare, revizuiește de asemenea serverele virtuale pentru sarcini de lucru care necesită control root complet dar beneficiază totuși de infrastructură stabilă și rețelistică predictibilă.

Punct de decizie: păstrezi compatibilitatea sau mergi pe strict

După ce repari întreruperea, decide cât de strict vrei să fii. Politicile TLS stricte reduc suprafața de atac, dar renunță și la suportul pentru clienți moșteniți. Pentru website-uri publice, o bază practică este TLS 1.2 și TLS 1.3 cu cifruri puternice. Pentru aplicații enterprise interne, poți merge mai strict dacă controlezi clienții. Pentru API-uri folosite de terți, planifică pentru compatibilitate maximă în timp ce rămâi sigur.

Dacă nu ești sigur ce clienți depind încă de TLS mai vechi, colectează dovezi înainte de a-i tăia. Revizuiește jurnalele de acces, distribuția user-agent și versiunile client API. Apoi ajustează politica TLS intenționat în loc să descoperi cerințele de compatibilitate prin întreruperi.