Come generare un CSR su Postfix

Questa guida ti mostra come generare una CSR (Certificate Signing Request) su Postfix utilizzando la riga di comando OpenSSL. Postfix di per sé non genera chiavi o CSR; utilizza i file prodotti da OpenSSL e li richiama da /etc/postfix/main.cf. Esegui un unico comando che crea contemporaneamente due file: una chiave privata che rimane sul server e la CSR che invii alla tua Autorità di Certificazione (CA).

La CSR codifica il nome host che il tuo MTA presenta su STARTTLS, i dettagli della tua organizzazione e la parte pubblica della chiave. La chiave privata corrispondente non lascia mai il server. Se la perdi, il certificato emesso diventa inutilizzabile e devi ricominciare da capo.

Prerequisiti

• Accesso root o sudo al server che esegue Postfix.
• OpenSSL installato. È incluso nel sistema base di ogni distribuzione Linux principale; verifica con openssl version.
• Il nome host di posta completamente qualificato che desideri sul certificato, ad esempio mail.example.com. Deve corrispondere al record MX a cui i client si connettono tramite STARTTLS, non al dominio apex nudo.

Passo 1: Prepara una directory per la chiave e la CSR

Conserva il materiale TLS di Postfix in una propria directory sotto /etc/postfix/ in modo che i permessi siano facili da gestire. Creala e blocca l’accesso solo a root:

sudo mkdir -p /etc/postfix/ssl
sudo chmod 700 /etc/postfix/ssl
cd /etc/postfix/ssl

Genererai la chiave e la CSR all’interno di questa directory, per poi richiamarle da main.cf dopo che la CA avrà emesso il certificato.

Passo 2: Genera la chiave privata e la CSR

Esegui il comando riportato sotto. Crea la chiave privata e la CSR in un unico passaggio e include il Subject Alternative Name (SAN) richiesto dai browser moderni, dai client di posta e dalle CA. Il SAN deve elencare il nome host di posta (quello a cui punta il tuo record MX), non il dominio apex nudo:

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Ecco cosa fa ciascuna parte:

• req -new crea una nuova richiesta di firma del certificato.
• -newkey rsa:2048 genera una nuova chiave privata RSA a 2048 bit. 2048 bit è il minimo attuale per i certificati pubblici; puoi usare rsa:4096 per una chiave più grande.
• -nodes lascia la chiave privata non cifrata (nessuna passphrase), così Postfix può caricarla all’avvio senza chiedere alcuna conferma.
• -keyout scrive la chiave privata. Mantieni questo file privato e non inviarlo mai a nessuno, nemmeno alla CA.
• -out scrive la CSR che invii alla CA.
• -subj compila i campi del soggetto inline in modo che il comando venga eseguito senza richieste interattive. Impostare CN (Common Name) sul nome host di posta.
• -addext “subjectAltName=…” aggiunge la voce SAN. Le CA emettono i certificati in base all’elenco SAN, quindi il nome host di posta deve apparire qui.

Sostituisci mail.example.com con il nome host reale a cui si connettono i client (spesso lo stesso nome del tuo record MX), e modifica i valori -subj in modo che corrispondano alla tua organizzazione. Il codice paese di due lettere (C) deve essere in maiuscolo, ad esempio US o GB. Per un certificato con validazione del dominio (DV), i campi dell’organizzazione non vengono verificati, ma il comando richiede comunque valori validi. L’OpenSSL moderno firma la CSR con SHA-256 per impostazione predefinita, che è quanto richiesto da ogni CA pubblica.

Se preferisci compilare i campi in modo interattivo invece di usare -subj, elimina quella riga e OpenSSL ti chiederà ogni valore:

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-addext "subjectAltName=DNS:mail.example.com"

Quando richiesto, lascia vuoti la challenge password e il nome dell’azienda opzionale premendo Invio. Le CA ignorano questi campi, e una challenge password causa problemi in seguito.

Coprire più di un nome host

Se la stessa istanza Postfix risponde su più di un nome (ad esempio, sia mail.example.com che smtp.example.com, o un certificato condiviso per mail e webmail), elenca ogni nome host nel valore SAN, separati da virgole:

-addext "subjectAltName=DNS:mail.example.com,DNS:smtp.example.com,DNS:webmail.example.com"

Il Common Name deve rimanere il nome host di posta primario. Aggiungere il dominio apex nudo al SAN è utile solo se i client di posta si connettono mai direttamente a esso; se il tuo record MX punta a un sottodominio, non ti serve l’apex sul certificato.

