Certificat SSL: ce garantează, cum îl verifici și ce faci când expiră

Un certificat SSL este un fișier semnat de o autoritate de certificare care face posibilă conexiunea criptată dintre browser și site și dovedește că serverul răspunde pentru domeniul din bara de adrese. Atât garantează. Nu spune dacă firma e serioasă, dacă site-ul e curat de programe dăunătoare sau dacă datele sunt bine păstrate pe server. Mai jos afli cum citești un certificat în browser, ce tip îți trebuie, de ce expiră din ce în ce mai des și cum scapi de avertismentul „conexiune nesigură”.

Ce este un certificat SSL și ce face, de fapt

Gândește-te la certificat ca la un act de identitate al serverului, semnat de cineva în care browserele au încredere. Documentația MDN explică faptul că certificatul conține o copie semnată digital a cheii publice a site-ului. Cheia publică este jumătatea care poate fi arătată oricui; perechea ei, cheia privată, rămâne doar pe server. Semnătura autorității leagă aceste chei de numele domeniului.

Cu acest act, conexiunea capătă trei proprietăți descrise de documentația MDN despre TLS:

• criptarea: datele schimbate pe drum nu pot fi citite de cine le interceptează;
• integritatea: nimeni nu poate modifica pe ascuns datele în tranzit;
• autentificarea: serverul dovedește că este cel care pretinde că este.

Documentul de standard pentru TLS 1.3 o spune direct: partea de server a canalului este mereu autentificată, iar cea de client doar opțional. Pe înțelesul unui om de afaceri, vizitatorul primește dovada că vorbește cu site-ul tău. Tu nu primești, prin certificat, nicio dovadă despre cine este vizitatorul.

Cum ajunge certificatul pe server

Procesul de emitere arată la fel la cele mai multe autorități automatizate. Programul de pe server cere certificatul, dovedește că are controlul domeniului, iar autoritatea verifică dovada și semnează.

Sursa: How It Works, Let's Encrypt

Pasul care contează pentru tine este al doilea. Dovada se face fie printr-o înregistrare DNS, fie printr-un fișier pus la o adresă anume pe site. Dacă cineva schimbă între timp setările DNS sau redirecționează site-ul greșit, verificarea poate eșua la reînnoire. Asta explică multe certificate care „au expirat singure” după o mutare de server.

Ce nu garantează lacătul din bara de adrese

O greșeală frecventă este să citești lacătul ca pe un semn de încredere în firmă. Pagina de ajutor Chrome despre conexiunea sigură avertizează că, chiar dacă te-ai conectat în siguranță la un site, trebuie să ai grijă când trimiți informații sensibile. Recomandă și să verifici numele site-ului în bara de adrese.

Motivul e simplu: oricine are un domeniu poate obține un certificat valid pentru el. Un site de înșelătorie, cu o adresă asemănătoare cu a unei bănci, poate avea conexiune criptată impecabilă. Criptarea îl protejează pe vizitator de cei care ascultă pe drum, nu de site-ul însuși.

Ce rămâne în afara certificatului:

• securitatea codului și a sistemului de administrare al site-ului;
• parolele conturilor de administrare și copiile de siguranță;
• felul în care sunt stocate datele clienților pe server;
• conformitatea cu regulile privind datele personale, pe care le explică ghidul nostru despre ce trebuie să conțină legal un site de firmă.

Asta nu face certificatul mai puțin necesar. Documentația web.dev numește drept concepție greșită ideea că doar site-urile cu informații sensibile au nevoie de HTTPS. Pe o conexiune necriptată pot fi modificate imaginile, scripturile, cookie-urile și HTML-ul, adică orice ajunge la vizitator.

SSL sau TLS: de ce mai spunem „SSL”

Expresia „certificat SSL” a rămas din obișnuință. Protocolul folosit efectiv pe web este TLS (Transport Layer Security), succesorul lui SSL (Secure Sockets Layer). Certificatul nu se schimbă cu numele: același fișier servește conexiunilor TLS. MDN folosește chiar formularea că SSL este predecesorul lui TLS.

Cronologia de mai jos vine din documentul IETF care a interzis ultima versiune SSL. Se vede cât de veche este, de fapt, denumirea pe care o folosim zilnic.

Sursa: RFC 7568, Deprecating Secure Sockets Layer Version 3.0, IETF

Documentul din iunie 2015 cere explicit ca SSLv3 să nu mai fie folosit. Același text notează că versiunea anterioară, SSL 2, nu mai era considerată suficient de sigură. Ulterior, IETF a scos din uz și TLS 1.0 și TLS 1.1, prin RFC 8996, un document cu drepturi de autor din 2021.

