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

KabyNode — Fri, 04 Sep 2026 06:32:04 +0000

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:

ClientHello — browserul trimite serverului versiunile de TLS pe care le suportă și lista de cipher suites.
ServerHello + Certificate — serverul răspunde cu versiunea aleasă și își trimite certificatul, care conține cheia publică și numele de domeniu (SAN).
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".
Schimbul de chei — clientul și serverul calculează o cheie de sesiune simetrică (de obicei prin ECDHE, care oferă forward secrecy).
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

Certificat instalat, dar resursele rămân pe HTTP → mixed content, pagini rupte.
Reînnoire manuală → la un moment dat uiți; site-ul pică într-o duminică.
SAN fără varianta www sau fără subdomeniul folosit → erori intermitente.
Redirect 302 în loc de 301 → SEO-ul pierde equity, iar Google vede două versiuni.
Fără HSTS → fiecare vizită nouă riscă o cerere HTTP în clar.
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.

De la `npm run dev` la producție: cum alegi infrastructura de hosting potrivită aplicației tale

KabyNode — Thu, 03 Sep 2026 21:54:49 +0000

Când termini o aplicație și vrei să o muți în producție, apare întrebarea pe care fiecare developer o amână cât poate: ce hosting aleg? După ce am mutat zeci de aplicații (de la boturi Discord și API-uri Node.js până la magazine online), am ajuns la câteva reguli simple care salvează timp și nervi.

1. Începe de la stack, nu de la preț

Prețul e ultimul criteriu. Întâi verifici dacă platforma suportă ce folosești deja: versiunea de PHP, Node.js, baza de date, extensiile. Nimic nu e mai frustrant decât să descoperi după migrare că hostul tău rulează PHP 7.4 când tu ai scris cod cu PHP 8.3.

Un mediu modern ar trebui să includă:

PHP 8.x cu opcache activat
MariaDB/MySQL 11 (sau mai nou)
SSH pentru comenzi reale, nu doar un manager de fișiere
Staging ca să testezi înainte să spargi producția

2. Viteza nu se negociază: NVMe și LiteSpeed

Dacă aplicația ta răspunde în 800ms local dar 3 secunde în producție, problema e aproape mereu infrastructura: discuri lente (HDD), Apache fără cache, fără HTTP/2. Discurile NVMe Gen4 și serverele LiteSpeed Enterprise fac o diferență pe care o vezi direct în timpii de răspuns — mai ales sub sarcină.

Testează orice provider cu un curl -w sau un tool de benchmark înainte să te legi contractual. Dacă un host nu îți poate spune ce fel de discuri folosește, ai deja răspunsul.

3. Backup-urile și restore-ul se testează, nu se presupun

„Facem backup zilnic" e fraza pe care o auzi de la toți. Întrebarea corectă e: cât durează un restore și cine îl face? Ideal: backup automat zilnic, reținut minim 30 de zile, cu opțiune de restore dintr-un singur click. Testează un restore în primele 30 de zile — mai bine să descoperi atunci o problemă decât după un incident real.

4. Suportul care chiar rezolvă

Ca developer, nu ai timp de ticket-uri care mor în coadă 48 de ore. Suportul 24/7 care răspunde în română și poate vorbi tehnic (nu doar să recite un manual) e o diferență uriașă când aplicația ta e down la 2 dimineața.

5. Shared hosting vs VPS — când muți aplicația?

Regula mea pragmatică:

Shared hosting cu LiteSpeed — pentru aplicații PHP/WordPress, site-uri de prezentare, API-uri mici. E de ajuns pentru 95% din cazuri și nu trebuie să administrezi un server.
VPS — când ai nevoie de root, de procese long-running (workers, crons grele, boturi), de software custom sau de izolare reală. Gândește-te la el ca la „propriul tău server, fără să cumperi un server".
Dedicat — abia când scalarea pe VPS nu mai e suficientă și ai un motiv clar (resurse constante, cerințe de conformitate, performanță extremă).

6. Securitatea implicită, nu opțională

SSL automat, firewall la nivel de aplicație, protecție malware și actualizări gestionate ar trebui să fie incluse, nu vândute separat. Un host care îți lasă site-ul fără SSL „pentru că nu ai plătit" nu își face treaba.

Concluzie

Alegerea infrastructurii nu e despre cel mai mic preț, ci despre cel mai mic timp total petrecut cu operațiuni: deploy fără frică, restore care merge, suport care răspunde. Dacă vrei să compari opțiunile de la un singur furnizor care acoperă toate cele trei trepte (shared, VPS, dedicat), am scris mai multe detalii despre găzduirea web și planurile disponibile și despre servere virtuale la KabyNode.

Articol scris de KabyNode — hosting românesc cu servere proprii, NVMe Gen4 și suport 24/7.

DEV Community: KabyNode