Pour demander un certificat TLS, OpenSSL permet de créer une clé privée et un CSR dans la même opération, ou de produire une demande à partir d’une clé existante. Dans les deux cas, la liste des noms doit figurer dans l’extension Subject Alternative Name (SAN) : le Common Name seul ne suffit plus pour les navigateurs modernes. Un oubli à cette étape peut conduire à un certificat inutilisable, même si le nom de domaine paraît correct dans la demande.
La procédure dépend surtout de deux choix : conserver une clé déjà utilisée par un service, ou en générer une nouvelle ; demander un certificat pour des noms précis, ou inclure un certificat wildcard couvrant les sous-domaines de premier niveau. Voici les commandes OpenSSL adaptées, les points à vérifier avant l’envoi à une autorité de certification et les précautions à prendre pour ne pas exposer la clé privée.
En bref
- Un CSR contient une clé publique, des informations d’identité et les extensions demandées ; il ne contient pas la clé privée.
- Avec une clé existante, utilisez openssl req -new -key et ajoutez le SAN.
- Un wildcard comme *.exemple.fr couvre les sous-domaines de premier niveau, pas le domaine nu ni les sous-domaines imbriqués.
- Inspectez la demande avant de la transmettre et vérifiez que l’autorité émettra bien les SAN demandés.
CSR OpenSSL : comprendre la clé privée, la demande et le SAN
Une CSR, ou demande de signature de certificat, est un fichier transmis à une autorité de certification (AC). Elle contient la clé publique associée à une clé privée, un sujet éventuellement renseigné avec le Common Name et les extensions demandées, notamment la liste des noms couverts. La demande est signée avec la clé privée : cette signature prouve que son auteur détient la clé correspondante, mais elle ne remplace pas la validation de domaine effectuée par l’AC.
La clé privée doit rester sur la machine qui en a besoin, ou dans un coffre prévu à cet effet. L’AC reçoit le CSR, jamais la clé privée. Les générateurs de CSR en ligne qui produisent ou récupèrent la clé privée déplacent ce secret hors de votre environnement ; pour un service professionnel, mieux vaut effectuer la génération localement avec OpenSSL.
Le SAN, pour Subject Alternative Name, permet d’associer plusieurs identités à un même certificat : noms DNS, adresses IP ou adresses de courrier électronique selon le type d’entrée. Par exemple, un certificat peut couvrir exemple.fr, www.exemple.fr et boutique.exemple.fr. Les clients TLS modernes vérifient les noms dans cette extension. Le Common Name peut rester utile à des fins de lisibilité ou de compatibilité, mais il ne faut pas compter sur lui pour remplacer un SAN absent.
Avant de lancer la commande, vérifiez la version utilisée avec openssl version. L’option -addext est disponible à partir d’OpenSSL 1.1.1. Sur certains macOS, la commande openssl peut pointer vers LibreSSL plutôt que vers OpenSSL ; les options ne sont pas toujours identiques. Dans ce cas, vérifiez le binaire et sa documentation avant de reprendre les exemples tels quels.
Générer une clé privée et un CSR avec OpenSSL
Pour une nouvelle installation, créer la clé et le CSR ensemble réduit le risque de les mélanger avec des fichiers provenant d’un autre service. Voici une commande RSA de 2048 bits, largement compatible avec les environnements courants :
openssl req -new -newkey rsa:2048 -noenc -keyout exemple.key -out exemple.csr -subj « /C=FR/O=Exemple/CN=exemple.fr » -addext « subjectAltName=DNS:exemple.fr,DNS:www.exemple.fr »
Sur certaines versions plus anciennes, utilisez -nodes à la place de -noenc pour créer une clé non chiffrée. Ce choix facilite le démarrage automatique de Nginx ou d’Apache, car le service n’a pas à demander une phrase de passe. En contrepartie, toute personne ayant accès au fichier peut utiliser la clé : restreignez ses permissions et évitez de la placer dans un dépôt Git, une archive partagée ou un répertoire accessible au serveur web.
Si l’environnement prend en charge ECDSA, une clé sur la courbe P-256 constitue une alternative courante :
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -noenc -keyout exemple-ec.key -out exemple-ec.csr -subj « /C=FR/O=Exemple/CN=exemple.fr » -addext « subjectAltName=DNS:exemple.fr,DNS:www.exemple.fr »
Choisissez RSA ou ECDSA selon les exigences de l’AC et la compatibilité des clients concernés. Dans un parc ancien ou hétérogène, RSA reste souvent le choix le plus prévisible. Pour un service maîtrisé de bout en bout, ECDSA peut convenir, à condition que la chaîne technique le prenne en charge.
La commande produit deux fichiers : exemple.key, qui est secret, et exemple.csr, qui peut être transmis à l’AC. Elle ne crée pas de certificat. Une AC publique doit encore vérifier le contrôle du domaine et émettre le certificat. Pour un laboratoire, l’option -x509 peut créer directement un certificat auto-signé, mais celui-ci n’est pas automatiquement reconnu par les navigateurs ou les postes clients.
Créer un CSR avec une clé existante, un SAN ou un wildcard
Si le service dispose déjà d’une clé privée, réutilisez-la plutôt que d’en générer une autre par réflexe. Cela évite de devoir remplacer la clé déployée, mais il faut d’abord confirmer qu’elle est bien disponible et qu’elle correspond à l’usage prévu. La commande de base est :
openssl req -new -key exemple.key -out exemple.csr -subj « /C=FR/O=Exemple/CN=exemple.fr » -addext « subjectAltName=DNS:exemple.fr,DNS:www.exemple.fr »
Cette méthode ne modifie pas la clé existante. Si celle-ci est chiffrée, OpenSSL demandera sa phrase de passe. Ne la retirez pas simplement pour éviter cette demande : sur un serveur de production, la gestion de la phrase de passe doit être décidée en fonction du mécanisme de démarrage et de protection des secrets.
Pour un certificat wildcard, ajoutez une entrée DNS de la forme DNS:*.exemple.fr. Elle couvre par exemple www.exemple.fr ou api.exemple.fr, mais pas exemple.fr lui-même. Elle ne couvre pas non plus v2.api.exemple.fr, car le joker ne s’étend qu’à un seul niveau. Si le domaine nu doit aussi être couvert, ajoutez-le explicitement :
-addext « subjectAltName=DNS:exemple.fr,DNS:*.exemple.fr »
Un wildcard réduit le nombre de certificats à gérer, mais élargit l’impact d’une compromission : une même clé peut servir plusieurs sous-domaines. Dans une PME, je préfère souvent des certificats distincts pour les services exposés séparément, sauf si l’exploitation d’un wildcard est réellement nécessaire. Vérifiez aussi les règles de l’AC : les noms présents dans le CSR ne garantissent pas qu’ils seront tous acceptés ou copiés dans le certificat final.
Si la liste de SAN est longue, ou si plusieurs demandes doivent suivre le même modèle, un fichier de configuration OpenSSL est plus lisible. Il faut relier explicitement la section d’extensions à la requête ; sinon, la commande peut produire un CSR sans SAN sans signaler clairement l’oubli.
openssl req -new -key exemple.key -out exemple.csr -config csr.cnf
Dans csr.cnf, la section [ req ] doit contenir req_extensions = req_ext, puis [ req_ext ] doit référencer les noms définis dans [ alt_names ]. Par exemple : subjectAltName = @alt_names, suivi de DNS.1 = exemple.fr, DNS.2 = *.exemple.fr et, si nécessaire, IP.1 = 192.0.2.10. Pour une adresse IP, utilisez bien le type IP et non DNS.
| Besoin | Commande ou entrée SAN | Point de vigilance |
|---|---|---|
| Nouvelle clé RSA | -newkey rsa:2048 | Protéger le fichier de clé généré |
| Clé privée existante | -key exemple.key | Confirmer qu’elle correspond au service concerné |
| Domaine et sous-domaine | DNS:exemple.fr,DNS:www.exemple.fr | Chaque nom nécessaire doit être listé |
| Wildcard | DNS:*.exemple.fr | Ne couvre ni le domaine nu ni plusieurs niveaux |
Inspecter le CSR avant de le transmettre à l’autorité de certification
Ne transmettez pas une demande sans avoir contrôlé son contenu. Affichez le sujet, les extensions demandées et le résultat de la vérification de signature avec :
openssl req -in exemple.csr -noout -text -verify
La sortie doit afficher le sujet attendu et une extension X509v3 Subject Alternative Name contenant tous les DNS et toutes les IP nécessaires. La vérification indique que la signature du CSR est cohérente avec la clé publique qu’il contient. Elle ne confirme ni que l’AC acceptera les noms ni que le futur certificat sera correctement déployé.
Si le bloc SAN est absent, arrêtez la demande. Recréez le CSR avec -addext ou corrigez le fichier de configuration en vérifiant la présence de req_extensions = req_ext. Cette vérification évite une erreur fréquente : transmettre un CSR valide sur le plan cryptographique, mais incomplet pour les navigateurs.
Une fois le certificat reçu, examinez également son contenu avec openssl x509 -in certificat.pem -noout -text. L’AC peut appliquer ses propres règles et ne pas émettre exactement toutes les extensions demandées. Pour comparer la clé publique du certificat avec celle de la clé privée, utilisez :
openssl x509 -in certificat.pem -noout -pubkey | openssl sha256
openssl pkey -in exemple.key -pubout | openssl sha256
Les empreintes doivent être identiques. Cette méthode fonctionne avec RSA comme avec ECDSA, contrairement à la comparaison de modules, qui est propre à RSA. Si les résultats diffèrent, le certificat et la clé privée ne forment pas une paire : ne déployez pas ce jeu de fichiers.
Envoyez uniquement le CSR à l’AC. Pour un certificat public, celle-ci valide le contrôle des noms selon sa procédure, puis fournit un certificat et souvent des certificats intermédiaires. La chaîne complète compte autant que le fichier feuille lors de l’installation sur un serveur.
Erreurs de génération de CSR et précautions de sécurité
Un navigateur qui signale une erreur de nom malgré un Common Name correct indique souvent que le SAN manque ou que le nom demandé par le client n’y figure pas. Inspectez le certificat effectivement installé, pas seulement le CSR d’origine : un ancien certificat peut encore être servi, ou le serveur peut avoir chargé un autre fichier. La commande openssl s_client -connect exemple.fr:443 -servername exemple.fr aide à examiner le certificat présenté par le serveur.
Une erreur de correspondance entre clé et certificat survient souvent après une régénération de clé : le nouveau fichier a écrasé l’ancien, alors que le certificat correspond toujours à la clé précédente. Pour éviter ce scénario, nommez les fichiers par service et par version, puis sauvegardez les secrets selon une procédure contrôlée. Une clé privée n’est pas un fichier de configuration ordinaire.
Un CSR contient les informations demandées à l’AC, mais le certificat final est émis selon les règles de cette autorité. Avant de lancer une demande, vérifiez que vous contrôlez chaque nom, que l’AC accepte le type de certificat choisi et que les enregistrements CAA du domaine ne bloquent pas l’émission. Pour les services publics, un certificat d’une AC reconnue est le bon choix ; l’auto-signature est réservée aux tests ou aux environnements internes où la confiance peut être distribuée par un canal maîtrisé.
Pour un certificat wildcard, limitez particulièrement les accès à la clé : elle peut concerner plusieurs applications et sous-domaines. Si les équipes ou les niveaux de sensibilité diffèrent, séparez les certificats et les clés. Le gain de gestion d’un wildcard ne compense pas toujours son rayon d’impact en cas de fuite.
La référence pour les options de requête reste la page de manuel officielle openssl-req. Avant une mise en production, contrôlez la version OpenSSL, relisez le SAN du CSR, puis vérifiez les noms et la paire clé-certificat après émission. C’est une courte vérification qui évite bien des interventions au moment du renouvellement.
Peut-on générer un CSR avec une clé privée déjà existante ?
Oui. Utilisez openssl req -new -key exemple.key -out exemple.csr, puis ajoutez les informations de sujet et le SAN avec -subj et -addext, ou avec un fichier de configuration OpenSSL. La clé privée reste sur votre système.
Un certificat wildcard couvre-t-il aussi le domaine principal ?
Non. DNS:*.exemple.fr couvre les sous-domaines de premier niveau, mais pas exemple.fr. Ajoutez DNS:exemple.fr séparément si le domaine principal doit être couvert.
Quelle différence entre un CSR et un certificat auto-signé ?
Un CSR est une demande destinée à une autorité de certification et ne constitue pas un certificat utilisable par un serveur. Un certificat auto-signé peut servir en laboratoire ou en interne, mais les clients ne lui font pas confiance sans configuration spécifique.
Comment vérifier que le SAN est présent dans la demande ?
Lancez openssl req -in exemple.csr -noout -text -verify et repérez l’extension X509v3 Subject Alternative Name. Vérifiez aussi le certificat émis, car l’autorité applique ses propres règles.
