SSL și TLS: Cum configurați și reînnoiți certificatele pe serverul dumneavoastră

SSL și TLS: Cum configurați și reînnoiți certificatele pe serverul dumneavoastră, de la obținerea gratuită a certificatului până la reînnoirea automată care nu eșuează în weekend. Un certificat expirat înseamnă un ecran roșu de avertizare pentru fiecare vizitator și, în câteva zile, scăderea încrederii Google; este cea mai vizibilă și cea mai evitabilă pană a unui site. Ghidul acoperă atât serverele proprii (Ubuntu, AlmaLinux, cu Apache sau Nginx), cât și conturile cPanel, unde certificatul vine prin AutoSSL.

SSL este numele vechi al protocolului; versiunile folosite azi sunt TLS 1.2 și TLS 1.3, iar TLS 1.0 și 1.1 sunt retrase și trebuie dezactivate. Termenul „certificat SSL” a rămas în uz și îl folosim și noi, pentru claritate.

SSL și TLS: Cum configurați și reînnoiți certificatele pe serverul dumneavoastră

Tipurile de certificate

• DV (validare de domeniu): confirmă doar controlul asupra domeniului; gratuit de la Let's Encrypt sau ZeroSSL; suficient pentru aproape orice site, inclusiv magazine.
• OV (validare de organizație): confirmă și existența firmei; plătit; vizibil doar în detaliile certificatului, browserele nu îl mai evidențiază.
• EV (validare extinsă): verificare mai strictă; bara verde a dispărut din browsere din 2019, deci avantajul vizual nu mai există.
• Wildcard (*.exemplu.ro): acoperă toate subdomeniile; Let's Encrypt îl emite cu validare prin DNS.

Pentru clienții noștri folosim DV de la Let's Encrypt aproape peste tot; OV are sens pentru instituții cu cerințe de conformitate.

Pe cPanel: AutoSSL

