Cum să Remediați Eroarea „Acest Site Nu Poate Furniza o Conexiune Securizată”

Eroarea "This site can't provide a secure connection" înseamnă că browserul dvs. nu a reușit să finalizeze un handshake TLS cu serverul țintă. Tentativa de conexiune a fost întreruptă înainte ca orice canal criptat să poată fi stabilit, lăsând browserul incapabil să verifice identitatea serverului sau să negocieze un cipher suite.

Această eroare apare în Chrome, Firefox, Edge și Safari și este aproape întotdeauna însoțită de un cod de eroare specific — cel mai frecvent ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH sau SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Fiecare cod indică un nivel distinct de defecțiune: configurația certificatului serverului, stiva TLS a clientului sau calea de rețea dintre acestea. Identificarea nivelului responsabil înainte de a modifica orice setare vă va economisi timp considerabil.

Ce se întâmplă de fapt în timpul unui handshake TLS

Înainte de a trece la soluții, este important să înțelegeți mecanismul de defecțiune. Când browserul dvs. se conectează la un site HTTPS, efectuează un handshake TLS în milisecunde:

1. Browserul trimite un mesaj ClientHello care anunță versiunile TLS și cipher suite-urile suportate.
2. Serverul răspunde cu un ServerHello, selectând o versiune de protocol și un cipher, apoi prezentând lanțul său de certificate.
3. Browserul validează certificatul față de Autoritățile de Certificare (CA) rădăcină de încredere, verifică data de expirare, confirmă că domeniul corespunde cu Subject Alternative Name (SAN) și confirmă că certificatul nu a fost revocat (prin OCSP sau CRL).
4. Ambele părți derivă cheile de sesiune și încep comunicarea criptată.

O defecțiune la oricare dintre acești patru pași produce mesajul "can't provide a secure connection". Codul de eroare din panoul de detalii al browserului vă indică exact care pas a eșuat.

Cauze principale mapate la coduri de eroare

Dacă codul de eroare plasează responsabilitatea pe administratorul serverului și nu controlați serverul, opțiunile dvs. sunt limitate la contactarea proprietarului site-ului. Secțiunile rămase se concentrează pe erorile pe care le puteți rezolva pe partea clientului, urmate de remedierea pe partea serverului pentru administratori.

Soluții pe partea clientului

1. Verificați certificatul înainte de a modifica orice

Faceți clic pe lacăt (sau pe pictograma de avertizare) din bara de adrese și selectați Conexiunea este securizată > Certificatul este valid. Verificați:

• Perioada de valabilitate: Data „Not After” trebuie să fie în viitor.
• Emis pentru: Domeniul din câmpul SAN al certificatului trebuie să corespundă exact cu URL-ul, inclusiv subdomeniile.
• Emis de: Lanțul CA trebuie să se termine la o CA rădăcină în care sistemul dvs. de operare are încredere.

Dacă certificatul este expirat sau nepotrivit și nu dețineți serverul, opriți-vă aici și contactați proprietarul site-ului. Dacă administrați serverul, treceți la secțiunea de pe partea serverului de mai jos.

2. Sincronizați data și ora sistemului

Validarea certificatelor este sensibilă la timp. Un ceas al sistemului care este chiar și cu câteva minute în urmă poate determina browserul să concluzioneze că un certificat valid este expirat sau că un certificat care nu este încă valid este utilizat prematur.

Windows:

w32tm /resync /force

Alternativ, faceți clic dreapta pe ceasul sistemului, selectați Ajustare dată/oră și activați Setare automată a orei cu serviciul Windows Time.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Deschideți Setări sistem > General > Dată și oră și activați Setare automată a datei și orei.

După sincronizare, reporniți browserul și testați din nou.

3. Ștergeți starea SSL și memoria cache a browserului

Browserele stochează în cache rezultatele validării certificatelor și politicile HSTS (HTTP Strict Transport Security). O intrare cache învechită poate bloca accesul chiar și după ce o problemă de certificat pe partea serverului a fost rezolvată.

Chrome — ștergere date de navigare:

Navigați la chrome://settings/clearBrowserData, selectați Tot timpul, bifați Cookie-uri și alte date de site și Imagini și fișiere în cache, apoi faceți clic pe Ștergere date.

Chrome — ștergere intrare HSTS pentru un domeniu specific:

