Cum se generează un certificat autosemnat folosind OpenSSL?

Un certificat autosemnat este unul pe care ți-l emiți singur, în loc să-l cumperi de la o autoritate de certificare. Browserele nu îl vor considera automat de încredere, așa că nu are ce căuta pe un site public, dar este cea mai rapidă modalitate de a activa HTTPS pe un calculator de dezvoltare, pe un server de staging, pe un panou de administrare intern sau pe orice serviciu care nu este niciodată expus pe internetul public.

Acest ghid îți arată cum să creezi un certificat autosemnat cu OpenSSL pe Windows, Linux și macOS. Comanda este aceeași pe toate trei. De asemenea, vei vedea cum să verifici că certificatul obținut este de fapt utilizabil și cum să faci propriul calculator să aibă încredere în el, astfel încât avertismentele browserului să dispară.

Ce este un certificat autosemnat

Un certificat autosemnat este un certificat digital semnat cu propria sa cheie privată, nu de către o autoritate de certificare (CA) de încredere. Din punct de vedere criptografic, este un certificat X.509 obișnuit: criptează traficul exact la fel de bine ca unul achiziționat. Ceea ce îi lipsește este un lanț de încredere. Nimic din afara propriului calculator nu are vreun motiv să-l creadă, astfel încât browserele arată un avertisment până le spui altfel.

Acest lucru face din certificatele autosemnate o soluție potrivită pentru:

• Dezvoltare locală, unde ai nevoie de HTTPS pentru ca cookie-urile, service workers sau un SDK de plăți să se comporte așa cum vor face în producție.
• Servicii interne, cum ar fi un panou de intranet, un panou de monitorizare sau o interfață de management al dispozitivelor într-o rețea privată.
• Testare și staging, unde vrei să repeți o configurație TLS fără să consumi un certificat pentru asta.
• Servere de origine aflate în spatele unui proxy care acceptă un certificat de neîncredere pe segmentul din spate, cum este Cloudflare în modul Full.

Sunt instrumentul greșit pentru orice va fi încărcat de un vizitator real. Tratăm această distincție în detaliu mai jos, la secțiunea despre când să nu îl folosești.

Înainte de a începe: verifică-ți versiunea OpenSSL

Ai nevoie de instrumentul de linie de comandă OpenSSL. Confirmă ce versiune ai:

openssl version

• Linux: OpenSSL este preinstalat pe majoritatea distribuțiilor. Dacă nu este, vezi ghidul nostru despre cum se instalează OpenSSL pe Ubuntu.
• Windows: OpenSSL nu este inclus. Urmează instrucțiunile noastre despre cum se instalează OpenSSL pe Windows, apoi rulează comanda din Command Prompt sau PowerShell.
• macOS: Apple livrează LibreSSL, o ramificație (fork) a OpenSSL, ca instrument openssl integrat, astfel încât aceasta returnează ceva de genul LibreSSL 3.3.6, nu o versiune OpenSSL.

Comanda principală din acest ghid funcționează pe LibreSSL 3.3.6 la fel de bine ca pe OpenSSL actual, așa că utilizatorii de Mac pot folosi instrumentul integrat. Dacă preferi să ai OpenSSL autentic (unele dintre comenzile opționale de mai jos au nevoie de el), instalează-l cu managerul de pachete Homebrew și apelează-l prin calea completă:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

Pe Mac-urile cu Intel, calea este /usr/local/opt/openssl@3/bin/openssl. Pentru mai multe detalii despre interpretarea rezultatului, vezi ghidul nostru despre cum verifici versiunea OpenSSL.

Cum să creezi un certificat autosemnat cu OpenSSL

Pasul 1: Deschide un terminal

Pe Linux, apasă Ctrl + Alt + T sau caută „Terminal” în meniul de aplicații. Pe macOS, deschide Applications, apoi Utilities, apoi Terminal, sau apasă Cmd + Space și scrie „Terminal”. Pe Windows, apasă Win + R, scrie cmd și apasă Enter.

Pasul 2: Mergi în folderul unde vrei să fie fișierele

OpenSSL scrie rezultatul în orice director în care te afli în momentul respectiv, nu în directorul în care este instalat OpenSSL. Creează un folder pentru acest certificat și mergi în el, astfel încât cheia și certificatul să ajungă undeva unde le poți găsi:

mkdir my-cert
cd my-cert

Pe Windows, folosește aceleași două comenzi în Command Prompt. Nu rula comenzile din interiorul folderului programului OpenSSL: pe Windows acel director de multe ori nu este accesibil pentru scriere de către un utilizator obișnuit, iar amestecarea cheilor tale cu fișierele binare face ca acestea să se poată pierde cu ușurință.