Ce înseamnă asta practic, după documentația MDN citită la 1 noiembrie 2026: TLS 1.3 este versiunea actuală și cea mai folosită, TLS 1.2 mai apare pe unele site-uri, iar TLS 1.1 și 1.0 nu mai trebuie folosite. Un detaliu pentru cei care citesc standardele: pagina RFC 8446, documentul din august 2018 care definește TLS 1.3, îl marchează ca înlocuit de RFC 9846.

Pentru tine, ca proprietar, întrebarea utilă nu e „SSL sau TLS”. Întrebarea este ce versiuni de TLS acceptă serverul. Dacă un furnizor de găzduire încă permite TLS 1.0, merită cerută dezactivarea lui.

Cum verifici certificatul unui site în browser

Verificarea durează un minut și nu cere unelte speciale. Pașii de mai jos sunt pentru Chrome, dar celelalte browsere au opțiuni asemănătoare, cu alte denumiri.

1. Deschide site-ul și uită-te la simbolul din stânga adresei. Pagina de ajutor Chrome descrie trei stări: securizat, informații sau nesecurizat, nesecurizat sau periculos.
2. Selectează simbolul. Se deschide un rezumat cu detalii despre conexiune, cookie-uri și permisiuni.
3. Intră în secțiunea despre conexiune și apoi în cea despre certificat. Denumirile exacte diferă între versiuni și sisteme de operare.
4. Citește numele pentru care a fost emis certificatul. Trebuie să se potrivească exact cu domeniul din bara de adrese, cu sau fără „www”, după cum ai configurat site-ul.
5. Uită-te la datele de valabilitate: de la ce zi și până la ce zi e valabil certificatul.
6. Verifică cine l-a emis. Numele autorității îți spune și dacă e un certificat gratuit, cu validare de domeniu, sau unul cu verificări suplimentare.
7. Repetă verificarea pe telefon și pe adresa fără „www”. Destule probleme apar doar pe una dintre variante.

Imaginează-ți o firmă mică cu un site de prezentare care a cumpărat și varianta de domeniu cu cratimă. Dacă certificatul acoperă doar numele principal, vizitatorii care tastează varianta cu cratimă primesc avertisment. Autoritatea non-profit confirmă că același certificat poate conține mai multe nume diferite, deci problema se rezolvă la emitere.

Tipurile de validare și când contează

Certificatele diferă prin ce verifică autoritatea înainte să le semneze, nu prin puterea criptării. Întrebările frecvente ale autorității non-profit numesc trei niveluri: validare de domeniu (DV), validare de organizație (OV) și validare extinsă (EV).

Tip	Ce verifică autoritatea	Cum se emite	Pentru cine are sens
Validare de domeniu (DV)	Că solicitantul controlează domeniul	Automat, prin DNS sau fișier pe site	Site-uri de prezentare, bloguri, majoritatea magazinelor online
Validare de organizație (OV)	Domeniul și date despre organizație	Cu pași care nu se pot automatiza complet	Firme care vor numele organizației în detaliile certificatului
Validare extinsă (EV)	Verificări mai amănunțite despre organizație	Tot cu pași care nu se pot automatiza complet	Situații cu cerințe contractuale sau interne explicite

Autoritatea non-profit emite doar certificate DV. Explică faptul că nu oferă OV sau EV în primul rând pentru că emiterea lor nu poate fi automatizată. Asta spune ceva important: diferența dintre tipuri ține de identitatea firmei, nu de cât de bine sunt protejate datele pe drum.

Mai există două criterii practice, independente de nivelul de validare:

• Câte nume acoperă. Un certificat poate include mai multe domenii. Varianta pentru toate subdomeniile, numită „wildcard”, cere la autoritatea non-profit verificarea prin DNS.
• Pentru ce e folosit. Certificatele pentru site-uri nu servesc la semnarea codului sau la criptarea e-mailurilor; acelea cer alt tip de certificat.

Este suficient un certificat gratuit

Pentru majoritatea site-urilor de firmă, da. MDN descrie autoritatea non-profit Let’s Encrypt ca fiind larg folosită și emitentă de certificate TLS gratuite. Criptarea conexiunii este aceeași ca la un certificat plătit cu validare de domeniu.

Diferențele reale sunt trei:

• Durata. Certificatele gratuite au valabilitate scurtă, deci reînnoirea trebuie făcută de un program, nu de un om.
• Asistența. Autoritatea non-profit spune deschis că lucrează cu o echipă mică și nu oferă asistență directă, ci documentație și forumuri.
• Intermediarul. Întrebările frecvente ale autorității notează că unii furnizori de găzduire cer o taxă pentru administrarea acestor certificate.

