Créer une CSR OpenSSL fiable sans oublier les SAN

Une CSR OpenSSL se génère en quelques secondes, mais une CSR ratée peut bloquer une émission de certificat pendant des heures. Le problème ne vient presque jamais de la commande elle-même. Il vient d'un nom oublié, d'un SAN absent, d'une clé privée stockée n'importe où ou d'une demande envoyée sans vérification.

Le principe à retenir est simple : la CSR part vers l'autorité de certification, mais la clé privée reste chez vous. Tout le reste de la procédure sert à préserver cette séparation, à déclarer les bons noms et à rendre le renouvellement reproductible six ou douze mois plus tard.

Ce qu'une CSR contient vraiment

Une CSR n'est ni le certificat final, ni un fichier à installer directement sur le serveur en production. Une CSR, ou Certificate Signing Request, est une demande de signature. Elle contient notamment la clé publique, le sujet demandé et les extensions utiles, dont les noms DNS du certificat. Elle est transmise à une autorité de certification ou à une PKI interne.

La clé privée, elle, ne doit pas voyager. Si vous envoyez la clé privée avec la CSR, vous avez déjà perdu le match avant le coup d'envoi. La CA n'a pas besoin de cette clé pour signer la demande; elle doit seulement recevoir les éléments publics nécessaires à l'émission.

Cette séparation est la base du diagnostic.

Quand un certificat ne fonctionne pas, on vérifie d'abord si la CSR contenait les bons noms, si le certificat émis correspond à la clé privée conservée, puis si le serveur présente bien la chaîne attendue. Ce raisonnement évite de tout refaire alors que le problème se trouve parfois dans une chaîne intermédiaire ou un mauvais vhost.

Il faut aussi distinguer la demande, le certificat final et la configuration serveur. La CSR ne prouve pas que votre reverse proxy, votre serveur Apache, votre load balancer ou votre appliance acceptera le fichier livré par la CA. Elle fixe seulement l'identité cryptographique demandée. Le reste se contrôle au moment de l'installation, avec la chaîne intermédiaire, le format attendu et les chemins réellement déclarés dans le service.

Gardez cette frontière en tête. La CSR prépare l'émission, mais elle ne valide pas encore le déploiement TLS.

Préparer les informations avant la commande

Commencez par la liste des noms. Faites-la valider par quelqu'un qui connaît réellement le service exposé au quotidien.

Avant d'ouvrir le terminal, listez les noms exacts à couvrir. Pour un site public, cela peut inclure example.com et www.example.com. Pour un service interne, notez les noms FQDN réellement utilisés par les applications, pas ceux que l'équipe aimerait utiliser un jour, puis confrontez cette liste aux entrées DNS réellement résolues.

Vérifiez aussi le type de certificat attendu : domaine unique, multi-domaines, wildcard, certificat interne ou certificat client. Une CSR n'est pas un formulaire magique. Elle encode une intention précise, et cette intention doit être cohérente avec l'usage réel.

• DNS publics à couvrir : domaine racine, sous-domaines, alias réellement exposés.
• DNS internes à couvrir : FQDN utilisés par les applications, pas seulement les noms historiques.
• Contraintes de certificat : wildcard, multi-domaines, certificat client ou usage purement serveur.
• Validation attendue : portail CA public, PKI interne, procédure sécurité ou prestataire.

Enfin, décidez où seront stockés la clé privée, la CSR, le fichier de configuration et les preuves de vérification. Cette étape paraît administrative, mais elle évite de chercher un fichier critique dans un dossier “Nouveau dossier final v3” six mois plus tard.

Dans une petite équipe, le bon réflexe consiste à créer un dossier de renouvellement avec le domaine, l'année et l'environnement dans le nom. Par exemple, un certificat public de production ne doit pas se mélanger avec une demande de recette ou un certificat interne. Cette organisation évite les erreurs de copie quand la CA renvoie plusieurs fichiers avec des noms peu explicites, surtout si l'installation finale se fait plusieurs jours après la génération et mobilise une autre personne côté exploitation.

Si plusieurs personnes interviennent, désignez aussi un responsable de validation. Celui qui tape la commande n'est pas toujours celui qui connaît le périmètre applicatif. Une relecture par l'équipe exploitation ou par le propriétaire du service permet de confirmer la liste des DNS, le besoin réel de wildcard et les contraintes de redémarrage avant de créer la demande.

Ce cadrage évite de corriger la CSR après coup, quand la demande est déjà partie en validation.

Choisir une clé cohérente avec l'environnement

La compatibilité prime sur l'élégance. Le certificat doit passer par les clients, les proxys et les équipements déjà en place.

