Comment générer un CSR sur Qmail

Ce guide vous montre comment générer une CSR (Certificate Signing Request) sur qmail en utilisant la ligne de commande OpenSSL. Qmail (et son fork activement maintenu, notqmail) n’inclut pas d’outil de CSR intégré. Vous utilisez OpenSSL pour créer deux fichiers en une seule 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 de messagerie que votre serveur présente pendant STARTTLS, les détails de votre organisation, et la moitié 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 générer une nouvelle paire.

Une note sur qmail vs. notqmail : le qmail original a été figé par Daniel J. Bernstein en 1998 et n’a reçu aucune mise à jour officielle depuis. notqmail (dernière version : 1.09, mai 2024) est le fork maintenu par la communauté qui ajoute des correctifs de sécurité, une compatibilité de compilation actuelle et un travail continu de portabilité. TLS n’en fait pas partie : sur notqmail, comme sur le qmail original, STARTTLS provient d’un correctif externe, et les notes de version 1.09 indiquent que le correctif smtp-tls existant ne s’applique pas à cette version et qu’un nouveau correctif officiel est nécessaire. Vérifiez l’état des correctifs pour la version que vous utilisez avant de commander un certificat. Le processus de génération de CSR est identique pour les deux, car il utilise OpenSSL plutôt qu’un binaire qmail quelconque. Si vous utilisez toujours le qmail original, envisagez de migrer vers notqmail ou Postfix pour bénéficier d’un support de sécurité continu.

Prérequis

• Accès root ou sudo au serveur exécutant qmail (ou notqmail).
• OpenSSL installé. Il est fourni dans le système de base de chaque distribution Linux et BSD courante. Vérifiez avec openssl version.
• Le nom d’hôte de messagerie complet (FQDN) 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 racine nu.

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

Qmail-smtpd lit son certificat TLS depuis /var/qmail/control/servercert.pem, le chemin codé en dur par le correctif TLS. Créez un sous-répertoire pour le matériel de clé et verrouillez-le au root :

sudo mkdir -p /var/qmail/control/ssl
sudo chmod 700 /var/qmail/control/ssl
cd /var/qmail/control/ssl

Vous allez générer la clé et la CSR à l’intérieur de ce répertoire. Une fois que la CA a émis le certificat, vous combinez les fichiers dans le servercert.pem que qmail-smtpd lit au démarrage.

É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) que les clients de messagerie modernes et les CA exigent. Le SAN doit lister le nom d’hôte de messagerie (celui vers lequel pointe votre enregistrement MX) :

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /var/qmail/control/ssl/mail.example.com.key 
-out /var/qmail/control/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 qmail-smtpd puisse la charger au démarrage sans invite.
• -keyout écrit la clé privée. Conservez ce fichier confidentiel et ne l’envoyez jamais à personne, y compris à la CA.
• -out écrit la CSR que vous soumettez à la CA.
• -subj remplit les champs du sujet en ligne 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 vrai nom d’hôte auquel les clients se connectent (souvent le même nom que votre enregistrement MX), et modifiez les valeurs de -subj pour correspondre à 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 quand même besoin de valeurs valides. OpenSSL moderne signe la CSR avec SHA-256 par défaut, ce qui est ce qu’exige chaque CA publique.

Si vous préférez remplir les champs de manière interactive plutôt qu’avec -subj, retirez cet indicateur et OpenSSL vous demandera chaque valeur :

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

Lorsque vous y êtes invité, laissez le challenge password et le nom d’entreprise optionnel vides en appuyant sur Entrée. Les CA ignorent ces champs, et un challenge password cause des problèmes plus tard.

Couvrir plusieurs noms d’hôte

Si la même instance qmail répond sur plusieurs noms (par exemple, à la fois mail.example.com et smtp.example.com), 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"

Le Common Name doit toujours être le nom d’hôte de messagerie principal. Ajouter le domaine racine nu au SAN n’est utile que si les clients de messagerie s’y connectent directement à un moment donné ; si votre enregistrement MX pointe vers un sous-nom d’hôte, vous n’avez pas besoin du domaine racine sur le certificat.