Majoritatea găzduirilor cPanel emit și reînnoiesc automat certificate pentru fiecare domeniu care indică spre server, prin AutoSSL (Let's Encrypt sau Sectigo). Verificați starea din Security, SSL/TLS Status: fiecare domeniu și subdomeniu cu certificatul lui, data expirării și eventualele erori. Cauzele obișnuite de eșec: domeniul nu indică spre server (DNS nepropagat sau greșit), subdomeniul www sau mail lipsește din DNS, o redirecționare care împiedică validarea pe calea /.well-known/, sau o înregistrare CAA în zona DNS care nu permite autoritatea folosită. Detaliile pentru mai multe domenii pe același cont sunt în ghidul despre AutoSSL pentru domenii multiple, iar activarea inițială în cel despre activarea și gestionarea SSL-ului în cPanel.

Pe server propriu: Let's Encrypt cu certbot

Instalarea și emiterea

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot --apache -d exemplu.ro -d www.exemplu.ro     # Apache
sudo certbot --nginx  -d exemplu.ro -d www.exemplu.ro     # Nginx

Certbot validează controlul domeniului printr-un fișier pe portul 80, emite certificatul (valabil 90 de zile), scrie configurația TLS în gazda virtuală și, la cerere, adaugă redirecționarea de la HTTP. Condiții: domeniul indică deja spre server, portul 80 este deschis în firewall, iar serverul web servește domeniul respectiv. Pe AlmaLinux, pachetul este certbot din EPEL, cu pluginurile python3-certbot-apache sau -nginx.

Certificate wildcard, prin DNS

sudo certbot certonly --manual --preferred-challenges dns -d exemplu.ro -d "*.exemplu.ro"

Certbot cere adăugarea unei înregistrări TXT în zona DNS; pentru reînnoire automată, folosiți un plugin DNS al furnizorului (certbot-dns-cloudflare și altele), altfel reînnoirea cere intervenție manuală la fiecare 60 de zile.

Reînnoirea automată

Certbot instalat din snap creează un temporizator systemd care verifică de două ori pe zi și reînnoiește certificatele cu mai puțin de 30 de zile rămase. Verificați că există și că testul de reînnoire trece:

systemctl list-timers | grep certbot
sudo certbot renew --dry-run
sudo certbot certificates

După reînnoire, serverul web trebuie să recitească certificatul; certbot o face prin pluginul folosit la emitere sau printr-un hook (--deploy-hook "systemctl reload apache2"). Un certificat reînnoit pe disc, dar neîncărcat de server, este cazul clasic de „am reînnoit și tot expirat arată”.

Configurația TLS a serverului

Certificatul este jumătate din securitate; cealaltă jumătate este configurația: versiunile de protocol și suitele de cifrare acceptate. Folosiți generatorul de configurație Mozilla (profilul Intermediate) și verificați cu un test extern. Pentru Apache, esențialul:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/exemplu.ro/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/exemplu.ro/privkey.pem
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite 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
SSLHonorCipherOrder off
SSLSessionTickets off
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

Pentru Nginx, directivele echivalente sunt ssl_protocols TLSv1.2 TLSv1.3, ssl_ciphers cu aceeași listă, ssl_prefer_server_ciphers off și add_header pentru HSTS. Pe cPanel, configurația TLS a serverului o face furnizorul din WHM; puteți doar verifica rezultatul.

Redirecționarea spre HTTPS

# Apache, în gazda virtuală de pe portul 80 sau în .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Nginx
server { listen 80; server_name exemplu.ro www.exemplu.ro; return 301 https://$host$request_uri; }

O singură redirecționare, direct spre versiunea finală (https și www sau fără www), nu două în lanț; ghidul despre redirecționări descrie combinația corectă.

HSTS și CAA

Antetul Strict-Transport-Security spune browserului să folosească doar HTTPS pentru domeniu, pentru perioada indicată; activați-l abia după ce totul funcționează pe HTTPS, inclusiv subdomeniile, fiindcă nu se poate „dezactiva” din browserul vizitatorului înainte de expirare. Înregistrarea CAA din DNS limitează autoritățile care pot emite certificate pentru domeniu (de exemplu, doar letsencrypt.org); o adăugați din Zone Editor și verificați că include autoritatea pe care o folosiți, altfel reînnoirea eșuează. Pe site-urile noastre, CAA are doar înregistrări issue și iodef, fără issuewild, după o eroare de configurare pe care am reparat-o.

Conținutul mixt

După trecerea la HTTPS, paginile care încarcă imagini, scripturi sau stiluri prin http afișează avertisment sau le blochează. Cauza este în baza de date (adrese absolute vechi) și în temă; pe WordPress, wp search-replace din terminalul cPanel înlocuiește adresele în minute. Verificați cu consola browserului (Mixed Content) și cu un crawler; antetul Content-Security-Policy cu upgrade-insecure-requests forțează browserul să ceară totul prin HTTPS, ca plasă de siguranță.

Certificate pentru e-mail și alte servicii

Serverul de e-mail (IMAP, SMTP), FTP cu TLS și panoul de administrare au nevoie de certificate proprii sau de același certificat instalat pe fiecare serviciu. Pe cPanel, AutoSSL acoperă și numele mail.exemplu.ro și instalează certificatul pe serviciile de e-mail; verificați în programul de e-mail că numele serverului este cel din certificat, altfel apar avertismente la fiecare pornire. Pe servere proprii, certbot emite un certificat cu toate numele (exemplu.ro, www, mail) și un hook îl copiază în locul cerut de Postfix și Dovecot, cu reîncărcarea lor. Politica MTA-STS, care obligă expeditorii să folosească TLS spre serverul dumneavoastră de e-mail, depinde de un certificat valid pe numele MX; un certificat expirat acolo oprește primirea de la Gmail și Outlook, caz pe care l-am avut pe un domeniu propriu.

Certificatele și Cloudflare

Cu Cloudflare în față, vizitatorii văd certificatul Cloudflare, iar între Cloudflare și server se folosește certificatul serverului (modul Full sau Full strict). Modul Flexible (HTTPS doar până la Cloudflare, HTTP spre server) este o capcană: pare sigur și nu este, iar unele aplicații intră în bucle de redirecționare. Setați Full strict, păstrați certificatul valid pe server (AutoSSL sau certbot merg și în spatele Cloudflare, cu validarea prin HTTP permisă) și verificați că HSTS nu este suprascris de setarea din panoul Cloudflare; detaliile sunt în ghidul despre Cloudflare și cPanel.

Erori frecvente și cauzele lor

• NET: ERR_CERT_DATE_INVALID: certificat expirat; reînnoirea nu a rulat sau serverul nu a fost reîncărcat.
• NET: ERR_CERT_COMMON_NAME_INVALID: certificatul nu acoperă numele cerut (www lipsă, subdomeniu nou); reemiteți cu toate numele.
• Lanț incomplet (funcționează în Chrome, eșuează pe telefon sau în curl): serverul trimite doar certificatul, fără intermediar; folosiți fullchain.pem, nu cert.pem.
• Validarea eșuează la reînnoire: portul 80 închis, o redirecționare care prinde /.well-known/acme-challenge/, CAA restrictiv, sau limita de rată Let's Encrypt (5 certificate identice pe săptămână) atinsă de încercări repetate.
• Certificat valid, dar browserul cere parolă la fiecare pagină: nu e TLS, e protecția cu parolă; vedeți ghidul despre protecția directorului.
• Scorul de test slab (B sau C) cu certificat valid: TLS 1.0/1.1 sau suite slabe active; corectați configurația, nu certificatul.

Verificarea

echo | openssl s_client -connect exemplu.ro:443 -servername exemplu.ro 2>/dev/null | openssl x509 -noout -dates -subject -issuer
curl -sI https://www.exemplu.ro/ | grep -i strict-transport
nmap --script ssl-enum-ciphers -p 443 exemplu.ro

Prima comandă arată datele de valabilitate, numele și emitentul; a doua confirmă HSTS; a treia listează protocoalele și suitele acceptate. Un test extern (SSL Labs sau scanerul de securitate GOAI) dă nota finală și lista de corecții. Atenție la un fals pozitiv frecvent: openssl s_client afișează „Protocol: TLSv1” și când conexiunea eșuează, deci citiți și rândul de eroare, nu doar protocolul.

Rutina

1. Reînnoire automată verificată cu --dry-run după instalare și după orice schimbare de server web.
2. Monitorizare externă a expirării, cu alertă la 14 zile (majoritatea serviciilor de monitorizare o au).
3. Test de configurație TLS trimestrial și după actualizări de server.
4. Inventarul subdomeniilor cu certificat: fiecare subdomeniu nou primește certificat înainte de a fi legat de undeva.
5. CAA verificat la orice schimbare de autoritate sau de furnizor.

Configurația TLS este unul dintre punctele verificate în auditul de securitate al site-urilor noastre, alături de antete și DNS; contextul complet pentru un server este în ghidul de securitate pentru AlmaLinux 9, iar pentru cont, în cel despre securitatea contului cPanel.

Surse

• Documentația cPanel, SSL/TLS: gestionarea certificatelor din panou și AutoSSL.
• web.dev, de ce contează HTTPS: motivele pentru HTTPS pe orice site și efectele lipsei lui.