Comment générer un CSR sous Node.js

Ce tutoriel vous montre comment générer un CSR pour une application Node.js. Node.js ne dispose d’aucun outil intégré de génération de CSR, vous devez donc créer la clé privée et la demande de signature de certificat (CSR) avec OpenSSL sur la machine qui exécutera Node, soumettre le CSR à votre autorité de certification, puis charger le certificat émis dans votre application avec fs.readFileSync() et https.createServer().

Les étapes ci-dessous fonctionnent sur tout système d’exploitation intégrant OpenSSL, ce qui couvre toutes les distributions Linux actuelles, macOS et Windows (via les binaires officiels OpenSSL ou Git Bash). OpenSSL moderne signe les requêtes avec SHA-256 par défaut, vous n’avez donc pas besoin d’ajouter un indicateur de condensé.

Étape 1 : assurez-vous qu’OpenSSL est installé

Vérifiez qu’OpenSSL est disponible sur la machine qui exécutera votre application Node.js :

openssl version

Vous devriez voir une ligne comme OpenSSL 3.0.x ou plus récent. Si la commande est introuvable, installez-la pour votre plateforme :

• Debian, Ubuntu : sudo apt update && sudo apt install openssl
• RHEL, AlmaLinux, Rocky Linux, Amazon Linux : sudo dnf install openssl (ou sudo yum install openssl sur les versions plus anciennes)
• macOS : OpenSSL (LibreSSL sur certaines versions, OpenSSL 3 si installé via Homebrew) est déjà présent dans le Terminal. Pour installer la version d’origine : brew install openssl@3.
• Windows : installez les binaires officiels OpenSSL, ou utilisez Git Bash, qui est livré avec OpenSSL préinstallé.

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

Générez la clé et le CSR sur la machine qui exécutera Node.js. La clé privée est créée à côté du CSR et doit rester sur cette machine. Exécuter ces commandes ailleurs puis copier la clé quelque part va à l’encontre de l’intérêt même d’avoir une clé privée.

Exécutez la commande suivante. Elle crée une clé privée RSA de 2048 bits et un CSR correspondant en une seule étape, avec le sujet et les noms alternatifs du sujet (SAN) fournis directement afin qu’OpenSSL ne s’arrête pas pour poser des questions :

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Ce que fait chaque partie :

• -newkey rsa:2048 génère une nouvelle clé RSA de 2048 bits. 2048 bits est le minimum actuellement accepté par les CA publiques ; vous pouvez utiliser rsa:4096 pour une clé plus grande, ou passer à ECDSA (voir ci-dessous).
• -nodes laisse la clé privée non chiffrée afin que Node.js puisse la lire au démarrage sans demander de phrase secrète. Le module https de Node prend en charge une option passphrase pour une clé chiffrée, mais la phrase secrète doit tout de même provenir de quelque part sur la machine (un fichier de configuration, une variable d’environnement ou un gestionnaire de secrets).
• -keyout et -out nomment les fichiers de la clé privée et du CSR.
• -subj fournit le sujet du certificat. Indiquez ici le nom réel de votre entreprise, votre état et votre ville, et non les valeurs d’exemple. CN (Common Name) est votre domaine principal.
• -addext « subjectAltName=… » répertorie tous les noms d’hôte que le certificat doit couvrir. Les CA publiques valident selon la liste SAN, incluez donc également le Common Name ici. L’indicateur -addext nécessite OpenSSL 1.1.1 ou plus récent, ce qui est le cas de tous les systèmes d’exploitation actuels.

Remplacez yourdomain.com par votre domaine réel partout où il apparaît. Pour couvrir des noms d’hôte supplémentaires, ajoutez-les à la liste SAN séparés par des virgules, par exemple DNS:api.yourdomain.com. Pour un certificat générique (wildcard), incluez à la fois le caractère générique et le domaine simple : DNS:*.yourdomain.com,DNS:yourdomain.com.

Si vous préférez une clé ECDSA (plus petite et plus rapide, avec P-256 largement pris en charge), générez la clé et le CSR ainsi :

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Mode interactif (sans -subj)

Si vous préférez qu’OpenSSL vous invite à saisir chaque champ, omettez l’indicateur -subj :

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key -out yourdomain.csr 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

OpenSSL vous demandera les informations suivantes :

• Country Name (C) : le code pays ISO à deux lettres de votre organisation (par exemple, US).
• State or Province Name (S) : le nom complet de l’état ou de la province où votre entreprise est enregistrée (par exemple, California). N’abrégez pas.
• Locality Name (L) : la ville où votre entreprise est enregistrée (par exemple, San Jose).
• Organization Name (O) : le nom légal de votre entreprise (par exemple, GPI Holding LLC). Pour un certificat DV (validation de domaine), laissez le champ vide et appuyez sur Entrée.
• Organizational Unit Name (OU) : obsolète depuis septembre 2022 et ignoré par les CA publiques. Laissez ce champ vide.
• Common Name (CN) : le nom de domaine complet (FQDN) que vous sécurisez, par exemple yourdomain.com. Pour un certificat générique, utilisez *.yourdomain.com.
• Email Address : facultatif. Laissez le champ vide.
• A challenge password : obsolète. Laissez le champ vide.