OpenSSL permet plusieurs familles de clés. Pour un guide simple et largement compatible, une clé RSA de 3072 bits reste un choix conservateur. Beaucoup d'environnements modernes acceptent aussi ECDSA, mais ce choix doit être aligné avec les clients, les proxys, les équipements et les procédures internes.

Le point important n'est pas de choisir l'algorithme le plus élégant sur le papier. Il faut choisir une clé acceptée partout où le certificat sera présenté. Un vieux client, une appliance TLS ou un outil métier peut transformer un choix théorique en incident d'exploitation. Si vous sortez du couple RSA classique, testez la compatibilité avant de standardiser, puis notez cette décision dans la procédure de renouvellement et dans la fiche du service.

Notez enfin la politique de rotation. Certaines organisations renouvellent le certificat avec la même clé, d'autres imposent une nouvelle clé privée à chaque cycle. Les deux approches existent, mais elles ne se décident pas dans l'urgence. Quand une clé a pu circuler hors contrôle, la seule réponse prudente consiste à la remplacer.

Pourquoi éviter la saisie interactive

Le mode interactif dépanne. Il documente mal les choix qui comptent au prochain renouvellement du certificat par l'équipe.

OpenSSL permet de générer une CSR en mode interactif. Cela dépanne pour un test rapide, mais ce n'est pas la meilleure méthode en production. La saisie manuelle laisse trop de place aux oublis et ne documente pas correctement les extensions demandées, notamment lorsque plusieurs SAN doivent être relus par une autre personne.

Un fichier de configuration .cnf rend la demande reproductible. Il garde les informations de sujet, les extensions, les SAN et les choix de base au même endroit. Pour un administrateur qui renouvelle plusieurs certificats, c'est la différence entre une procédure et une loterie.

La méthode par fichier est aussi plus facile à relire en équipe. Un collègue peut vérifier les noms, repérer un domaine obsolète ou confirmer que le certificat couvre bien l'environnement prévu avant que la demande parte à la CA.

Elle évite surtout les variations invisibles. Un champ saisi différemment, un pays oublié ou une extension absente ne saute pas toujours aux yeux dans un terminal. Avec un fichier versionné hors dépôt public, vous pouvez comparer deux demandes, comprendre ce qui a changé et conserver la preuve de configuration sans exposer la clé privée ni dépendre d'un souvenir oral au prochain audit, y compris quand le renouvellement revient à une autre équipe.

Exemple de fichier openssl.cnf avec SAN

Le fichier openssl.cnf mérite une vraie relecture. Ne vous contentez pas d'un copier-coller depuis un ancien ticket de support ou d'infogérance.

Voici un modèle minimal à adapter. Les noms DNS sont placés dans la section alt_names. Le Common Name reste présent, mais il ne doit plus être votre seule source de vérité pour un certificat web.

[ req ]
default_bits       = 3072
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
C  = FR
O  = Exemple SAS
CN = www.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = www.example.com
DNS.2 = example.com

Adaptez l'organisation, le pays et les noms. Si vous demandez un wildcard, vérifiez que la CA l'accepte et que l'usage est justifié. Un wildcard facilite parfois l'exploitation, mais il augmente aussi l'impact d'une clé privée compromise.

Pour un certificat multi-domaines, gardez une numérotation lisible et évitez de mélanger des environnements sans raison. Mettre production, recette et administration dans la même CSR peut sembler pratique, mais cela crée un périmètre flou. Quand un seul service doit être renouvelé, vous ne voulez pas dépendre d'un certificat qui couvre des usages sans rapport.

Sur un réseau interne, soyez attentif aux noms courts. Beaucoup de PKI modernes refusent ou déconseillent les noms non qualifiés. Préférez des FQDN stables, cohérents avec le DNS interne, et vérifiez que le nom utilisé par l'application est bien celui que le client verra au moment de la connexion TLS.

Un nom interne mal choisi devient souvent une dette invisible jusqu'au changement d'application ou de proxy.

Générer la clé privée et la CSR

La génération doit produire deux fichiers bien nommés. D'un côté la clé privée locale, de l'autre une CSR transmissible à la CA.

La commande suivante s'appuie sur le fichier de configuration. Le nom des fichiers doit rester explicite, idéalement avec le domaine et l'année de renouvellement.

1. Placez-vous dans le dossier de renouvellement prévu.
2. Vérifiez que le fichier openssl.cnf contient les SAN validés.
3. Générez la clé et la CSR avec des noms de fichiers explicites.
4. Protégez immédiatement la clé privée générée.

openssl req -new -newkey rsa:3072 -nodes \
  -keyout www.example.com-2026.key \
  -out www.example.com-2026.csr \
  -config openssl.cnf

