Come generare un certificato autofirmato utilizzando OpenSSL?

Un certificato autofirmato è un certificato che rilasci a te stesso invece di acquistarlo da un’autorità di certificazione. I browser non lo considerano automaticamente attendibile, quindi non ha posto su un sito web pubblico, ma è il modo più rapido per attivare HTTPS su una macchina di sviluppo, un server di staging, una dashboard interna o qualsiasi servizio che non è mai esposto a internet aperto.

Questa guida mostra come creare un certificato autofirmato con OpenSSL su Windows, Linux e macOS. Il comando è identico su tutti e tre i sistemi. Vedrai anche come verificare che il certificato prodotto sia effettivamente utilizzabile e come far sì che la tua macchina lo consideri attendibile, in modo che gli avvisi del browser scompaiano.

Cos’è un certificato autofirmato

Un certificato autofirmato è un certificato digitale firmato con la propria chiave privata piuttosto che da una autorità di certificazione (CA) attendibile. Dal punto di vista crittografico è un normale certificato X.509: cifra il traffico esattamente come farebbe uno acquistato. Ciò che gli manca è una catena di fiducia. Nulla al di fuori della tua macchina ha motivo di considerarlo attendibile, quindi i browser mostrano un avviso finché non li istruisci diversamente.

Questo rende i certificati autofirmati adatti a:

• Sviluppo locale, dove hai bisogno di HTTPS affinché i cookie, i service worker o un SDK di pagamento si comportino come faranno in produzione.
• Servizi interni, come una dashboard intranet, un pannello di monitoraggio o un’interfaccia di gestione dispositivi su una rete privata.
• Test e staging, dove vuoi provare una configurazione TLS senza spendere un certificato per questo.
• Server di origine dietro un proxy che accetta un certificato non attendibile sul lato back-end, come Cloudflare in modalità Full.

Sono lo strumento sbagliato per qualsiasi cosa che un visitatore reale caricherà. Approfondiamo questa distinzione più avanti, nella sezione su quando non usarne uno.

Prima di iniziare: verifica il tuo OpenSSL

Hai bisogno dello strumento a riga di comando OpenSSL. Verifica quale versione hai:

openssl version

• Linux: OpenSSL è preinstallato sulla maggior parte delle distribuzioni. Se non lo è, consulta la nostra guida su come installare OpenSSL su Ubuntu.
• Windows: OpenSSL non è incluso. Segui le nostre istruzioni su come installare OpenSSL su Windows, poi esegui il comando dal Prompt dei comandi o da PowerShell.
• macOS: Apple distribuisce LibreSSL, un fork di OpenSSL, come comando openssl integrato, quindi questo restituisce qualcosa come LibreSSL 3.3.6 piuttosto che una versione di OpenSSL.

Il comando principale di questa guida funziona sia su LibreSSL 3.3.6 che sull’attuale OpenSSL, quindi gli utenti Mac possono usare lo strumento integrato. Se preferisci avere il vero OpenSSL (alcuni dei comandi opzionali qui sotto lo richiedono), installalo con il gestore di pacchetti Homebrew e richiamalo con il suo percorso completo:

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

Sui Mac con processore Intel il percorso è invece /usr/local/opt/openssl@3/bin/openssl. Per maggiori dettagli sulla lettura dell’output, consulta la nostra guida su come verificare la versione di OpenSSL.

Come creare un certificato autofirmato con OpenSSL

Passaggio 1: Apri un terminale

Su Linux, premi Ctrl + Alt + T oppure cerca “Terminale” nel menu delle applicazioni. Su macOS, apri Applicazioni, poi Utility, poi Terminale, oppure premi Cmd + Spazio e digita “Terminale”. Su Windows, premi Win + R, digita cmd e premi Invio.

Passaggio 2: Spostati nella cartella dove vuoi i file

OpenSSL scrive il suo output nella directory in cui ti trovi attualmente, non nella directory in cui è installato OpenSSL. Crea una cartella per questo certificato e spostati al suo interno, così la chiave e il certificato finiranno in un posto che potrai trovare facilmente:

mkdir my-cert
cd my-cert

Su Windows, usa gli stessi due comandi nel Prompt dei comandi. Non eseguire i comandi dall’interno della cartella del programma OpenSSL: su Windows quella directory spesso non è scrivibile da un utente normale, e mescolare le tue chiavi con i file binari le rende facili da perdere.

Passaggio 3: Esegui il comando per il certificato

