Comment générer un CSR sur NGINX

Ce tutoriel vous montre comment générer un CSR sur NGINX. NGINX ne génère pas lui-même les Certificate Signing Requests : vous créez la clé privée et le CSR avec OpenSSL sur le même serveur qui hébergera le certificat, puis vous soumettez le CSR à votre autorité de certification (CA). Une fois le certificat émis reçu, vous indiquez à NGINX où le trouver grâce aux directives ssl_certificate et ssl_certificate_key.

Les étapes ci-dessous fonctionnent sur toutes les distributions Linux prises en charge qui proposent NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), car chacune inclut OpenSSL 1.1.1 ou 3.x. Les versions modernes d’OpenSSL signent les requêtes avec SHA-256 par défaut, vous n’avez donc pas besoin d’ajouter un indicateur de condensé (digest).

Étape 1 : Connectez-vous à votre serveur NGINX

Connectez-vous au serveur qui exécute NGINX via SSH depuis votre machine locale (Terminal sur macOS ou Linux, PowerShell ou Windows Terminal sous Windows). Remplacez le nom d’utilisateur et l’hôte par les vôtres :

ssh your-user@your-nginx-server

Générez le CSR sur le serveur qui servira le certificat. La clé privée est créée à côté du CSR et doit rester sur ce serveur. Exécuter ces commandes localement puis copier la clé ailleurs va à l’encontre de l’intérêt même d’avoir une clé privée.

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

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 Subject Alternative Names (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 NGINX puisse la lire au démarrage sans demander de phrase de passe. Si vous préférez chiffrer la clé, supprimez -nodes et utilisez la directive ssl_password_file de NGINX pour fournir la phrase de passe au démarrage et lors du rechargement.
• -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 région (État) et votre ville, et non les valeurs d’exemple. CN (Common Name) est votre domaine principal.
• -addext « subjectAltName=… » liste chaque nom d’hôte que le certificat doit couvrir. Les CA publiques valident par rapport à la liste SAN, incluez donc également le Common Name ici. L’option -addext nécessite OpenSSL 1.1.1 ou une version plus récente ; toutes les distributions Linux prises en charge fournissent au moins cette version.

Remplacez yourdomain.com par votre domaine réel partout. 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 caractère générique (wildcard), incluez à la fois le domaine avec joker et le domaine nu : 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 comme ceci à la place :

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"

Si votre OpenSSL ne prend pas en charge -addext

Sur des systèmes très anciens équipés d’une version d’OpenSSL antérieure à 1.1.1, l’option -addext n’est pas disponible. Créez un petit fichier de configuration appelé san.cnf avec ce contenu :

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

[ dn ]
C  = US
ST = YourState
L  = YourCity
O  = YourCompany
CN = yourdomain.com

[ req_ext ]
subjectAltName = @alt_names

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

Puis exécutez :

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key -out yourdomain.csr -config san.cnf

Étape 3 : Localisez vos fichiers

Listez le répertoire actuel 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 de façon sécurisée, et ne l’envoyez jamais à qui que ce soit, y compris à l’autorité de certification. Quiconque détient la clé peut usurper l’identité de votre site.
• yourdomain.csr : votre Certificate Signing Request. C’est le fichier que vous soumettez au fournisseur SSL.

Définissez immédiatement des permissions strictes sur la clé privée afin que seul root puisse la lire :

sudo chmod 600 yourdomain.key
sudo chown root:root 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. Cela 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 liste chaque nom d’hôte attendu, et que la vérification de la signature affiche verify OK. L’algorithme de signature devrait afficher 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 de 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 tirets de chaque côté). Ce bloc complet 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 vers le serveur.

Que se passe-t-il une fois que la CA émet le certificat

Une fois que la CA valide le CSR et émet le certificat, vous recevrez généralement votre certificat 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. NGINX s’attend à ce que le certificat serveur et la chaîne intermédiaire soient combinés en un seul fichier (le « fullchain ») et référencés par ssl_certificate ; la clé privée que vous avez générée ci-dessus est référencée séparément par ssl_certificate_key. La procédure complète (construction du fullchain, modification du bloc serveur, test et rechargement) est couverte dans notre tutoriel d’installation SSL pour NGINX.