HTTPS pentru aplicația ta: de ce contează și cum îl configurezi corect

Când termini de scris cod și deploy-uiești prima dată în producție, unul dintre primele lucruri pe care le verifici e dacă site-ul se încarcă pe https://. Și totuși, HTTPS rămâne una dintre cele mai prost înțelese părți ale infrastructurii web. Am văzut aplicații perfect arhitecturate care pierdeau ranking și încredere doar din cauza unui certificat expirat sau a unui mix de resurse HTTP/HTTPS.

În acest ghid trec prin ce se întâmplă de fapt la nivel de protocol, ce tipuri de certificate există, cum configurezi corect redirectul și HSTS și ce greșeli evit eu în proiectele de producție.

Ce se întâmplă de fapt când browserul se conectează la site-ul tău

Când un utilizator accesează https://aplicatia-ta.ro, în spate are loc un TLS handshake — o negociere care durează câteva milisecunde, dar face mult mai mult decât să „cripteze" datele:

1. ClientHello — browserul trimite serverului versiunile de TLS pe care le suportă și lista de cipher suites.
2. ServerHello + Certificate — serverul răspunde cu versiunea aleasă și își trimite certificatul, care conține cheia publică și numele de domeniu (SAN).
3. Verificarea lanțului de încredere — browserul verifică că certificatul e semnat de o autoritate de certificare (CA) pe care o are în lista de încredere. Dacă lanțul e rupt sau certificatul e expirat, vezi ecranul roșu „Your connection is not private".
4. Schimbul de chei — clientul și serverul calculează o cheie de sesiune simetrică (de obicei prin ECDHE, care oferă forward secrecy).
5. HTTP peste TLS — de acum, tot traficul HTTP e criptat cu cheia de sesiune.

Partea importantă pentru tine ca dezvoltator: TLS nu e doar criptare, ci și autentificare. Certificatul dovedește că serverul care răspunde la aplicatia-ta.ro chiar e al tău. Fără el, oricine poate face un server care pretinde că e domeniul tău (atac man-in-the-middle).

Ce conține un certificat și de ce contează SAN

Un certificat TLS e un fișier X.509 care conține:

• cheia publică a serverului;
• numele de domenii pentru care e valid (câmpul SAN — Subject Alternative Name);
• emitentul (CA-ul care l-a semnat);
• perioada de valabilitate;
• semnătura digitală a CA-ului.

Cel mai frecvent motiv pentru care un certificat „nu merge": SAN lipsă. Instalezi certificatul pentru www.aplicatia-ta.ro, dar site-ul e accesat pe aplicatia-ta.ro (fără www) — sau invers. Browserul refuză conexiunea pentru că numele nu se potrivește cu SAN-ul.

Verifică întotdeauna cu ce nume e accesat site-ul în producție și asigură-te că ambele variante (cu și fără www, sau subdomeniile folosite) sunt în certificat.

DV, OV, EV: care e diferența și de care ai nevoie