Questo singolo comando genera insieme la chiave privata e il certificato autofirmato. Sostituisci example.com e www.example.com con i nomi con cui il tuo servizio sarà effettivamente raggiunto:

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"

Mantienilo su una sola riga. Il Prompt dei comandi e le shell Unix usano caratteri di continuazione riga diversi, e una singola riga funziona ovunque. Usa le virgolette doppie, non quelle singole, per lo stesso motivo: il Prompt dei comandi non tratta le virgolette singole come delimitatori.

Ecco cosa fa ciascuna parte:

• req -x509: produce un certificato firmato e finito invece di una richiesta di firma del certificato.
• -newkey rsa:2048: crea una nuova chiave privata RSA a 2048 bit come parte dello stesso comando. 2048 bit è il minimo attuale e una scelta predefinita sensata. Usa rsa:4096 se la tua politica richiede una chiave più grande, al costo di handshake più lenti.
• -keyout private.key: il nome del file per la chiave privata.
• -out certificate.crt: il nome del file per il certificato.
• -days 365: per quanto tempo il certificato rimane valido. Consulta la sezione sulla validità più sotto prima di modificarlo.
• -nodes: lascia la chiave privata non cifrata, così il tuo server web può avviarsi senza che una persona digiti una passphrase.
• -addext “subjectAltName=…”: l’elenco dei nomi host per cui il certificato è valido. Senza questo, il certificato non corrisponde a nulla.
• -addext “basicConstraints=critical,CA:FALSE”: contrassegna il certificato come certificato end-entity (server) piuttosto che come autorità di certificazione.
• -addext “extendedKeyUsage=serverAuth”: dichiara che il certificato serve per autenticare un server TLS. Le piattaforme Apple lo trattano come obbligatorio.

Perché le tre opzioni -addext sono importanti

Questi tre flag fanno la differenza tra un certificato che funziona e uno che i client rifiutano subito. Vale la pena capirli, perché un certificato autofirmato creato senza di essi fallisce in tre modi che sono facili da diagnosticare male.

Il Subject Alternative Name è dove vivono i nomi host. I browser hanno smesso di leggere il campo Common Name anni fa e ora confrontano il nome host solo con l’estensione Subject Alternative Name (SAN). Un certificato senza SAN non corrisponde a nessun sito, per quanto corretto possa sembrare il Common Name. Elenca ogni nome che utilizzerai, separato da virgole. Per un servizio locale puoi includere anche un indirizzo IP:

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

Senza CA:FALSE, OpenSSL costruisce per te un certificato CA. Quando req -x509 viene lasciato ai suoi valori predefiniti, imposta basicConstraints su critical, CA:TRUE, il che descrive un’autorità di certificazione, non un server web. Chrome e Safari accettano questo su un certificato server. Firefox no, e si blocca con MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Puoi ancora cliccare su Avanzate e aggiungere un’eccezione, ma starai lavorando intorno a un certificato che sai già essere malformato, e altri client tracciano il confine in punti diversi. Passare basicConstraints=critical,CA:FALSE evita la situazione fin dall’inizio.

La build di LibreSSL distribuita da macOS si comporta diversamente qui: lasciata ai suoi valori predefiniti, scrive un certificato X.509 versione 1 senza alcuna estensione, quindi non ottieni il problema CA:TRUE ma nemmeno il Subject Alternative Name. Fornire le estensioni esplicitamente ti dà lo stesso certificato corretto su entrambi gli strumenti.

Senza serverAuth, le piattaforme Apple rifiutano il certificato. I requisiti pubblicati da Apple per i certificati attendibili stabiliscono che un certificato server TLS deve avere un’estensione ExtendedKeyUsage contenente l’OID id-kp-serverAuth. Un certificato senza di essa fallisce la validazione dei certificati macOS sotto la politica TLS con il messaggio “Invalid Extended Key Usage for policy”, anche quando il certificato è fornito come proprio trust anchor. Firefox e Chrome sono più permissivi e trattano un ExtendedKeyUsage assente su un certificato server come consentito, quindi questo è facile da trascurare finché non è un Mac o un iPhone a non riuscire a connettersi. Aggiungere extendedKeyUsage=serverAuth non costa nulla sulle altre piattaforme ed è comunque quello che una CA pubblica emetterebbe.

Passaggio 4: Compila i dettagli del certificato