Pasul 3: Rulează comanda pentru certificat

Această comandă unică generează împreună cheia privată și certificatul autosemnat. Înlocuiește example.com și www.example.com cu numele prin care serviciul tău va fi de fapt accesat:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Păstreaz-o pe o singură linie. Command Prompt și shell-urile Unix folosesc caractere diferite pentru continuarea liniei, iar o singură linie funcționează pretutindeni. Folosește ghilimele duble, nu simple, din același motiv: Command Prompt nu tratează ghilimelele simple ca ghilimele propriu-zise.

Iată ce face fiecare parte:

• req -x509: produce un certificat finalizat, semnat, în loc de o cerere de semnare a certificatului.
• -newkey rsa:2048: creează o nouă cheie privată RSA de 2048 de biți ca parte a aceleiași comenzi. 2048 de biți reprezintă minimul actual și o opțiune implicită sensibilă. Folosește rsa:4096 dacă politica ta necesită o cheie mai mare, cu costul unor negocieri (handshake) mai lente.
• -keyout private.key: numele fișierului pentru cheia privată.
• -out certificate.crt: numele fișierului pentru certificat.
• -days 365: cât timp rămâne valid certificatul. Consultă secțiunea despre valabilitate de mai jos înainte de a schimba acest lucru.
• -nodes: lasă cheia privată necriptată, astfel încât serverul tău web să poată porni fără ca un om să introducă o frază de acces.
• -addext „subjectAltName=…”: lista de nume de hosturi pentru care este valid certificatul. Fără aceasta, certificatul nu se potrivește cu nimic.
• -addext „basicConstraints=critical,CA:FALSE”: marchează certificatul drept certificat de entitate finală (server), nu drept autoritate de certificare.
• -addext „extendedKeyUsage=serverAuth”: precizează că certificatul este destinat autentificării unui server TLS. Platformele Apple tratează acest lucru drept obligatoriu.

De ce sunt importante cele trei opțiuni -addext

Aceste trei marcaje fac diferența dintre un certificat care funcționează și unul pe care clienții îl refuză categoric. Merită să le înțelegi, pentru că un certificat autosemnat creat fără ele eșuează în trei feluri care sunt ușor de diagnosticat greșit.

Subject Alternative Name este locul unde „locuiesc” numele de hosturi. Browserele au încetat de ani buni să mai citească câmpul Common Name și acum verifică potrivirea numelui de host doar cu extensia Subject Alternative Name (SAN). Un certificat fără SAN nu se potrivește cu niciun site, indiferent cât de corect pare Common Name-ul. Enumeră toate numele pe care le vei folosi, separate prin virgulă. Pentru un serviciu local poți include și o adresă IP:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

Fără CA:FALSE, OpenSSL îți construiește un certificat CA. Când req -x509 este lăsat pe setările implicite, acesta stabilește basicConstraints la critical, CA:TRUE, ceea ce descrie o autoritate de certificare, nu un server web. Chrome și Safari acceptă acest lucru pe un certificat de server. Firefox nu, și se blochează cu MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Poți încă să apeși pe Advanced și să adaugi o excepție, dar în acest caz ai lucra în jurul unui certificat despre care știi deja că este malformat, iar alți clienți trasează limita în alte locuri. Trecerea opțiunii basicConstraints=critical,CA:FALSE evită situația de la bun început.

Versiunea LibreSSL livrată de macOS se comportă diferit aici: lăsată pe setările implicite, scrie un certificat X.509 versiunea 1 fără nicio extensie, așa că nu ai problema CA:TRUE, dar nici Subject Alternative Name. Furnizarea explicită a extensiilor îți dă același certificat corect pe ambele instrumente.

Fără serverAuth, platformele Apple resping certificatul. Cerințele publicate de Apple pentru certificatele de încredere stipulează că un certificat de server TLS trebuie să conțină o extensie ExtendedKeyUsage care include OID-ul id-kp-serverAuth. Un certificat fără aceasta eșuează la validarea certificatelor macOS în cadrul politicii TLS cu mesajul „Invalid Extended Key Usage for policy”, chiar și atunci când certificatul este furnizat ca propria sa ancoră de încredere. Firefox și Chrome sunt mai permisive și tratează absența ExtendedKeyUsage pe un certificat de server ca fiind permisă, așa că această omisiune este ușor de trecut cu vederea până când un Mac sau un iPhone este cel care refuză conectarea. Adăugarea lui extendedKeyUsage=serverAuth nu costă nimic pe celelalte platforme și este exact ceea ce ar emite oricum o CA publică.

Pasul 4: Completează detaliile certificatului