Preferisci una chiave ECDSA?

Le chiavi ECDSA sono più piccole e più veloci di RSA allo stesso livello di sicurezza e sono supportate da tutti i client di posta e dalle CA attuali. Per generare invece una chiave e una CSR P-256 (prime256v1), sostituisci l’argomento -newkey:

sudo openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Passo 3: Proteggi la chiave privata

Blocca la chiave privata in modo che solo root possa leggerla. Postfix apre il suo materiale TLS prima di abbandonare i privilegi, quindi la proprietà di root e la modalità 600 sono entrambe corrette e necessarie:

sudo chown root:root /etc/postfix/ssl/mail.example.com.key
sudo chmod 600 /etc/postfix/ssl/mail.example.com.key

Il file CSR non è segreto (contiene solo la chiave pubblica e i tuoi dettagli del soggetto), ma mantenerlo nella stessa directory protetta rende l’organizzazione più ordinata.

Passo 4: Verifica la CSR

Prima di inviare la richiesta, confermare che contenga il nome host e il SAN corretti e che la sua firma sia valida. Questo comando stampa il contenuto decodificato e verifica la firma localmente:

openssl req -noout -text -verify -in /etc/postfix/ssl/mail.example.com.csr

Cerca verify OK nell’output, verifica che la riga Subject mostri il tuo nome host di posta come Common Name, e confermare che la sezione X509v3 Subject Alternative Name elenchi ogni nome host previsto. Se manca un SAN, rigenera la CSR con il valore -addext corretto: una CA non può aggiungere nomi host dopo l’emissione. Puoi anche incollare la CSR nel nostro CSR Decoder online per verificare questi campi nel browser.

Passo 5: Invia la CSR

Apri il file CSR e copia tutto il suo contenuto, incluse le righe BEGIN e END:

cat /etc/postfix/ssl/mail.example.com.csr

Il blocco appare così. Copia tutto dalla prima riga all’ultima, incluse le cinque trattini su ciascun lato dei marcatori BEGIN e END:

-----BEGIN CERTIFICATE REQUEST-----
MIIC...base64-encoded data...AB
-----END CERTIFICATE REQUEST-----

Incolla quel blocco nel tuo modulo d’ordine SSL. Dopo che la CA valida la CSR ed emette il certificato, segui le nostre istruzioni di installazione SSL per Postfix per distribuirlo. Conserva il file .key sul server: ti serve insieme al certificato emesso per servire STARTTLS, e non devi mai inviarlo alla CA o a chiunque altro.

Se preferisci non usare la riga di comando, crea la richiesta con il nostro CSR Generator e incolla il risultato nel tuo ordine. Il generatore restituisce una chiave privata corrispondente che posizionerai nel medesimo percorso sul server.

Dove vanno i file in Postfix

Per contesto, ecco come i file appena generati vengono collegati a Postfix una volta che la CA restituisce il certificato e l’intermedio (bundle CA). Su Postfix 3.4 e versioni successive, la forma con direttiva unica consigliata prevede un unico file PEM che contiene la chiave privata seguita dall’intera catena di certificati:

cat mail.example.com.key mail.example.com.crt intermediate.pem 
> /etc/postfix/ssl/mail.example.com.chain.pem
sudo chmod 600 /etc/postfix/ssl/mail.example.com.chain.pem

Poi in /etc/postfix/main.cf:

smtpd_tls_chain_files = /etc/postfix/ssl/mail.example.com.chain.pem
smtpd_tls_security_level = may

Su Postfix precedenti alla 3.4, usa la coppia di direttive legacy, con la chiave e un certificato a catena completa conservati in file separati:

smtpd_tls_cert_file = /etc/postfix/ssl/mail.example.com.fullchain.crt
smtpd_tls_key_file  = /etc/postfix/ssl/mail.example.com.key
smtpd_tls_security_level = may

Il percorso completo di installazione, incluso il servizio di invio sulla porta 587 e la verifica con OpenSSL, si trova nella nostra guida all’installazione SSL per Postfix.

Genera una CSR su altre piattaforme di posta

Usi un server di posta o un gateway diverso? Consulta le nostre altre guide sulle CSR:

• Courier IMAP Server
• Kerio Connect
• Qmail
• SurgeMail
• Zimbra
• Tutti i tutorial per la generazione di CSR