OpenSSL chiede i campi che compongono il Distinguished Name. Premi Invio per saltare uno qualsiasi di essi, ma compilane almeno uno, e rendilo il Common Name. La build di LibreSSL su macOS si blocca con “error, no objects specified in config file” e non scrive nulla se lasci ogni campo vuoto. I valori qui sotto sono esempi, quindi usa i tuoi:

• Country Name: il codice a due lettere per il tuo paese, ad esempio US.
• State or Province Name: scritto per intero, ad esempio California.
• Locality Name: la tua città, ad esempio San Jose.
• Organization Name: il nome della tua azienda o progetto, ad esempio Example Inc.
• Organizational Unit Name: il team responsabile, ad esempio IT.
• Common Name: il nome host principale, ad esempio example.com. Usa lo stesso nome che hai messo per primo nell’elenco Subject Alternative Name.
• Email Address: un indirizzo di contatto, ad esempio [email protected]. Opzionale.

Solo il Common Name conta davvero qui, e solo come etichetta: la corrispondenza del nome host viene fatta tramite il Subject Alternative Name che hai già impostato sulla riga di comando. Tutto il resto è descrittivo.

Noterai che il comando non chiede mai una challenge password. Quel prompt appartiene alle richieste di firma del certificato, ed è un campo vestigiale che le CA generalmente ignorano o rifiutano. Poiché questo comando produce un certificato finito piuttosto che una richiesta, il prompt non appare affatto.

Passaggio 5: Verifica il certificato prima di usarlo

Non saltare questo passaggio. Un certificato autofirmato può essere generato con successo e risultare comunque inutilizzabile, e il problema si manifesta solo più tardi come errore del browser. Leggi nuovamente il certificato:

openssl x509 -in certificate.crt -noout -text

Nel blocco delle estensioni X509v3 stai cercando esattamente tre cose:

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

Se la riga Subject Alternative Name è assente, il certificato non corrisponderà a nessun nome host. Se Basic Constraints indica CA:TRUE, Firefox si bloccherà. Se la riga Extended Key Usage è assente, le piattaforme Apple rifiuteranno il certificato. In uno qualsiasi di questi casi, elimina i due file ed esegui nuovamente il comando con tutte e tre le opzioni -addext presenti.

Su OpenSSL 3.x puoi richiedere solo quelle estensioni invece di leggere l’intero certificato:

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

Il flag -ext non esiste nella build di LibreSSL distribuita da macOS, che riporta “unknown option -ext”. Su un Mac standard, usa la versione con -text mostrata sopra.

Per confermare che il certificato e la chiave appartengano insieme, confronta i loro moduli. I due comandi devono stampare lo stesso hash:

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

Il certificato stesso è un file di testo. Aprendolo in un editor di testo mostra un blocco base64 tra le righe BEGIN CERTIFICATE e END CERTIFICATE, che è ciò che incolli nei panel di controllo che chiedono il certificato piuttosto che un upload di file.

Varianti del comando

Generarlo senza alcun prompt

Per script e pipeline CI, fornisci il Distinguished Name con -subj e il comando viene eseguito senza interazione:

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"

Usare una chiave EC invece di RSA

Le chiavi a curva elittica sono più piccole e più rapide rispetto a RSA a parità di robustezza, e ogni browser attuale le supporta. P-256 è la scelta 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"

Il risultato è firmato con ecdsa-with-SHA256. Rimani su RSA se devi supportare vecchi client embedded o versioni Java legacy, che a volte non hanno il supporto EC.

Usa il vero OpenSSL per questo. La build di LibreSSL su macOS accetta il comando, ma scrive la curva nel certificato come un insieme completo di parametri espliciti invece dell’identificatore standard P-256. L’RFC 5480 stabilisce che la forma esplicita non deve essere usata nei certificati, e macOS stesso rifiuta un certificato codificato in quel modo.

Verifica il risultato con openssl x509 -in certificate.crt -noout -text: vuoi vedere una riga che dice “ASN1 OID: prime256v1”, non un blocco che elenca Prime, A, B e Generator. Su un Mac standard, usa il comando RSA mostrato sopra oppure installa prima OpenSSL tramite Homebrew.

-nodes o -noenc?

Entrambi i flag fanno la stessa cosa: impediscono a OpenSSL di cifrare la chiave privata con una passphrase. OpenSSL 3.x ha introdotto -noenc come nome più chiaro ed elenca -nodes come deprecato, sebbene lo accetti ancora. LibreSSL, distribuita da macOS, non riconosce affatto -noenc e genera un errore.

