Créer une CSR OpenSSL sans exposer votre clé privée

Une CSR OpenSSL ne sert pas à “créer un certificat” directement. Elle sert à préparer une demande de signature de certificat contenant votre clé publique et les informations que l’autorité de certification devra valider. La clé privée, elle, reste sur votre serveur ou dans votre coffre de déploiement.

La différence est décisive : le fichier .csr peut être transmis à l’autorité, mais le fichier .key ne doit jamais sortir du périmètre d’administration. Une grande partie des erreurs TLS commence là, avec une commande copiée trop vite, un mauvais domaine dans le SAN ou une clé privée déposée dans un ticket support.

Ce qu’une CSR contient vraiment

La CSR est publique. La clé reste privée. Cette séparation doit guider toute la procédure.

Une Certificate Signing Request est un objet PKCS#10. Elle contient la clé publique, des informations d’identité et, selon la configuration, des extensions demandées comme subjectAltName. OpenSSL la signe avec la clé privée associée afin de prouver que vous possédez bien la paire cryptographique, sans révéler cette clé privée.

Cette précision corrige une confusion fréquente. La CSR n’est pas “chiffrée avec la clé privée”. Elle est signée. L’autorité de certification peut vérifier la cohérence de la demande, puis émettre un certificat qui liera l’identité validée à la clé publique. Le serveur utilisera ensuite le certificat signé et la clé privée correspondante pour établir TLS, ce qui explique pourquoi une clé perdue ou remplacée au mauvais moment rend le certificat inutilisable malgré une émission réussie.

En pratique, le navigateur ne se contente plus d’un Common Name bien rempli. Les noms réellement valides doivent apparaître dans les SAN DNS. Le CN reste utile pour la lisibilité, mais un certificat moderne doit surtout porter les noms attendus dans l’extension subjectAltName.

Préparer les fichiers avant de lancer OpenSSL

Travaillez dans un dossier réservé au certificat, pas au milieu d’un répertoire de téléchargement. Choisissez un nom clair, par exemple example.com.key et example.com.csr, puis définissez qui aura le droit de lire la clé privée. Cette étape paraît administrative, mais elle évite les clés perdues, écrasées ou commitées par erreur.

Sur un serveur Linux, vérifiez d’abord la version disponible. C’est aussi le bon moment pour confirmer l’environnement cible :

openssl version

Ensuite, créez un dossier de travail et appliquez des permissions restrictives. L’objectif est simple : la clé privée doit rester lisible uniquement par l’administrateur ou le compte de service prévu.

mkdir -p ~/tls/example.com
cd ~/tls/example.com
umask 077

Le umask 077 limite les permissions des fichiers créés ensuite. Il ne remplace pas une politique de secret, mais il réduit le risque d’un fichier clé lisible par d’autres utilisateurs locaux.

Après génération, vérifiez explicitement les droits du fichier clé. Une commande comme ls -l example.com.key doit montrer un accès restreint. Si nécessaire, corrigez avec chmod 600 example.com.key et un propriétaire cohérent. Dans une organisation, cette clé devrait aussi être référencée dans un inventaire de secrets ou de certificats, avec un responsable, une date de génération, un périmètre d’usage et une procédure de révocation si l’environnement change.

Ne stockez pas la clé privée dans le même espace que les livrables publics du site. Le répertoire web, un dépôt Git applicatif ou un dossier partagé d’équipe sont de mauvais emplacements. Une clé TLS appartient au périmètre d’exploitation, pas au contenu servi aux visiteurs.

Créer une clé privée et une CSR RSA en une commande

Pour un cas classique, une commande combinée suffit. Elle génère une clé privée RSA et la CSR associée, en restant facile à relire :

openssl req -new -newkey rsa:2048 -sha256 -nodes \
  -keyout example.com.key \
  -out example.com.csr

Le paramètre -newkey rsa:2048 crée une nouvelle clé RSA de 2048 bits. Le paramètre -sha256 demande une signature SHA-256 de la CSR. Le paramètre -nodes produit une clé privée non chiffrée par passphrase, ce qui facilite les redémarrages automatiques d’un service web, mais exige une protection stricte du fichier.