• DV (Domain Validation) — validează doar că deții domeniul. Se emite automat, în câteva minute, prin protocolul ACME (Let's Encrypt). Pentru 95% dintre site-uri și aplicații e suficient: oferă exact aceeași criptare ca unul scump.
• OV (Organization Validation) — validează și datele firmei. Afișează compania în certificat. Folosit de business-uri care vor să arate identitatea juridică.
• EV (Extended Validation) — cel mai strict; practic a dispărut din UI-ul browserelor moderne (Chrome și Firefox nu mai afișează bara verde distinctă), deci rar mai justifică prețul.

Concluzia practică: dacă nu ai o cerință explicită de OV/EV, un certificat DV cu reînnoire automată e alegerea corectă. Economisești timp și nu mai depinzi de reînnoire manuală.

Auto-SSL: de ce e standardul în 2026

Emisiunea automată de certificate DV prin Let's Encrypt și alți CA-uri ACME a schimbat complet peisajul. Un hosting modern instalează și reînnoiește singur certificatele, fără intervenția ta. La proiectele mele, regula e:

Dacă trebuie să-mi amintesc să reînnoiesc un certificat, configurarea e greșită.

Când alegi un host pentru aplicațiile clienților, caută explicit SSL automat (auto-issuance + auto-renew). E o diferență uriașă între „am SSL instalat" și „SSL-ul se reînnoiește singur, la timp, și am notificare dacă ceva eșuează".

Configurarea corectă: redirect, HSTS și mixed content

Instalarea certificatului e doar jumătate din treabă. Iată configurația pe care o aplic constant:

1. Redirect permanent HTTP → HTTPS

În Nginx:

server {
    listen 80;
    server_name aplicatia-ta.ro www.aplicatia-ta.ro;
    return 301 https://$host$request_uri;
}

În Apache:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

2. HSTS — spune browserului să nu mai încerce HTTP deloc

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

HSTS îi spune browserului: „pentru următorul an, accesează direct HTTPS, fără să mai treci prin HTTP". Elimină riscul unui downgrade attack și o cerere HTTP redundantă la prima vizită. Activează-l doar când ești sigur că HTTPS funcționează perfect — cu includeSubDomains, un subdomeniu fără certificat va deveni inaccesibil.

3. Mixed content — inamicul tăcut

După ce site-ul e pe HTTPS, orice resursă încărcată pe http:// (imagine, script, iframe) e blocată de browser. Simptom: pagina se încarcă, dar un script nu rulează și nu înțelegi de ce. Deschide DevTools → Console și vei vedea Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource.

Soluția: nu mai folosi URL-uri absolute cu protocol în cod. Scrie /assets/app.js sau //cdn.example.com/lib.js (protocol-relative), sau mai bine, lasă browserul să moștenească protocolul paginii.

4. HTTP/2 și HTTP/3

HTTP/2 necesită TLS și oferă multiplexing — mai multe resurse pe aceeași conexiune. HTTP/3 (QUIC) merge mai departe, cu multiplexing peste UDP și toleranță mai bună la pierderea de pachete. Ambele sunt activate automat de serverele moderne când TLS e configurat corect. Le verifici cu:

curl -sI https://aplicatia-ta.ro --http2 | head -n 5

Dacă vezi HTTP/2 200, ești pe drumul cel bun.

Cum testezi configurarea ca un profesionist

Nu te baza pe „se încarcă în browser". Folosește instrumente care îți arată exact ce se întâmplă:

# Vezi lanțul de certificate, datele de expirare și cipher-urile
curl -vI https://aplicatia-ta.ro 2>&1 | grep -E "SSL|subject|expire"

# Verifici expirarea direct
echo | openssl s_client -servername aplicatia-ta.ro -connect aplicatia-ta.ro:443 2>/dev/null | openssl x509 -noout -dates

Și cel mai important: configurează monitorizarea expirării certificatului. Un certificat expirat oprește site-ul complet și e prima cauză de incidente „de ce nu merge site-ul?" pe care o văd în support. Un simplu script cron care verifică datele de expirare și trimite un alert e suficient:

#!/bin/bash
DOMAIN="aplicatia-ta.ro"
DAYS=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null \
  | openssl x509 -noout -enddate \
  | sed 's/notAfter=//' \
  | xargs -I{} date -d {} +%s)
NOW=$(date +%s)
LEFT=$(( (DAYS - NOW) / 86400 ))
if [ "$LEFT" -lt 14 ]; then
  echo "Certificatul pentru $DOMAIN expiră în $LEFT zile!"
fi

Cu SSL automat nu ai nevoie de asta — dar dacă gestionezi servere proprii, îl vrei.

Greșelile pe care le văd cel mai des

1. Certificat instalat, dar resursele rămân pe HTTP → mixed content, pagini rupte.
2. Reînnoire manuală → la un moment dat uiți; site-ul pică într-o duminică.
3. SAN fără varianta www sau fără subdomeniul folosit → erori intermitente.
4. Redirect 302 în loc de 301 → SEO-ul pierde equity, iar Google vede două versiuni.
5. Fără HSTS → fiecare vizită nouă riscă o cerere HTTP în clar.
6. TLS 1.0/1.1 rămase active → compatibilitate falsă, securitate slabă. În 2026, TLS 1.2 și 1.3 sunt singurele care ar trebui să existe.

Când ai nevoie de mai mult decât auto-SSL

Dacă ai mai multe subdomenii, un certificat wildcard (*.aplicatia-ta.ro) acoperă totul cu un singur certificat. Dacă ai un business care vinde servicii B2B și partenerii cer dovada identității, un certificat OV face treaba. În rest, DV auto e noul standard.

Iar dacă nu vrei să-ți bați capul cu gestionarea serverului, un hosting care include SSL automat, certificate gratuite nelimitate și reînnoire fără intervenție economisește ore bune pe an. Eu pun preț pe chestiile astea la recomandările mele — la fel cum verific NVMe și LiteSpeed înainte să recomand un host pentru aplicații în producție, verific și cum e gestionat TLS-ul.

Dacă vrei detalii despre cum arată SSL-ul automat și restul configurației de producție la KabyNode, pagina de certificate SSL și cea de securitate explică exact ce primești. SSL automat, backup zilnic 30 de zile și suport tehnic în română 24/7 sunt incluse — lucruri care contează când aplicația ta e în producție, nu doar în development.

Articol scris de KabyNode — hosting NVMe cu LiteSpeed și SSL automat, din România, din 2022.