bg-tutorials

Cum să generezi un CSR pe NGINX

Acest tutorial vă arată cum să generați un CSR pe NGINX. NGINX nu generează el însuși Cererile de Semnare a Certificatului: creați cheia privată și CSR-ul cu OpenSSL pe același server care va găzdui certificatul, apoi trimiteți CSR-ul către Autoritatea dvs. de Certificare. Când certificatul emis este primit înapoi, îl indicați către NGINX cu directivele ssl_certificate și ssl_certificate_key.

Pașii de mai jos funcționează pe orice distribuție Linux suportată care include NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), deoarece fiecare vine cu OpenSSL 1.1.1 sau 3.x. OpenSSL modern semnează cererile cu SHA-256 în mod implicit, deci nu trebuie să adăugați un flag de digest.

Pasul 1: Conectați-vă la serverul NGINX

Conectați-vă la serverul care rulează NGINX prin SSH de pe computerul dvs. local (Terminal pe macOS sau Linux, PowerShell sau Windows Terminal pe Windows). Înlocuiți numele de utilizator și hostul cu ale dvs.:

ssh your-user@your-nginx-server

Generați CSR-ul pe serverul care va servi certificatul. Cheia privată este creată alături de CSR și trebuie să rămână pe acel server. Rularea acestor comenzi local și apoi copierea cheii peste tot anulează scopul de a avea o cheie privată încă de la început.

Pasul 2: Generați cheia privată și CSR-ul

Executați următoarea comandă. Aceasta creează o cheie privată RSA de 2048 de biți și un CSR corespunzător într-un singur pas, cu subiectul și Numele Alternative ale Subiectului (SAN-uri) furnizate inline, astfel încât OpenSSL să nu se oprească pentru a pune întrebări:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Ce face fiecare parte:

  • -newkey rsa:2048 generează o nouă cheie RSA de 2048 de biți. 2048 de biți este minimul actual acceptat de CA-urile publice; puteți folosi rsa:4096 pentru o cheie mai mare, sau puteți trece la ECDSA (vezi mai jos).
  • -nodes lasă cheia privată necriptată, astfel încât NGINX să o poată citi la pornire fără a solicita o parolă. Dacă preferați să criptați cheia, eliminați -nodes și folosiți directiva ssl_password_file a NGINX pentru a furniza parola la pornire și la reîncărcare.
  • -keyout și -out denumesc fișierele cheii private și ale CSR-ului.
  • -subj furnizează subiectul certificatului. Introduceți aici numele real al companiei dvs., statul și orașul, nu marcatorii de poziție. CN (Common Name) este domeniul dvs. principal.
  • -addext „subjectAltName=…” listează fiecare nume de host pe care certificatul trebuie să îl acopere. CA-urile publice validează în raport cu lista SAN, deci includeți și Common Name aici. Flagul -addext necesită OpenSSL 1.1.1 sau mai nou; fiecare versiune Linux suportată vine cu cel puțin această versiune.

Înlocuiți yourdomain.com cu domeniul dvs. real de fiecare dată. Pentru a acoperi nume de host suplimentare, adăugați-le la lista SAN separate prin virgule, de exemplu DNS:api.yourdomain.com. Pentru un wildcard, includeți atât wildcard-ul cât și domeniul simplu: DNS:*.yourdomain.com,DNS:yourdomain.com.

Dacă preferați o cheie ECDSA (mai mică și mai rapidă, cu P-256 pe scară largă suportat), generați cheia și CSR-ul astfel:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Dacă OpenSSL-ul dvs. nu suportă -addext

Pe sisteme foarte vechi cu OpenSSL mai vechi decât 1.1.1, flagul -addext nu este disponibil. Creați un fișier de configurare mic numit san.cnf cu acest conținut:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
C  = US
ST = YourState
L  = YourCity
O  = YourCompany
CN = yourdomain.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = yourdomain.com
DNS.2 = www.yourdomain.com

Apoi executați:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key -out yourdomain.csr -config san.cnf

Pasul 3: Localizați-vă fișierele

Listați directorul curent pentru a confirma că ambele fișiere au fost create:

ls

Ar trebui să vedeți două fișiere noi:

  • yourdomain.key: cheia dvs. privată. Păstrați-o pe server, faceți o copie de rezervă în siguranță și nu o trimiteți niciodată nimănui, inclusiv Autorității de Certificare. Oricine deține cheia poate să vă imite site-ul.
  • yourdomain.csr: Cererea dvs. de Semnare a Certificatului. Acesta este fișierul pe care îl trimiteți furnizorului SSL.

Setați permisiuni stricte pentru cheia privată imediat, astfel încât doar root să o poată citi:

sudo chmod 600 yourdomain.key
sudo chown root:root yourdomain.key

Pasul 4: Verificați CSR-ul (opțional, dar recomandat)

Înainte de a-l trimite, verificați dacă CSR-ul conține subiectul și SAN-urile corecte și dacă semnătura sa este validă. Aceasta decodează cererea local cu OpenSSL:

openssl req -noout -text -verify -in yourdomain.csr

Confirmați că linia Subject arată detaliile dvs., că X509v3 Subject Alternative Name listează fiecare nume de host pe care îl așteptați, și că verificarea semnăturii afișează verify OK. Algoritmul de semnătură ar trebui să fie sha256WithRSAEncryption (sau ecdsa-with-SHA256 pentru o cheie ECDSA). Dacă preferați să nu folosiți linia de comandă, lipiți CSR-ul în decodorul nostru online CSR decoder pentru a citi aceleași câmpuri într-un browser.

Pasul 5: Trimiteți CSR-ul dvs.

Pentru a copia CSR-ul pentru comanda dvs., afișați conținutul acestuia:

cat yourdomain.csr

Veți vedea un bloc de text asemănător acestuia:

-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----

Copiați întregul bloc, inclusiv liniile ––BEGIN CERTIFICATE REQUEST–– și ––END CERTIFICATE REQUEST–– (fiecare marker are cinci liniuțe pe fiecare parte). Întregul bloc este CSR-ul dvs. Lipiți-l în formularul de comandă în timpul achiziției și păstrați cheia privată corespunzătoare la locul ei pe server.

Dacă preferați să nu folosiți linia de comandă, puteți construi cererea și cu generatorul nostru de CSR online. Rețineți că acesta generează cheia privată în browserul dvs., deci salvați-o dvs. singur și transferați-o pe server.

Ce se întâmplă după ce CA emite certificatul

Odată ce CA validează CSR-ul și emite certificatul, veți primi de obicei certificatul dvs. de server (un fișier .crt numit după domeniul dvs.) plus unul sau mai multe certificate intermediare, uneori grupate într-un fișier .ca-bundle. NGINX se așteaptă ca certificatul de server și lanțul intermediar să fie combinate într-un singur fișier („fullchain”) și indicate prin ssl_certificate; cheia privată pe care ați generat-o mai sus este indicată separat prin ssl_certificate_key. Procedura completă (construirea fullchain-ului, editarea blocului de server, testarea și reîncărcarea) este acoperită în tutorialul nostru de instalare SSL pentru NGINX.

Economisește 10% la certificatele SSL în momentul plasării comenzii!

Eliberare rapidă, criptare puternică, încredere în browser de 99,99%, suport dedicat și garanție de returnare a banilor în 25 de zile. Codul cuponului: SAVE10

A detailed image of a dragon in flight

Autor cu experiență, specializat în certificate SSL. Transformă subiectele complexe despre securitatea cibernetică în conținut clar și captivant. Contribuie la îmbunătățirea securității digite prin narațiuni cu impact.