Étape 3 : localisez et protégez vos fichiers

Listez le répertoire courant pour confirmer que les deux fichiers ont bien été créés :

ls

Vous devriez voir deux nouveaux fichiers :

• yourdomain.key : votre clé privée. Conservez-la sur le serveur, sauvegardez-la en toute sécurité, et ne l’envoyez jamais à personne, y compris à l’autorité de certification. Quiconque détient la clé peut usurper l’identité de votre site.
• yourdomain.csr : votre demande de signature de certificat. C’est le fichier que vous soumettez au fournisseur SSL.

Sur Linux ou macOS, définissez immédiatement des permissions strictes sur la clé privée afin que seul l’utilisateur exécutant Node.js puisse la lire :

chmod 600 yourdomain.key

Si Node.js s’exécute sous un compte de service dédié (par exemple, node ou www-data), définissez également le propriétaire afin que le processus puisse lire la clé :

sudo chown node:node yourdomain.key

Étape 4 : vérifiez le CSR (facultatif mais recommandé)

Avant de le soumettre, vérifiez que le CSR contient le bon sujet et les bons SAN, et que sa signature est valide. Ceci décode la requête localement avec OpenSSL :

openssl req -noout -text -verify -in yourdomain.csr

Confirmez que la ligne Subject affiche bien vos informations, que X509v3 Subject Alternative Name répertorie tous les noms d’hôte attendus, et que la vérification de la signature affiche verify OK. L’algorithme de signature doit indiquer sha256WithRSAEncryption (ou ecdsa-with-SHA256 pour une clé ECDSA). Si vous préférez ne pas utiliser la ligne de commande, collez le CSR dans notre décodeur de CSR en ligne pour lire les mêmes champs dans un navigateur.

Étape 5 : soumettez votre CSR

Pour copier le CSR pour votre commande, affichez son contenu :

cat yourdomain.csr

Vous verrez un bloc de texte comme celui-ci :

-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----

Copiez l’intégralité du bloc, y compris les lignes —–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—– (chaque marqueur comporte cinq traits d’union de chaque côté). Ce bloc entier constitue votre CSR. Collez-le dans le formulaire de commande lors de votre achat, et conservez la clé privée correspondante en place sur le serveur.

Si vous préférez ne pas utiliser la ligne de commande, vous pouvez également créer la requête avec notre générateur de CSR en ligne. Notez qu’il génère la clé privée dans votre navigateur, alors sauvegardez cette clé vous-même et transférez-la sur le serveur Node.js.

Que se passe-t-il après l’émission du certificat par la CA

Une fois que la CA valide le CSR et émet le certificat, vous recevrez généralement votre certificat de serveur (un fichier .crt nommé d’après votre domaine) ainsi qu’un ou plusieurs certificats intermédiaires, parfois regroupés dans un fichier .ca-bundle. Node.js les charge en JavaScript : concaténez le certificat de serveur et les intermédiaires dans un seul fichier fullchain.crt, puis lisez-le avec fs.readFileSync() et transmettez-le à https.createServer() :

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('/path/to/yourdomain.key'),
  cert: fs.readFileSync('/path/to/fullchain.crt'),
  minVersion: 'TLSv1.2'
};

https.createServer(options, (req, res) => {
  res.writeHead(200);
  res.end('Welcome to a Node.js HTTPS servern');
}).listen(443);

Ce schéma de fullchain est celui utilisé par la plupart des configurations en production. La procédure complète (incluant un exemple avec les modules ES, une approche alternative avec un tableau ca:, et un exemple Express) est détaillée dans notre tutoriel d’installation SSL pour Node.js.

Une remarque sur les déploiements en production. En 2026, la plupart des applications Node.js qui gèrent du trafic public s’exécutent derrière un proxy inverse ou un équilibreur de charge cloud (NGINX, HAProxy, Caddy, AWS ALB, Cloudflare, Fastly) qui termine TLS en périphérie et transmet du HTTP ou HTTP/2 en clair à Node sur un port local élevé. Dans ce schéma, le certificat (et le CSR que vous avez généré ci-dessus) se trouve sur le proxy ou l’équilibreur de charge, et non sur le processus Node lui-même. Laisser Node.js terminer TLS directement convient parfaitement pour le développement, les services internes et les petits déploiements ; pour une application en production accessible au public, terminer TLS en périphérie est la configuration la plus courante.