L'option -nodes crée une clé non chiffrée par mot de passe. Ce choix peut être acceptable pour certains serveurs automatisés, mais il impose une protection stricte des droits fichier et du stockage. Le confort de redémarrage ne doit pas devenir une fuite de clé privée.

Sur un poste d'administration, appliquez des permissions restrictives, déplacez la clé vers l'emplacement prévu et évitez les partages non maîtrisés. La CSR peut être envoyée à la CA; la clé privée ne doit pas être jointe au ticket, au mail ou au portail.

Après génération, ne multipliez pas les copies “au cas où”. Conservez la CSR envoyée, la clé privée correspondante et le fichier openssl.cnf dans le dossier prévu. Les brouillons et essais doivent être supprimés ou clairement isolés, car ce sont souvent eux qui reviennent par erreur lors de l'installation finale.

Si la commande échoue, lisez le message au lieu de relancer en changeant plusieurs paramètres à la fois. Une section mal nommée, une extension absente ou un chemin incorrect se corrige proprement. Relancer trois variantes produit surtout trois clés privées et trois demandes impossibles à distinguer sous pression.

Un seul essai propre vaut mieux que plusieurs fichiers presque identiques dont personne ne connaît l'état.

Vérifier la CSR avant envoi

La vérification doit être systématique. Elle prend moins d'une minute et évite un certificat inutilisable. Commencez par relire la demande en clair avec OpenSSL.

openssl req -in www.example.com-2026.csr -noout -text

Contrôlez le sujet, les extensions et surtout subjectAltName. Si les SAN ne sont pas visibles, ne partez pas du principe que la CA va deviner. Elle signera ce que vous demandez, pas ce que vous aviez en tête.

Vérifiez ensuite que la CSR correspond bien à la clé privée. Une méthode simple consiste à comparer le module ou la clé publique selon le type de clé. L'objectif est de prouver que la demande et la clé appartiennent au même couple cryptographique.

openssl req -noout -modulus -in www.example.com-2026.csr | openssl md5
openssl rsa -noout -modulus -in www.example.com-2026.key | openssl md5

Si les empreintes diffèrent, arrêtez-vous. Envoyer cette CSR reviendrait à demander un certificat que votre serveur ne pourra pas utiliser avec la clé privée prévue.

Cette vérification doit être faite avant le portail de la CA, pas après réception du certificat. Une fois le certificat émis, l'erreur devient administrative autant que technique : il faut révoquer, réémettre, prévenir l'équipe concernée et parfois attendre une validation supplémentaire. Le contrôle préalable est donc un vrai gain d'exploitation, pas une coquetterie de procédure, surtout lorsqu'un prestataire ou une équipe sécurité valide chaque demande dans un circuit formalisé avec ticket.

Pensez aussi à relire la casse, les tirets et les domaines proches. Un nom comme api-prod n'a pas le même sens que api-preprod. Sur les certificats internes, les erreurs ressemblent souvent à des détails; côté application, elles deviennent des alertes TLS ou des connexions refusées.

Relisez les noms visibles par les clients. Ne vous limitez pas au nom technique du serveur.

Protéger la clé privée

La clé privée est le fichier le plus sensible de toute la procédure. La CSR peut circuler; la clé privée, non.

La sécurité du certificat dépend directement de la clé privée. Une CSR peut être stockée dans un dossier de projet; une clé privée doit être traitée comme un secret. Copiez-la uniquement là où elle est nécessaire et documentez son emplacement.

Évitez les pièces jointes, les messageries instantanées, les dépôts Git et les dossiers partagés généralistes. Cela paraît évident jusqu'au jour où un renouvellement urgent finit dans un canal “certificats” accessible à quinze personnes. On appelle ça une organisation agile; l'auditeur appelle ça autre chose.

Si votre organisation utilise un coffre, un HSM ou une procédure de secrets, suivez-la. Sinon, fixez au minimum les droits fichier, le compte propriétaire, la sauvegarde chiffrée et la liste des personnes autorisées à manipuler la clé.

Sur Linux, contrôlez les droits dès la génération. Une clé lisible par tout le monde sur un serveur partagé n'est pas acceptable. Le bon réglage dépend de votre service, mais l'idée reste la même : le compte qui sert TLS doit pouvoir lire la clé, pas l'ensemble des utilisateurs de la machine.

Si vous devez transférer la clé vers un serveur, utilisez un canal maîtrisé et supprimez les copies temporaires. Documentez aussi qui a effectué le transfert et à quelle date. Cette trace sera utile en cas d'incident, de rotation forcée ou de départ d'un administrateur qui connaissait seul l'historique du certificat.

Erreurs fréquentes à éviter