OpenSSL solicită câmpurile care alcătuiesc Distinguished Name. Apasă Enter pentru a sări peste orice câmp, dar completează cel puțin unul, iar acesta să fie Common Name. Versiunea LibreSSL de pe macOS se blochează cu „error, no objects specified in config file” și nu scrie nimic dacă lași toate câmpurile necompletate. Valorile de mai jos sunt exemple, folosește-le pe ale tale:

• Country Name: codul din două litere al țării tale, de exemplu US.
• State or Province Name: scris integral, de exemplu California.
• Locality Name: orașul tău, de exemplu San Jose.
• Organization Name: numele companiei sau proiectului tău, de exemplu Example Inc.
• Organizational Unit Name: echipa responsabilă, de exemplu IT.
• Common Name: numele principal de host, de exemplu example.com. Folosește același nume pe care l-ai pus primul în lista Subject Alternative Name.
• Email Address: o adresă de contact, de exemplu [email protected]. Opțional.

Doar Common Name are cu adevărat importanță aici, și doar ca etichetă: potrivirea numelui de host se face prin Subject Alternative Name, deja stabilit în linia de comandă. Restul este descriptiv.

Vei observa că comanda nu solicită niciodată o parolă de tip challenge. Acel prompt aparține cererilor de semnare a certificatelor și este un câmp vestigial, pe care CA-urile în general îl ignoră sau îl resping. Pentru că această comandă produce un certificat finalizat, nu o cerere, promptul nu apare deloc.

Pasul 5: Verifică certificatul înainte de a-l folosi

Nu sări peste acest pas. Un certificat autosemnat poate fi generat cu succes și totuși să fie inutilizabil, iar defecțiunea se manifestă abia mai târziu, ca o eroare de browser. Citește certificatul înapoi:

openssl x509 -in certificate.crt -noout -text

În blocul de extensii X509v3 cauți exact trei lucruri:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Dacă linia Subject Alternative Name lipsește, certificatul nu se va potrivi cu niciun nume de host. Dacă Basic Constraints indică CA:TRUE, Firefox se va bloca la el. Dacă linia Extended Key Usage lipsește, platformele Apple vor refuza certificatul. În orice caz de acest fel, șterge cele două fișiere și rulează comanda din nou cu toate cele trei opțiuni -addext prezente.

Pe OpenSSL 3.x poți solicita doar aceste extensii, în loc să citești tot certificatul:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

Opțiunea -ext nu există în versiunea LibreSSL livrată de macOS, care raportează „unknown option -ext”. Pe un Mac de fabrică, folosește varianta -text de mai sus.

Pentru a confirma că certificatul și cheia se corespund, compară modulii lor. Cele două comenzi trebuie să afișeze același hash:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

Certificatul propriu-zis este un fișier text. Deschiderea lui într-un editor de text arată un bloc base64 între liniile BEGIN CERTIFICATE și END CERTIFICATE, care este ceea ce lipești în panourile de control care cer certificatul, nu o încărcare de fișier.

Variații ale comenzii

Generează-l fără niciun prompt

Pentru scripturi și pipeline-uri CI, furnizează Distinguished Name cu -subj și comanda se execută automat, fără intervenție:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Folosește o cheie EC în locul RSA

Cheile pe curbe eliptice (EC) sunt mai mici și mai rapide decât RSA la o rezistență echivalentă, iar toate browserele actuale le suportă. P-256 este alegerea standard:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Rezultatul este semnat cu ecdsa-with-SHA256. Rămâne la RSA dacă trebuie să susții clienți embedded vechi sau versiuni Java mai vechi, care uneori nu au suport EC.

Folosește OpenSSL autentic pentru acest caz. Versiunea LibreSSL de pe macOS acceptă comanda, dar scrie curba în certificat ca un set complet de parametri expliciți, în loc de identificatorul standard P-256. RFC 5480 precizează că forma explicită nu trebuie folosită în certificate, iar macOS însuși respinge un certificat codificat astfel.

Verifică rezultatul cu openssl x509 -in certificate.crt -noout -text: vrei o linie cu textul „ASN1 OID: prime256v1”, nu un bloc care listează Prime, A, B și Generator. Pe un Mac de fabrică, folosește fie comanda RSA de mai sus, fie instalează întâi OpenSSL prin Homebrew.

-nodes sau -noenc?

Ambele marcaje fac același lucru: opresc OpenSSL de la criptarea cheii private cu o frază de acces. OpenSSL 3.x a adăugat -noenc ca denumire mai clară și listează -nodes ca fiind depreciat, chiar dacă îl acceptă în continuare. LibreSSL, livrat de macOS, nu recunoaște deloc -noenc și returnează o eroare.