Si votre politique interne impose une clé chiffrée au repos, retirez -nodes. OpenSSL demandera une passphrase. Ce choix peut être pertinent pour une clé conservée hors ligne ou utilisée manuellement, mais il complique l’automatisation d’un serveur qui doit redémarrer sans intervention humaine.

Ajouter les SAN dès la génération

Le SAN décide des noms réellement couverts. Relisez-le deux fois, surtout si le certificat sert plusieurs points d’entrée.

Pour un certificat web, le SAN est rarement optionnel. Si vous devez couvrir example.com et www.example.com, ajoutez-les explicitement. Avec OpenSSL récent, l’option -addext permet de le faire sans fichier de configuration :

openssl req -new -newkey rsa:2048 -sha256 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=FR/L=Paris/O=Example/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Cette forme est pratique pour un certificat simple. Elle réduit les invites interactives et rend la commande reproductible. En revanche, elle doit être relue attentivement : un nom oublié dans le SAN ne pourra pas être “ajouté” après coup au certificat déjà émis. Il faudra générer une nouvelle demande ou refaire l’émission selon le processus de l’autorité, puis redéployer le certificat sur tous les points d’entrée concernés, y compris les reverse proxies et les équilibreurs.

Pour plusieurs environnements, préférez un fichier de configuration versionné dans un dépôt privé d’infrastructure. Il devient plus lisible, plus contrôlable en revue et moins fragile qu’une longue commande copiée depuis un historique shell.

Utiliser un fichier de configuration OpenSSL

Un fichier de configuration est plus sûr lorsque vous répétez souvent l’opération. Il permet de fixer le Subject, les extensions et les SAN de manière explicite. Voici une base courte à adapter :

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

[ dn ]
C = FR
L = Paris
O = Example
CN = example.com

[ req_ext ]
subjectAltName = @alt_names

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

La génération devient alors plus lisible. Elle se relit mieux en revue d’exploitation :

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -config csr.conf

Dans une équipe DevOps, ce fichier doit être traité comme un artefact d’infrastructure, pas comme une note jetable. Le domaine principal, les SAN, l’organisation et le niveau de clé doivent pouvoir être relus avant émission. C’est particulièrement utile quand plusieurs certificats couvrent des API, des back-offices et des environnements de recette.

Valider la CSR avant de l’envoyer

Cette étape prend une minute. Elle évite parfois une réémission complète, donc plusieurs allers-retours inutiles avec l’autorité.

Ne transmettez pas une CSR sans l’avoir décodée. La commande suivante affiche le contenu lisible, sans modifier le fichier ni exposer la clé :

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

Vérifiez d’abord le Subject, puis cherchez les extensions demandées. Les SAN doivent contenir tous les noms DNS attendus, sans faute de frappe ni environnement oublié. Contrôlez aussi la taille et le type de clé publique. Une clé RSA 2048 reste courante ; des politiques internes peuvent demander RSA 3072, RSA 4096 ou une clé elliptique selon le contexte.

Vous pouvez aussi vérifier la correspondance entre la clé privée et la CSR en comparant leurs modules pour RSA. Cette vérification est utile si plusieurs fichiers ont été manipulés dans le même répertoire :

openssl req -noout -modulus -in example.com.csr | openssl sha256
openssl rsa -noout -modulus -in example.com.key | openssl sha256

Les empreintes doivent correspondre. Si ce n’est pas le cas, la CSR ne correspond pas à cette clé privée. Il faut alors retrouver la bonne clé ou repartir proprement avec une nouvelle paire.

Avant de valider la demande, relisez ces points dans cet ordre. La liste sert de garde-fou opérationnel :

1. le fichier généré est bien example.com.csr ;
2. la clé privée example.com.key reste locale et protégée ;
3. les SAN contiennent tous les noms DNS publics attendus ;
4. la commande de génération est conservée avec le dossier de certificat ;
5. la procédure de renouvellement indique qui peut remplacer la clé.

Quand choisir une clé ECC plutôt que RSA

RSA reste très répandu, mais les clés ECC sont fréquentes dans les infrastructures modernes. Elles offrent de bonnes performances avec des clés plus courtes. Pour générer une clé elliptique P-256, vous pouvez utiliser :