Criteriul de decizie, deci, nu e „gratuit sau plătit”. Te întrebi dacă ai nevoie de numele firmei verificat în certificat și cine răspunde de reînnoire. Dacă site-ul e administrat în cadrul unui serviciu de găzduire și mentenanță, de obicei reînnoirea automată și urmărirea ei intră în sarcinile furnizorului. Verifică însă în contract că așa este.

Ce se întâmplă când expiră certificatul

Când certificatul expiră, Chrome și celelalte browsere afișează un avertisment pe toată pagina. Pagina de ajutor Chrome spune că mesajul „Conexiunea nu este privată” pe toată pagina indică o problemă cu site-ul, rețeaua sau dispozitivul. Pentru vizitator, un astfel de ecran e un motiv bun să închidă fila.

Efectele pentru firmă se adună repede. Formularele de contact nu mai primesc mesaje, coșul de cumpărături se oprește, iar campaniile plătite trimit oameni spre un ecran de avertisment. Raportul HTTPS din Search Console listează eroarea de certificat invalid și precizează că, de obicei, ea afectează tot site-ul.

Duratele scad, deci reînnoirea manuală nu mai e o opțiune

Autoritatea non-profit a anunțat un calendar de scurtare a duratei. Graficul arată valorile publicate de ea pentru profilul implicit și pentru profilul de scurtă durată.

Sursa: Decreasing Certificate Lifetimes to 45 Days, Let's Encrypt

În anunț, autoritatea spune că emite certificate valabile 90 de zile, durată care va fi înjumătățită la 45 de zile până în 2028. Schimbarea se face, spune ea, odată cu restul industriei, la cererea regulilor comune ale autorităților și browserelor. Pentru 13 mai 2026, autoritatea a programat trecerea unui profil opțional, gândit pentru testare, la certificate de 45 de zile.

Pe 10 februarie 2027, profilul implicit trece la certificate de 64 de zile. Pe 16 februarie 2028, același profil ajunge la 45 de zile. Schimbările se aplică certificatelor noi, deci le vezi la prima reînnoire de după fiecare dată.

Consecința practică e scrisă direct în anunț: o reînnoire programată fix la 60 de zile nu va mai fi suficientă. Autoritatea consideră acceptabilă reînnoirea pe la două treimi din durata certificatului curent. Tot ea nu recomandă reînnoirea manuală, fiindcă ar trebui făcută tot mai des.

Cum previi expirarea

1. Află cine emite certificatul și cine îl reînnoiește: furnizorul de găzduire, agenția sau tu.
2. Cere confirmarea că reînnoirea este automată și că programul suportă duratele mai scurte.
3. Setează o alertă care te anunță dacă certificatul nu a fost reînnoit la timp. Autoritatea non-profit recomandă explicit o astfel de monitorizare.
4. După orice mutare de server sau schimbare DNS, verifică certificatul în browser în aceeași zi.
5. Notează într-un document intern data de expirare și cine trebuie sunat dacă apare avertismentul.

De ce apare „conexiune nesigură” deși ai certificat

Aici se blochează cei mai mulți proprietari: certificatul e valid, dar browserul tot afișează un semn de avertizare. Cauza cea mai frecventă este conținutul mixt. MDN îl definește ca situația în care documentul principal se încarcă prin HTTPS, dar o parte din resurse vin prin HTTP.

Documentația web.dev împarte conținutul mixt în două tipuri, cu riscuri diferite. Comparația de mai jos rezumă ce înseamnă fiecare.

Sursa: What is mixed content?, web.dev (Google)

Conținutul pasiv pare inofensiv, dar web.dev notează că, dacă există, majoritatea browserelor arată în bara de adrese că pagina nu e sigură. Și asta chiar dacă pagina în sine vine prin HTTPS. Mai mult, browserele încearcă uneori să încarce resursa prin HTTPS; dacă nu există o versiune sigură, resursa nu se mai încarcă deloc. Rezultatul: imagini lipsă sau un formular care nu mai pornește.

Cauzele frecvente și remedierea lor

Ce vezi	Cauza probabilă	Ce faci
Avertisment pe toată pagina	Certificat expirat sau emis pentru alt nume	Reînnoiești sau emiți certificatul pentru numele corect
Avertisment doar pe unele pagini	Imagini, scripturi sau fonturi încărcate prin HTTP	Schimbi adresele resurselor în HTTPS
Site-ul merge cu „www”, dar nu fără	Certificatul nu include ambele variante	Adaugi ambele nume în certificat
Pagina se deschide și prin HTTP	Lipsește redirecționarea spre HTTPS	Configurezi redirecționarea permanentă
Avertismentul apare doar la unii vizitatori	O problemă a dispozitivului sau a rețelei vizitatorului	Verifici pe alt dispozitiv și în altă rețea