Acest ghid folosește -nodes pentru că este opțiunea care funcționează pe orice versiune pe care este probabil să o întâlnești, inclusiv pe un Mac de fabrică. Dacă folosești OpenSSL 3.x și vrei să eviți denumirea depreciată, înlocuiește cu -noenc. Nimic altceva nu se schimbă.

Dacă renunți complet la acest marcaj, OpenSSL criptează cheia cu o frază de acces la alegere, iar serverul tău web va solicita apoi această frază la fiecare repornire. Acest lucru este rareori ceea ce vrei pentru un certificat de dezvoltare.

Fă-ți calculatorul să aibă încredere în certificat

Un certificat autosemnat corect încă generează un avertisment de browser, pentru că nimic nu a fost instruit să aibă încredere în el. Adăugarea lui în magazinul de încredere local este ceea ce dezactivează avertismentul și este de obicei chiar scopul creării unuia.

Fă acest lucru doar pe calculatoare pe care le controlezi și doar pentru certificate pe care le-ai generat tu însuți. Un certificat de încredere este de încredere pentru fiecare site pe care îl numește, așa că tratează cheia privată în consecință și nu o distribui niciodată.

Keychain-ul macOS

Adaugă certificatul în keychain-ul de sistem și marchează-l ca de încredere pentru TLS. Ți se va cere parola de administrator:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

Partea -p ssl limitează încrederea la conexiunile TLS. Omite-o și certificatul va fi de încredere pentru orice scop cunoscut de macOS, inclusiv semnarea de cod, ceea ce este mult mai mult decât are nevoie un certificat de dezvoltare.

Pentru a face acest lucru prin interfață, dă dublu clic pe fișierul certificatului pentru a deschide Keychain Access, găsește intrarea din keychain-ul System, deschide-o, expandează Trust și setează When using this certificate la Always Trust. Pentru a anula asta mai târziu, șterge intrarea din Keychain Access.

Magazinul de certificate Windows

Deschide Command Prompt ca administrator (apasă Win + R, scrie cmd, apoi apasă Ctrl + Shift + Enter) și adaugă certificatul în magazinul Trusted Root Certification Authorities:

certutil -addstore -f "Root" certificate.crt

Alternativ, dă dublu clic pe fișierul certificatului, alege Install Certificate, selectează Local Machine, apoi Place all certificates in the following store și navighează la Trusted Root Certification Authorities. Pentru a-l elimina mai târziu, deschide certmgr.msc și șterge intrarea din acel magazin.

ca-certificates pe Linux

Pe Debian și Ubuntu, copiază certificatul în directorul local de ancore și reconstruiește pachetul. Fișierul trebuie să-și păstreze extensia .crt, altfel instrumentul de actualizare îl va ignora:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Pe RHEL, CentOS, AlmaLinux, Rocky și Fedora, căile diferă:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Excepția Firefox

Firefox își păstrează propriul magazin de încredere, în loc să-l folosească pe cel al sistemului de operare. Pe Windows și macOS, el citește implicit și rădăcinile adăugate în magazinul sistemului de operare, așa că pașii de mai sus îl cuprind de obicei. Pe Linux nu face acest lucru, așa că certificatul trebuie importat direct în Firefox: deschide Settings, apoi Privacy & Security, derulează la Certificates, dă clic pe View Certificates, deschide fila Authorities și folosește Import.

Repornește browserul după fiecare dintre aceste modificări. Browserele memorează în cache deciziile privind certificatele, iar o sesiune expirată este un motiv frecvent pentru care avertismentul pare să persiste după un import corect.

Când să nu folosești un certificat autosemnat

Nu-l pune niciodată pe un site pe care publicul îl va vizita. Fiecare vizitator primește un avertisment de securitate pe ecran întreg, iar cei care continuă totuși au fost învățați să treacă exact prin avertismentul care îi protejează de un atac real. De asemenea, un vizitator nu are nicio modalitate de a distinge certificatul tău autosemnat de cel al unui atacator, motiv pentru care browserele nu au încredere în ele. Discutăm detaliile în articolul nostru despre pericolele certificatelor autosemnate.

Certificatele autosemnate nu satisfac nici cerințe practice dincolo de avertismentul browserului. Procesatorii de plăți, magazinele de aplicații, aplicațiile mobile cu certificate pinning și majoritatea regimurilor de conformitate necesită un certificat de la o CA recunoscută. Pentru orice este orientat spre public, folosește un certificat emis de o autoritate de certificare de încredere, pe care îl soliciți printr-un CSR și îl validezi înainte de emitere. Odată activ, confirmă instalarea cu SSL Checker al nostru.