openssl ecparam -name prime256v1 -genkey -noout -out example.com.key
openssl req -new -sha256 -key example.com.key -out example.com.csr \
  -subj "/C=FR/L=Paris/O=Example/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Le choix ne doit pas être esthétique. Il dépend de la compatibilité des serveurs, des clients, de l’autorité de certification et des règles internes. Dans une infrastructure hétérogène, RSA 2048 ou 3072 peut rester plus simple. Dans un environnement maîtrisé et récent, ECC peut réduire la charge cryptographique. Le meilleur choix est celui que votre supervision, vos procédures de renouvellement et vos clients savent réellement supporter.

Quelle que soit l’option retenue, documentez le choix. Une CSR n’est qu’une étape ; elle s’inscrit dans un cycle plus large : génération, validation, émission, installation, test TLS, renouvellement et révocation éventuelle.

Deux contrôles à ne pas repousser

La sécurité de la CSR se joue avant l’envoi et juste après l’installation.

Séparer clé et demande

La clé privée reste dans le coffre d’exploitation ; seule la CSR part vers l’autorité.

Tester la chaîne installée

Après émission, s_client confirme le certificat réellement présenté, le SNI et la chaîne intermédiaire.

Les erreurs qui coûtent du temps en production

En TLS, l’erreur grave est souvent un fichier envoyé trop vite. Le bon réflexe est de ralentir avant l’envoi.

La première erreur consiste à envoyer la clé privée au lieu de la CSR. Si cela arrive, considérez la clé comme compromise. Ne cherchez pas à “rattraper” la situation : générez une nouvelle clé, créez une nouvelle CSR et révoquez tout certificat associé si nécessaire.

La deuxième erreur consiste à oublier un SAN. Le certificat peut être émis correctement, mais ne pas couvrir www, une API ou un nom interne exposé. Le résultat n’est pas une panne OpenSSL ; c’est une demande incomplète. La correction passe par une nouvelle émission.

La troisième erreur est plus discrète : réutiliser trop longtemps la même clé privée par confort. Pour un renouvellement de routine, certaines équipes réutilisent la clé. Pour une refonte d’infrastructure, une suspicion d’exposition, un changement de prestataire ou un nouveau périmètre, générer une nouvelle paire est plus propre.

Après émission, tester le certificat installé

Une fois le certificat reçu, installez-le avec la clé privée correspondante et la chaîne intermédiaire fournie par l’autorité. Une chaîne incomplète peut provoquer des erreurs chez certains clients même si le certificat serveur semble correct. Ce point compte beaucoup sur des serveurs Nginx, Apache, reverse proxies ou appliances qui demandent parfois un fichier bundle précis. Avant de redémarrer un service critique, gardez un plan de retour arrière : ancien certificat, ancienne configuration et commande de reload validée.

Localement, openssl s_client permet de voir ce que le serveur présente réellement. Ce test complète la vérification navigateur :

openssl s_client -connect example.com:443 -servername example.com

Contrôlez le Subject, l’Issuer, les dates de validité et la chaîne. Le paramètre -servername est important sur les serveurs qui utilisent SNI, car plusieurs certificats peuvent cohabiter sur la même adresse IP. Sans ce nom, vous risquez d’inspecter le mauvais certificat.

Enfin, planifiez le renouvellement. Les certificats à durée courte, comme ceux de Let’s Encrypt, poussent naturellement à l’automatisation. C’est souvent une bonne chose : un renouvellement automatique, surveillé et testé vaut mieux qu’un rappel calendrier oublié dans une boîte mail.

La méthode à retenir

Créer une CSR OpenSSL fiable revient à suivre une chaîne courte : préparer le périmètre, générer la clé, déclarer les SAN, relire la demande, protéger la clé privée, puis seulement transmettre la CSR. Le vrai risque n’est pas la commande OpenSSL elle-même, mais l’absence de vérification autour d’elle.

Pour une machine isolée, une commande bien relue peut suffire. Pour une infrastructure d’équipe, un fichier de configuration, une revue et un registre de certificats deviennent vite indispensables. C’est cette discipline qui transforme une demande TLS ponctuelle en procédure exploitable.