Navigați la chrome://net-internals/#hsts, introduceți domeniul sub Ștergere politici de securitate domeniu și faceți clic pe Ștergere. Acest lucru este deosebit de util când un domeniu era anterior exclusiv HTTPS și acum este configurat greșit.

Windows — ștergere stare SSL la nivel de sistem de operare:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Aceasta șterge memoria cache a certificatelor utilizată de Internet Explorer, Edge (versiunea veche) și unele aplicații Windows.

Firefox: Navigați la about:preferences#privacy, derulați până la Cookie-uri și date de site și faceți clic pe Ștergere date.

4. Dezactivați inspecția HTTPS a antivirusului

Produsele de securitate de la furnizori precum Avast, AVG, Kaspersky, ESET și Bitdefender efectuează interceptarea SSL/TLS — acționează ca un proxy local man-in-the-middle, re-semnând certificatele cu propria lor CA rădăcină. Când CA-ul lor rădăcină nu este instalat corect în magazinul de încredere al browserului sau când modulul de interceptare are erori, fiecare conexiune HTTPS eșuează.

Pentru a testa dacă aceasta este cauza:

1. Dezactivați temporar funcția Web Shield, Scanare HTTPS sau Filtrare SSL din setările antivirusului.
2. Reîncărcați pagina care prezintă eroarea.
3. Dacă eroarea dispare, antivirusul este vinovatul.

Soluția permanentă este să adăugați domeniul afectat în lista de excluderi a antivirusului, mai degrabă decât să dezactivați scanarea HTTPS global, ceea ce ar reduce nivelul dvs. de securitate.

5. Actualizați browserul

TLS modern necesită suport pentru cel puțin TLS 1.2 din partea browserului, și TLS 1.3 pentru securitate optimă. Browserele mai vechi decât aproximativ Chrome 70, Firefox 63 sau Edge 79 pot lipsi suportul pentru TLS 1.3 sau pot avea erori cunoscute de handshake.

Chrome:

Navigați la chrome://settings/help. Chrome verifică actualizările automat și le instalează la repornire.

Firefox:

Navigați la about:support, apoi Verificare actualizări din meniul Ajutor.

Menținerea browserului actualizat asigură, de asemenea, că magazinul de CA rădăcină integrat al browserului este actualizat, ceea ce contează pentru certificatele emise de CA-uri mai noi.

6. Auditați setările protocolului TLS în browser

Chrome și Edge (bazate pe Chromium):

Aceste browsere nu expun comutatoare de versiune TLS în interfața utilizator începând cu Chrome 84. TLS 1.0 și 1.1 sunt dezactivate permanent. Dacă un site necesită TLS 1.0 sau 1.1, site-ul trebuie actualizat — nu există nicio soluție alternativă pe partea clientului și nici nu ar trebui să existe.

Pentru a verifica flag-urile TLS experimentale, navigați la chrome://flags și căutați TLS. În majoritatea versiunilor de producție, nu vor apărea flag-uri acționabile.

Firefox:

Navigați la about:config și căutați security.tls.version.min. Valoarea ar trebui să fie 3 (corespunzând TLS 1.2). Setarea la 1 sau 2 pentru a acomoda un server defect reprezintă un risc de securitate și ar trebui făcută doar în medii de testare izolate.

Internet Explorer / Edge vechi:

Navigați la Opțiuni Internet > Avansat > Securitate și asigurați-vă că Utilizare TLS 1.2 și Utilizare TLS 1.3 sunt bifate. Debifați Utilizare SSL 3.0, Utilizare TLS 1.0 și Utilizare TLS 1.1.

7. Dezactivați sau auditați extensiile browserului

Extensiile cu acces la rețea — în special VPN-urile, blocantele de reclame, instrumentele de confidențialitate și comutatoarele de proxy — pot intercepta sau modifica conexiunile TLS. Pentru a izola un conflict de extensie:

Navigați la chrome://extensions/ și dezactivați toate extensiile. Reîncărcați pagina care prezintă eroarea. Dacă eroarea se rezolvă, reactivați extensiile una câte una, reîncărcând după fiecare, până când extensia vinovată este identificată.

8. Schimbați rezolvatorul DNS

DNS nu afectează direct TLS, dar un rezolvator DNS care returnează adrese IP incorecte (din cauza otrăvirii, filtrării sau interferenței ISP) poate direcționa browserul dvs. către un server care prezintă un certificat pentru domeniul greșit, cauzând o eroare ERR_CERT_COMMON_NAME_INVALID.