Questa guida usa -nodes perché è l’opzione che funziona su ogni build che è probabile incontrare, incluso un Mac standard. Se sei su OpenSSL 3.x e vuoi evitare la dicitura deprecata, sostituiscilo con -noenc. Nulla altro cambia.

Se elimini del tutto il flag, OpenSSL cifra la chiave con una passphrase che scegli tu, e il tuo server web ti chiederà poi di digitarla a ogni riavvio. Questo è raramente ciò che vuoi per un certificato di sviluppo.

Fai in modo che la tua macchina consideri attendibile il certificato

Un certificato autofirmato corretto produce comunque un avviso del browser, perché non è stato detto a nulla di considerarlo attendibile. Aggiungerlo al tuo trust store locale è ciò che disattiva l’avviso, ed è di solito lo scopo stesso di crearne uno.

Fai questo solo su macchine che controlli, e solo per certificati che hai generato tu stesso. Un certificato attendibile è attendibile per ogni sito che nomina, quindi tratta la chiave privata di conseguenza e non condividerla mai.

Portachiavi di macOS

Aggiungi il certificato al portachiavi di sistema e contrassegnalo come attendibile per TLS. Ti verrà chiesta la password di amministratore:

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

La parte -p ssl limita la fiducia alle connessioni TLS. Se la omitti, il certificato è attendibile per ogni scopo che macOS conosce, incluso il code signing, che è molto più di quanto un certificato di sviluppo necessiti.

Per farlo tramite l’interfaccia grafica, fai doppio clic sul file del certificato per aprire Accesso Portachiavi, trova la voce nel portachiavi System, aprila, espandi Trust, e imposta Quando si utilizza questo certificato su Attendi sempre. Per annullare l’operazione in seguito, elimina la voce da Accesso Portachiavi.

Archivio certificati di Windows

Apri il Prompt dei comandi come amministratore (premi Win + R, digita cmd, poi premi Ctrl + Shift + Invio) e aggiungi il certificato all’archivio Autorità di certificazione radice attendibili:

certutil -addstore -f "Root" certificate.crt

In alternativa, fai doppio clic sul file del certificato, scegli Installa certificato, seleziona Computer locale, poi Inserisci tutti i certificati nel seguente archivio, e sfoglia fino a Autorità di certificazione radice attendibili. Per rimuoverlo in seguito, apri certmgr.msc ed elimina la voce da quell’archivio.

ca-certificates su Linux

Su Debian e Ubuntu, copia il certificato nella directory delle ancore locali e ricostruisci il bundle. Il file deve mantenere l’estensione .crt oppure lo strumento di aggiornamento lo ignorerà:

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

Su RHEL, CentOS, AlmaLinux, Rocky e Fedora, i percorsi sono diversi:

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

L’eccezione di Firefox

Firefox mantiene un proprio trust store piuttosto che usare quello del sistema operativo. Su Windows e macOS legge anche di default le radici aggiunte all’archivio del sistema operativo, quindi i passaggi sopra normalmente lo coprono. Su Linux non lo fa, quindi il certificato deve essere importato direttamente in Firefox: apri Impostazioni, poi Privacy e sicurezza, scorri fino a Certificati, clicca su Visualizza certificati, apri la scheda Autorità, e usa Importa.

Riavvia il browser dopo qualsiasi di queste modifiche. I browser memorizzano nella cache le decisioni sui certificati, e una sessione non aggiornata è una causa comune per cui l’avviso sembra persistere dopo un’importazione corretta.

Quando non usare un certificato autofirmato

Non metterne mai uno su un sito che il pubblico visiterà. Ogni visitatore riceve un avviso di sicurezza a schermo intero, e coloro che procedono comunque sono stati addestrati a cliccare oltre esattamente l’avviso che li protegge da un attacco reale. Non c’è inoltre nessun modo per un visitatore di distinguere il tuo certificato autofirmato da quello di un attaccante, che è esattamente il motivo per cui i browser non li considerano attendibili. Approfondiamo i dettagli nel nostro articolo sui pericoli dei certificati autofirmati.

I certificati autofirmati falliscono anche requisiti pratici oltre l’avviso del browser. I processori di pagamento, gli app store, le app mobile con certificate pinning e la maggior parte dei regimi di conformità richiedono un certificato da una CA riconosciuta. Per qualsiasi cosa esposta al pubblico, usa un certificato rilasciato da un’autorità di certificazione attendibile, che richiedi con una CSR e convalidi prima dell’emissione. Una volta attivo, confermane l’installazione con il nostro SSL Checker.