Pentru conținutul mixt din pagini vechi, pe care nu le poți edita ușor, MDN indică o soluție la nivel de server: o politică de securitate a conținutului cu directiva upgrade-insecure-requests. Browserul transformă singur cererile HTTP în HTTPS. E un ajutor, nu un înlocuitor pentru corectarea adreselor.

Mai e un pas pe care îl uită multe site-uri. MDN recomandă ca serverul să răspundă la cererile HTTP cu o redirecționare permanentă 301 spre versiunea HTTPS. Apoi, antetul Strict-Transport-Security (HSTS) îi spune browserului să folosească direct HTTPS la vizitele următoare.

Ce vede Google când certificatul are probleme

Pentru vizibilitatea în căutare, certificatul contează mai mult decât pare. Pagina de ajutor a raportului HTTPS din Search Console spune că, atunci când o pagină are atât adresă HTTP, cât și HTTPS, Google preferă să indexeze varianta HTTPS. Avertizează și că multe probleme HTTPS pot face Google să nu mai acceseze paginile HTTPS ale site-ului.

Erorile din raport care țin direct de certificat și de trecerea la HTTPS:

• certificat invalid: adresa HTTPS are un certificat SSL invalid, problemă care de regulă afectează tot site-ul;
• redirecționare greșită: adresa HTTPS trimite înapoi spre o adresă HTTP;
• harta site-ului cu adrese HTTP: fișierul trimis la Google indică încă paginile vechi;
• pagina canonică pe HTTP: pagina declară versiunea HTTP drept cea principală.

Dacă treci un site vechi pe HTTPS sau îl muți pe alt server, tratează schimbarea ca pe o migrare. Ghidul despre redesign fără să pierzi pozițiile din Google descrie pașii de redirecționare, iar o optimizare SEO tehnică include de obicei și verificarea raportului HTTPS.

Lista de control pentru proprietarul site-ului

Folosește lista de mai jos o dată la câteva luni și după orice schimbare de server, domeniu sau design. Fiecare punct se verifică fără cunoștințe de programare.

• Simbolul din bara de adrese arată conexiune securizată pe prima pagină, pe pagina de contact și pe o pagină de produs.
• Certificatul este emis exact pentru domeniul tău, inclusiv pentru varianta cu „www” sau fără.
• Știi data de expirare și știi cine face reînnoirea.
• Reînnoirea este automată și există o alertă dacă eșuează.
• Adresa tastată cu HTTP te duce automat la varianta HTTPS.
• Nu apar avertismente de conținut mixt pe paginile cu formulare.
• Raportul HTTPS din Search Console nu arată certificat invalid sau redirecționări spre HTTP.
• Furnizorul de găzduire a confirmat că TLS 1.0 și TLS 1.1 sunt dezactivate.

Dacă pornești un site nou, cere ca aceste puncte să facă parte din livrare. La un site de prezentare sau la un magazin online, HTTPS ar trebui să funcționeze corect din prima zi, nu să fie adăugat după lansare. Iar dacă domeniul abia urmează să fie cumpărat, ghidul despre înregistrarea unui domeniu .ro te ajută să pornești cu setările DNS în ordine.

Unde se oprește acest ghid

Articolul explică certificatele pentru site-uri publice, pe baza documentației oficiale citite la 1 noiembrie 2026. Calendarul de durate vine de la o singură autoritate de certificare; alte autorități pot avea durate și date diferite, așa că verifici la emitentul tău. Regulile comune ale industriei se pot schimba, iar autoritatea non-profit anunță modificările pe pagina ei.

Configurarea fină a serverului, alegerea algoritmilor criptografici sau certificatele pentru aplicații interne cer un specialist. Documentația MDN trimite, pentru astfel de setări, la recomandările de configurare TLS publicate de Mozilla. Pentru instituții publice sau contracte cu cerințe de securitate, verifici cerințele exacte în documentul care se aplică situației tale.

Ce faci mai departe

Deschide site-ul firmei acum, apasă simbolul din stânga adresei și notează trei lucruri: pentru ce nume e emis certificatul, până când e valabil și cine l-a emis. Apoi întreabă-l pe cel care îți administrează site-ul dacă reînnoirea e automată și dacă e pregătită pentru duratele care scad în 2027 și 2028. Dacă nu primești un răspuns clar, acolo e primul lucru de reparat.