Cum se instalează un certificat SSL pe NGINX

Acest ghid îți arată cum să instalezi un certificat SSL/TLS pe NGINX. Acoperă partea care încurcă cel mai des utilizatorii: construirea lanțului corect de certificate („fullchain”) pe care NGINX îl solicită, direcționarea directivelor potrivite către fișierele corecte, testarea configurației înainte de reîncărcare și adăugarea unei redirecționări curate de la HTTP la HTTPS, astfel încât fiecare vizitator să ajungă pe versiunea securizată a site-ului tău.

Generează un cod CSR pentru NGINX

Dacă ai generat deja CSR-ul și ai fișierele certificatului emis la îndemână, sari direct la Instalează un certificat SSL pe NGINX.

Înainte ca o Autoritate de Certificare să poată emite certificatul tău, trebuie să trimiți un CSR (Certificate Signing Request): un mic bloc de text care conține detaliile domeniului tău și o cheie publică, asociat cu o cheie privată păstrată pe server. Ai două opțiuni:

• Generează CSR-ul automat cu Generatorul nostru de CSR. Instrumentul returnează atât CSR-ul, cât și cheia privată corespunzătoare, pe care apoi le încarci pe server.
• Generează CSR-ul chiar pe server cu OpenSSL, urmând tutorialul nostru despre cum să generezi un CSR pe NGINX. Cheia privată rămâne pe server.

Deschide fișierul .csr rezultat în orice editor de text; blocul de text din interior (inclusiv liniile ––BEGIN CERTIFICATE REQUEST–– și ––END CERTIFICATE REQUEST––) este ceea ce lipești în formularul de comandă SSL în timpul finalizării comenzii. Dacă vrei să confirmi conținutul CSR-ului înainte de a-l trimite, lipește-l în decodorul nostru de CSR.

Instalează un certificat SSL pe NGINX

Odată ce CA-ul a emis certificatul, de obicei vei primi:

• Certificatul primar (de server), de obicei un fișier .crt denumit după domeniul tău.
• Certificatele intermediare (și uneori rădăcină), fie ca fișiere .crt separate, fie grupate într-un singur fișier .ca-bundle.
• Cheia privată (un fișier .key) care a fost generată împreună cu CSR-ul tău.

NGINX are nevoie de certificatul de server și lanțul intermediar combinate într-un singur fișier („fullchain”), la care se face referire prin ssl_certificate; cheia privată este indicată separat prin ssl_certificate_key. Omiterea lanțului este cea mai comună greșeală de instalare: certificatul pare corect într-un browser desktop, dar eșuează pe Android, în clienți API și în instrumente precum SSL Checker-ul nostru.

Pasul 1: Combină certificatele într-un singur fișier

Ordinea certificatelor în fișierul combinat contează. Certificatul tău de server vine primul, apoi fiecare certificat intermediar de la CA-ul emitent al certificatului final în sus, cu rădăcina la final (sau omisă, deoarece browserele au deja rădăcinile de încredere în magazinul lor încorporat):

• Certificatul tău primar pentru numele de domeniu.
• Certificat(e) intermediar(e).
• Certificat rădăcină (opțional).

Poți construi fișierul fullchain manual într-un editor de text (lipind fiecare bloc PEM în ordine), sau cu o singură comandă cat. Dacă ai primit fișiere separate pentru intermediar și rădăcină, rulează:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Dacă intermediarele și rădăcina se află deja într-un singur fișier .ca-bundle, rulează:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Înlocuiește numele de fișiere cu propriile tale nume. Mută fișierul combinat (și cheia privată, dacă nu se află deja acolo) în directorul SSL de pe serverul tău, de exemplu /etc/ssl/ sau /etc/nginx/ssl/. Păstrează fișierul cheii lizibil doar de root:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Pasul 2: Editează fișierul de configurare NGINX

Deschide fișierul de configurare NGINX pentru site-ul tău. Pe Debian și Ubuntu se află în /etc/nginx/sites-available/ (cu un link simbolic în sites-enabled/); pe RHEL, CentOS, AlmaLinux și Rocky Linux se află în /etc/nginx/conf.d/. Adaugă sau editează blocul server care ascultă pe portul 443, astfel încât să indice fișierul fullchain și cheia privată:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    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;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Câteva observații despre directivele de mai sus:

• listen 443 ssl; activează TLS pe portul 443. Directiva veche ssl on; a fost eliminată în NGINX 1.25 și nu ar trebui să apară în configurațiile moderne.
• http2 on; activează HTTP/2 ca directivă separată (NGINX 1.25.1 și versiuni ulterioare). Configurațiile mai vechi foloseau listen 443 ssl http2;, care încă funcționează, dar este depreciată.
• ssl_protocols TLSv1.2 TLSv1.3; dezactivează versiunile obsolete TLS 1.0 și 1.1. Începând cu NGINX 1.27.3, aceasta este și valoarea implicită dacă omiți directiva, dar setarea explicită este alegerea clară, ușor de auditat.
• Lista de cifruri corespunde profilului „intermediate” al Mozilla și funcționează pe orice client recent. Dacă ai nevoie doar de clienți TLS 1.3, poți elimina complet ssl_ciphers.

Pasul 3: Redirecționează HTTP către HTTPS

Adaugă un bloc server separat pe portul 80 care redirecționează permanent fiecare solicitare către HTTPS, astfel încât vizitatorii care ajung prin HTTP simplu să ajungă pe URL-ul securizat:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Utilizarea return 301 este mai rapidă și mai sigură decât o regulă rewrite bazată pe regex și este modelul recomandat chiar de NGINX.

Pasul 4: Testează configurația și reîncarcă NGINX

Validează întotdeauna configurația înainte de a reîncărca, pentru ca o greșeală de tastare să nu poată scoate serviciul din funcțiune:

sudo nginx -t

Ar trebui să vezi syntax is ok și test is successful. Dacă raportează o eroare, mesajul include fișierul și numărul liniei; corectează-o și rulează din nou testul. Când testul reușește, reîncarcă NGINX pentru ca acesta să preia noua configurație fără a întrerupe conexiunile existente:

sudo systemctl reload nginx

Pe sistemele fără systemd, folosește în schimb semnalul propriu de reîncărcare al NGINX:

sudo nginx -s reload

Preferă reload în locul lui restart: o reîncărcare recitește configurația fără a închide conexiunile active, în timp ce o repornire le întrerupe.

Pasul 5 (opțional): Activează OCSP stapling

OCSP stapling permite NGINX să livreze o stare de revocare proaspătă și semnată alături de certificat, astfel încât clienții nu mai trebuie să contacteze CA-ul la fiecare handshake. Adaugă următoarele în blocul tău server HTTPS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Reîncarcă NGINX din nou cu sudo systemctl reload nginx. Stapling-ul este un pas mic, dar util de securizare, iar majoritatea certificatelor moderne îl acceptă din start.

Verifică instalarea

Deschide site-ul tău prin https:// într-un browser și verifică dacă lacătul este închis și certificatul corespunde domeniului tău. Apoi rulează o scanare mai aprofundată cu SSL Checker-ul nostru pentru un raport instant despre certificat, lanț și protocoalele și cifrurile pe care le oferă serverul tău. Un rezultat verde acolo înseamnă că clienții de pe orice platformă majoră vor avea încredere în certificat, inclusiv clienții mobili și API.

Întrebări frecvente