Les erreurs les plus coûteuses sont rarement spectaculaires. Elles tiennent souvent à un nom ou à une copie.

La première erreur est de se contenter du Common Name. Les navigateurs modernes et beaucoup d'outils TLS se fient aux SAN. Sans SAN correct, le certificat peut être techniquement émis mais pratiquement inutilisable.

La deuxième erreur est de générer une nouvelle clé à chaque essai sans savoir laquelle correspond à quelle CSR. Au bout de trois tentatives, plus personne ne sait quel fichier utiliser. Nommez les fichiers proprement et supprimez ou archivez les essais ratés.

La troisième erreur est d'envoyer la demande sans relire. Une CSR avec un domaine de recette, un ancien nom ou une faute de frappe passera parfois assez loin dans le processus pour faire perdre du temps à tout le monde.

Ajoutez à cette liste les erreurs de copier-coller dans les portails de CA. Certains outils acceptent une CSR collée sans les lignes de début et de fin, d'autres non. Copiez toujours le bloc complet, depuis BEGIN CERTIFICATE REQUEST jusqu'à END CERTIFICATE REQUEST, sans ajouter d'espace parasite.

Autre piège : confondre CSR et certificat. Une CSR n'est pas installable directement sur le serveur comme certificat final. Elle sert à obtenir le certificat signé. Si un outil demande un certificat et que vous lui donnez la CSR, l'installation échouera ou produira un message peu clair.

Après émission, contrôler le certificat reçu

La qualité de la CSR ne dispense pas de vérifier le certificat livré. Contrôlez que les SAN du certificat correspondent à la demande, que les dates de validité sont cohérentes et que la chaîne intermédiaire fournie par la CA est bien celle attendue. Une erreur peut encore se glisser entre la demande, la validation et l'émission, surtout quand le portail propose plusieurs formats de téléchargement ou plusieurs chaînes intermédiaires possibles dans la même interface.

Avant de remplacer un certificat en production, testez le couple certificat plus clé privée sur un environnement maîtrisé quand c'est possible. Ce test confirme la correspondance cryptographique, le format de fichier et la compatibilité avec le service. Il vaut mieux découvrir une chaîne manquante sur une machine de recette que pendant une fenêtre de maintenance raccourcie, avec des utilisateurs déjà connectés et un rollback mal préparé côté exploitation ou hébergement.

Une fois le certificat installé, vérifiez depuis l'extérieur ou depuis un client représentatif. Le serveur peut démarrer correctement tout en présentant l'ancien certificat, une chaîne incomplète ou le mauvais vhost. Le test final ne consiste donc pas seulement à voir un service “up”; il faut regarder le certificat réellement servi.

Renouvellement : garder une trace exploitable

Un certificat se renouvelle rarement dans le calme absolu. Gardez donc la commande, le fichier openssl.cnf, la date, la CA utilisée, le périmètre DNS et l'emplacement de la clé privée. Le prochain renouvellement doit repartir d'une base claire, avec des décisions compréhensibles pour une personne qui n'a pas participé à la demande initiale ni au choix de la CA, mais qui doit intervenir vite.

Ajoutez aussi une note sur les choix faits : longueur de clé, wildcard ou non, noms internes exclus, environnement concerné. Ces informations évitent de reproduire un ancien compromis par habitude.

Si le certificat sert un service critique, testez le nouveau certificat avant la fenêtre de bascule. Une CSR parfaite n'empêche pas une erreur de chaîne intermédiaire, de format de fichier ou de configuration serveur.

La bonne documentation n'a pas besoin d'être longue. Elle doit répondre à quelques questions simples : quel service est couvert, quels noms sont dans les SAN, où se trouve la clé privée active, quelle CA signe le certificat, qui valide le périmètre et quelle procédure permet de revenir en arrière si l'installation se passe mal.

Planifiez aussi une alerte d'expiration indépendante du souvenir de l'équipe. Les certificats courts sont devenus la norme, et un calendrier oublié suffit à provoquer une panne visible. Une CSR bien générée ne sert à rien si personne ne relance le renouvellement avant l'échéance.

Créer une CSR OpenSSL fiable ne consiste pas seulement à lancer une commande. Il faut préparer les noms, produire un fichier de configuration reproductible, protéger la clé privée, vérifier la demande et garder une trace utile pour le renouvellement. Cette discipline paraît lourde la première fois, mais elle fait gagner du temps dès que plusieurs certificats, environnements ou intervenants entrent dans la boucle de validation et d'exploitation.

La bonne procédure tient en une règle : envoyez la CSR, jamais la clé privée, et ne transmettez rien avant d'avoir relu les SAN. C'est moins spectaculaire qu'un dépannage en urgence, mais c'est précisément ce qui évite l'urgence.