Vous préférez une clé ECDSA ?

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

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

Notez que le qmail original avec les correctifs TLS de DJB ne prend peut-être pas en charge ECDSA. Si vous utilisez notqmail avec un OpenSSL actuel, ECDSA fonctionne sans problème.

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

Verrouillez la clé privée pour que seul root puisse la lire. Le fichier de clé brut n’est nécessaire que lorsque vous construirez le servercert.pem combiné plus tard, donc la propriété par root et le mode 600 sont corrects :

sudo chown root:root /var/qmail/control/ssl/mail.example.com.key
sudo chmod 600 /var/qmail/control/ssl/mail.example.com.key

Le fichier CSR n’est pas secret (il contient uniquement la clé publique et les détails de votre sujet), mais le conserver dans le même répertoire verrouillé maintient une organisation propre.

É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 :

openssl req -noout -text -verify -in /var/qmail/control/ssl/mail.example.com.csr

Recherchez verify OK dans la sortie, 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 valeur -addext correcte : une CA ne peut pas ajouter de noms d’hôte 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 /var/qmail/control/ssl/mail.example.com.csr

Le bloc ressemble à ceci. Copiez tout depuis la première ligne jusqu’à la dernière, y compris les cinq traits d’union 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 notre guide d’installation SSL pour qmail pour le déployer. Conservez le fichier .key sur le serveur : vous en avez besoin avec le certificat émis pour activer 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, construisez 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 placez au même chemin sur le serveur.

Où vont les fichiers dans qmail

Pour le contexte, voici comment les fichiers que vous venez de générer sont intégrés dans qmail une fois que la CA renvoie le certificat et l’intermédiaire (bundle CA). Qmail-smtpd lit son matériel TLS depuis un seul fichier PEM combiné à /var/qmail/control/servercert.pem. Ce fichier doit contenir la clé privée, le certificat serveur, et les certificats intermédiaires, concaténés dans cet ordre :

cat mail.example.com.key mail.example.com.crt intermediate.pem 
> /var/qmail/control/servercert.pem
sudo chown root:nofiles /var/qmail/control/servercert.pem
sudo chmod 640 /var/qmail/control/servercert.pem

Le groupe nofiles est le groupe par défaut pour l’utilisateur qmaild sous lequel qmail-smtpd s’exécute. Le mode 640 permet à qmaild de lire le fichier via l’appartenance au groupe tout en le rendant illisible pour les autres utilisateurs. Si votre système utilise un groupe différent pour qmaild, substituez ce nom de groupe dans la commande chown.

Qmail-smtpd propose STARTTLS uniquement lorsqu’il a été compilé avec le support TLS, ce que ni le qmail original ni notqmail ne fournit par lui-même. La voie habituelle pour les deux est le correctif qmail-tls de Frederik Vermeulen : c’est ce qui fait que qmail-smtpd lit servercert.pem et annonce STARTTLS dès que ce fichier est en place. L’autre voie est s/qmail d’Erwin Hoffmann avec ucspi-ssl, où sslserver exporte la variable d’environnement UCSPITLS dans /service/qmail-smtpd/run et la clé se trouve dans un fichier serverkey.pem séparé, donc la disposition à fichier unique ci-dessus ne s’applique pas dans ce cas. Après avoir placé le fichier PEM combiné, redémarrez le service qmail-smtpd :

sudo svc -t /service/qmail-smtpd

Le guide d’installation complet, y compris la vérification de la chaîne de certificats avec OpenSSL, se trouve dans notre guide d’installation SSL pour qmail.

Vérifier STARTTLS après installation

Une fois le certificat installé, confirmez que votre serveur annonce STARTTLS et sert une chaîne valide :

openssl s_client -connect mail.example.com:25 -starttls smtp -servername mail.example.com

Recherchez Verify return code: 0 (ok) et confirmez que le sujet et l’émetteur correspondent à votre certificat. Vous pouvez également analyser le serveur avec notre SSL Checker pour obtenir un rapport visuel de la chaîne de certificats et de la date d’expiration.

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

Vous utilisez un autre serveur de messagerie ? Consultez nos autres guides CSR :

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