Comment générer un CSR sur Postfix

Ce guide vous montre comment générer une CSR (Certificate Signing Request) sur Postfix à l’aide de la ligne de commande OpenSSL. Postfix lui-même ne génère pas de clés ni de CSR ; il utilise les fichiers produits par OpenSSL et les référence depuis /etc/postfix/main.cf. Vous exécutez une seule commande qui crée deux fichiers à la fois : une clé privée qui reste sur le serveur, et la CSR que vous soumettez à votre autorité de certification (CA).

La CSR encode le nom d’hôte que votre MTA présente lors du STARTTLS, les détails de votre organisation, ainsi que la partie publique de la clé. La clé privée correspondante ne quitte jamais le serveur. Si vous la perdez, le certificat émis devient inutilisable et vous devez tout recommencer.

Prérequis

• Un accès root ou sudo au serveur exécutant Postfix.
• OpenSSL installé. Il est fourni de base dans le système sur toutes les principales distributions Linux ; vérifiez avec openssl version.
• Le nom d’hôte de messagerie pleinement qualifié que vous souhaitez sur le certificat, par exemple mail.example.com. Il doit correspondre à l’enregistrement MX auquel les clients se connectent via STARTTLS, et non au domaine apex nu.

Étape 1 : préparer un répertoire pour la clé et la CSR

Conservez les éléments TLS de Postfix dans leur propre répertoire sous /etc/postfix/ afin que les autorisations soient faciles à gérer. Créez-le et verrouillez-le pour root uniquement :

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

Vous allez générer la clé et la CSR dans ce répertoire, puis les référencer depuis main.cf une fois que la CA aura émis le certificat.

Étape 2 : générer la clé privée et la CSR

Exécutez la commande ci-dessous. Elle crée la clé privée et la CSR en une seule étape et inclut le Subject Alternative Name (SAN) qu’exigent les navigateurs modernes, les clients de messagerie et les CA. Le SAN doit lister le nom d’hôte de messagerie (celui vers lequel pointe votre enregistrement MX), et non le domaine apex nu :

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"

Voici ce que fait chaque partie :

• req -new crée une nouvelle demande de signature de certificat.
• -newkey rsa:2048 génère une nouvelle clé privée RSA de 2048 bits. 2048 bits est le minimum actuel pour les certificats publics ; vous pouvez utiliser rsa:4096 pour une clé plus grande.
• -nodes laisse la clé privée non chiffrée (sans phrase de passe), afin que Postfix puisse la charger au démarrage sans demander de confirmation.
• -keyout écrit la clé privée. Gardez ce fichier confidentiel et ne l’envoyez jamais à qui que ce soit, y compris à la CA.
• -out écrit la CSR que vous soumettez à la CA.
• -subj renseigne les champs du sujet directement afin que la commande s’exécute sans invites interactives. Définissez CN (Common Name) sur votre nom d’hôte de messagerie.
• -addext « subjectAltName=… » ajoute l’entrée SAN. Les CA émettent en se basant sur la liste SAN, donc le nom d’hôte de messagerie doit y figurer.

Remplacez mail.example.com par le nom d’hôte réel auquel les clients se connectent (souvent le même nom que votre enregistrement MX), et modifiez les valeurs de -subj pour qu’elles correspondent à votre organisation. Le code pays à deux lettres (C) doit être en majuscules, par exemple US ou GB. Pour un certificat à validation de domaine (DV), les champs d’organisation ne sont pas vérifiés, mais la commande a tout de même besoin de valeurs valides. OpenSSL moderne signe la CSR avec SHA-256 par défaut, ce qui est exigé par toutes les CA publiques.

Si vous préférez remplir les champs de manière interactive plutôt qu’avec -subj, supprimez cette ligne et OpenSSL vous invitera à saisir chaque valeur :

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"

Lorsque vous y êtes invité, laissez le mot de passe de défi (challenge password) et le nom d’entreprise optionnel vides en appuyant sur Entrée. Les CA ignorent ces champs, et un mot de passe de défi cause des problèmes par la suite.

Couvrir plus d’un nom d’hôte