Trecerea la un rezolvator public elimină manipularea DNS la nivel de ISP:

Windows — schimbare DNS prin PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Înlocuiți "Ethernet" cu numele real al interfeței dvs. (utilizați Get-NetAdapter pentru a lista interfețele).

Linux:

sudo nano /etc/resolv.conf

Adăugați:

nameserver 1.1.1.1
nameserver 8.8.8.8

Rezolvatoare publice recomandate:

9. Resetați stiva de rețea (Windows)

Un catalog Winsock corupt sau o stivă TCP/IP defectă poate cauza defecțiuni TLS intermitente care par necorelate cu certificatele. Rulați următoarele ca Administrator:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Reporniți mașina după rularea tuturor celor cinci comenzi. Nu omiteți repornirea — netsh winsock reset în special necesită o repornire pentru a intra în vigoare.

Soluții pe partea serverului pentru administratori

Dacă administrați serverul web care prezintă certificatul, următoarele sunt cele mai frecvente cauze pe partea serverului și remedierea lor.

Certificat SSL expirat sau configurat greșit

Un certificat expirat este cea mai frecventă cauză a acestei erori la nivel de server. Dacă rulați un site într-un mediu de VPS Hosting, reînnoirea certificatelor ar trebui automatizată.

Verificați expirarea certificatului din linia de comandă:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Automatizați reînnoirea cu Certbot (Let's Encrypt):

sudo certbot renew --dry-run

Adăugați un job cron sau un timer systemd pentru a rula certbot renew de două ori pe zi — certificatele Let's Encrypt expiră la fiecare 90 de zile, iar Certbot reînnoiește doar când mai rămân mai puțin de 30 de zile.

0 0,12 * * * root certbot renew --quiet

Dacă aveți nevoie de un certificat validat comercial cu validare extinsă sau acoperire wildcard, Certificatele SSL de la o CA de încredere oferă lanțul de încredere necesar pentru toate browserele majore.

Lanț de certificate incomplet

O configurare greșită foarte frecventă: serverul prezintă doar certificatul entității finale fără certificatele CA intermediare. Browserul nu poate construi o cale de încredere către o CA rădăcină pe care o recunoaște, rezultând în ERR_CERT_AUTHORITY_INVALID.

Diagnosticați cu SSL Labs:

Rulați domeniul dvs. prin SSL Labs Server Test (instrument extern). O problemă de lanț va fi semnalată imediat.

Remediere pe Nginx:

Directiva ssl_certificate trebuie să indice un fișier care conține lanțul complet — certificatul dvs. urmat de toate certificatele intermediare:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Remediere pe Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Versiuni TLS depreciate și cipher suite-uri slabe

Browserele au eliminat suportul pentru TLS 1.0 și TLS 1.1. Dacă serverul dvs. oferă doar aceste versiuni de protocol, browserele moderne vor refuza complet conexiunea.

Configurație TLS recomandată pentru Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Configurație TLS recomandată pentru Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

După modificarea configurației serverului, testați cu:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Nepotrivire de domeniu a certificatului

Dacă certificatul dvs. acoperă www.example.com dar utilizatorii accesează example.com (sau invers), browserul va raporta o nepotrivire de domeniu. Soluția corectă este să emiteți un certificat cu ambele nume în câmpul SAN sau să utilizați un certificat wildcard (*.example.com).

Când configurați un domeniu nou într-un mediu de Servere Dedicate, verificați întotdeauna că câmpul SAN acoperă fiecare variantă de hostname la care serverul va răspunde înainte de a trece în producție.

Blocarea conținutului mixt

O pagină încărcată prin HTTPS care face referire la resurse HTTP (imagini, scripturi, foi de stil) declanșează avertismente de conținut mixt. Deși aceasta nu produce direct eroarea „can't provide a secure connection”, poate cauza defecțiuni parțiale ale paginii care sunt diagnosticate greșit ca erori TLS.

Auditați conținutul mixt cu:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Compararea cauzelor pe partea clientului față de cele pe partea serverului

Considerații privind mediul de hosting

Mediul de hosting pe care îl utilizați influențează direct cât de ușor puteți rezolva problemele TLS pe partea serverului.

Pe Hosting Web Partajat, gestionarea certificatelor este de obicei realizată prin panoul de control. Majoritatea platformelor moderne de hosting partajat includ integrare gratuită Let's Encrypt, dar aveți control limitat asupra setărilor protocolului TLS la nivel de server.

Pe un VPS cu cPanel, obțineți acces la AutoSSL pentru provizionarea automată a certificatelor și puteți configura direct setările TLS Apache sau Nginx. Acesta este mediul recomandat pentru site-urile unde precizia configurației TLS contează.

Pe Servere Dedicate bare-metal, aveți control deplin asupra întregii stive TLS — versiunea OpenSSL, selecția cipher suite-urilor, OCSP stapling, preîncărcarea HSTS și fixarea certificatelor — dar sunteți, de asemenea, pe deplin responsabil pentru menținerea configurației actualizate.

Listă de verificare practică pentru decizie

Utilizați această listă de verificare pentru a tria eroarea sistematic, mai degrabă decât a aplica soluții la întâmplare:

• Eroarea apare pe toate site-urile HTTPS sau doar pe unul?
• Toate site-urile: concentrați-vă pe ceasul sistemului, scanarea HTTPS a antivirusului, actualizarea browserului, magazinul CA rădăcină al sistemului de operare.
• Un singur site: problema este aproape sigur pe partea serverului.

• Ce indică codul de eroare specific?
• ERR_CERT_DATE_INVALID: verificați mai întâi ceasul sistemului, apoi expirarea certificatului.
• ERR_CERT_AUTHORITY_INVALID: verificați completitudinea lanțului de certificate.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: serverul rulează TLS depreciat sau cipher-uri nesuportate.
• ERR_CERT_COMMON_NAME_INVALID: SAN-ul certificatului nu corespunde cu domeniul.

• Eroarea dispare pe o rețea diferită?
• Da: firewall-ul, proxy-ul sau inspecția TLS la nivel de ISP este cauza.

• Eroarea dispare cu antivirusul dezactivat?
• Da: configurați o excludere pentru domeniu în setările de scanare HTTPS ale antivirusului.

• Sunteți administratorul serverului?
• Rulați diagnostice openssl s_client și testul SSL Labs înainte de a atinge orice fișier de configurare.
• Automatizați reînnoirea certificatelor imediat după rezolvarea problemei imediate.

Întrebări frecvente

De ce apare „This site can't provide a secure connection” doar pe un singur site?

Când eroarea este izolată la un singur domeniu, cauza principală este aproape întotdeauna pe partea serverului: un certificat expirat, un lanț de certificate incomplet, o nepotrivire a numelui de domeniu în câmpul SAN al certificatului sau serverul configurat să utilizeze doar versiuni TLS depreciate (1.0 sau 1.1) pe care browserele moderne nu le mai acceptă.

Poate un VPN cauza această eroare?

Da. Unii clienți VPN rutează interogările DNS prin propriile rezolvatoare sau efectuează inspecție a traficului care interferează cu handshake-urile TLS. Dacă eroarea apare doar când VPN-ul este activ, dezactivați funcția „split tunneling” sau „inspecție SSL” a VPN-ului sau adăugați domeniul afectat ca excludere.

Ștergerea cache-ului rezolvă întotdeauna erorile SSL?

Nu. Ștergerea cache-ului rezolvă erorile cauzate de politici HSTS învechite sau răspunsuri de certificate invalide stocate în cache. Nu are niciun efect asupra problemelor de certificate pe partea serverului, problemelor de ceas al sistemului sau interceptării antivirusului. Utilizați ștergerea cache-ului ca prim pas, nu ca soluție universală.

Cum verific dacă certificatul SSL al serverului meu este configurat corect fără un browser?

Utilizați OpenSSL de pe orice mașină cu acces la rețea:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Rezultatul afișează lanțul complet de certificate, versiunea TLS negociată, cipher suite-ul selectat și orice erori de verificare. Aceasta este cea mai fiabilă metodă de diagnosticare pentru problemele TLS pe partea serverului.

Care este diferența dintre ERR_SSL_PROTOCOL_ERROR și ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR indică faptul că serverul a trimis un răspuns care nu se conformează niciunui format de înregistrare TLS recunoscut — adesea cauzat de un server care trimite un răspuns HTTP pe portul 443, un load balancer configurat greșit sau un firewall care întrerupe conexiunea în mijlocul handshake-ului. ERR_SSL_VERSION_OR_CIPHER_MISMATCH înseamnă că handshake-ul a început corect, dar clientul și serverul nu au putut conveni asupra unei versiuni TLS sau a unui cipher suite suportat reciproc, de obicei deoarece serverul suportă doar protocoale depreciate.