Si la même instance Postfix répond sur plusieurs noms (par exemple, à la fois mail.example.com et smtp.example.com, ou un certificat partagé pour la messagerie et le webmail), listez chaque nom d’hôte dans la valeur SAN, séparés par des virgules :

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

Le Common Name doit rester le nom d’hôte de messagerie principal. Ajouter le domaine apex nu au SAN n’est utile que si des clients de messagerie s’y connectent directement ; si votre enregistrement MX pointe vers un sous-nom d’hôte, vous n’avez pas besoin de l’apex sur le certificat.

Vous préférez une clé ECDSA ?

Les clés ECDSA sont plus petites et plus rapides que les clés RSA à un niveau de sécurité équivalent, et sont prises en charge par tous les clients de messagerie et CA actuels. Pour générer à la place une clé P-256 (prime256v1) et une CSR, remplacez l’argument -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"

Étape 3 : protéger la clé privée

Verrouillez la clé privée afin que seul root puisse la lire. Postfix ouvre ses éléments TLS avant d’abandonner ses privilèges, donc la propriété root et le mode 600 sont à la fois corrects et requis :

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

Le fichier CSR n’est pas secret (il ne contient que la clé publique et vos détails de sujet), mais le conserver dans le même répertoire verrouillé permet de garder une structure ordonnée.

Étape 4 : vérifier la CSR

Avant de soumettre la demande, confirmez qu’elle contient le bon nom d’hôte et le bon SAN, et que sa signature est valide. Cette commande affiche le contenu décodé et vérifie la signature localement :

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

Recherchez verify OK dans le résultat, vérifiez que la ligne Subject affiche votre nom d’hôte de messagerie comme Common Name, et confirmez que la section X509v3 Subject Alternative Name liste chaque nom d’hôte attendu. Si un SAN est manquant, régénérez la CSR avec la bonne valeur -addext : une CA ne peut pas ajouter de noms d’hôtes après l’émission. Vous pouvez également coller la CSR dans notre décodeur de CSR en ligne pour vérifier ces champs dans un navigateur.

Étape 5 : soumettre la CSR

Ouvrez le fichier CSR et copiez tout son contenu, y compris les lignes BEGIN et END :

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

Le bloc ressemble à ceci. Copiez tout, de la première à la dernière ligne, y compris les cinq tirets de chaque côté des marqueurs BEGIN et END :

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

Collez ce bloc dans votre formulaire de commande SSL. Une fois que la CA a validé la CSR et émis le certificat, suivez nos instructions d’installation SSL pour Postfix pour le déployer. Conservez le fichier .key sur le serveur : vous en avez besoin avec le certificat émis pour servir STARTTLS, et vous ne devez jamais l’envoyer à la CA ou à qui que ce soit d’autre.

Si vous préférez ne pas utiliser la ligne de commande, créez la demande avec notre générateur de CSR et collez le résultat dans votre commande. Le générateur renvoie une clé privée correspondante que vous placerez au même emplacement sur le serveur.

Où placer les fichiers dans Postfix

À titre d’information, voici comment les fichiers que vous venez de générer sont intégrés à Postfix une fois que la CA a renvoyé le certificat et l’intermédiaire (CA bundle). Sur Postfix 3.4 et versions ultérieures, la forme recommandée à directive unique utilise un seul fichier PEM contenant la clé privée suivie de la chaîne complète de certificats :

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

Puis dans /etc/postfix/main.cf :

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

Sur les versions de Postfix antérieures à 3.4, utilisez l’ancienne paire de directives, avec la clé et un certificat en chaîne complète conservés dans des fichiers séparés :

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

Le guide d’installation complet, incluant le service de soumission sur le port 587 et la vérification avec OpenSSL, se trouve dans notre guide d’installation SSL pour Postfix.

Générer une CSR sur d’autres plateformes de messagerie

Vous utilisez un serveur ou une passerelle de messagerie différent ? Consultez nos autres guides de génération de CSR :

• Courier IMAP Server
• Kerio Connect
• Qmail
• SurgeMail
• Zimbra
• Tous les tutoriels de génération de CSR