Comment générer un CSR sur Sentora

Ce guide vous montre comment générer un CSR (Certificate Signing Request) sur Sentora avec OpenSSL. Le panneau de contrôle de Sentora ne dispose d’aucun outil CSR intégré, vous créez donc la demande directement sur le serveur, qui fonctionne sous Apache et Linux. Une seule commande produit deux fichiers à la fois : une clé privée qui reste sur votre serveur, et le CSR que vous soumettez à votre autorité de certification (CA).

Sentora évolue lentement mais n’est pas abandonné ; la version stable actuelle est la v2.0.2 (mai 2024, sous PHP 7.4), maintenue par d’anciens développeurs de ZPanel, et le flux de travail OpenSSL décrit ci-dessous n’est pas affecté par la version du panneau.

Si vous avez déjà généré votre CSR et reçu le certificat émis par votre CA, passez directement à l’installation de votre certificat SSL sur Sentora. Sinon, suivez les étapes ci-dessous.

Étape 1 : Connectez-vous au serveur en tant que root

Ouvrez une session SSH vers le serveur qui exécute Sentora et passez en root. Générer un CSR ne nécessite pas strictement le compte root, mais vous en aurez besoin pour installer OpenSSL à l’étape suivante s’il est manquant :

sudo -i

Étape 2 : Vérifiez qu’OpenSSL est installé

OpenSSL est fourni avec toutes les versions actuelles de Debian, Ubuntu, CentOS, AlmaLinux et Rocky Linux, il est donc presque certainement déjà présent. Vérifiez la version :

openssl version

Si la commande affiche un numéro de version, passez à l’étape 3. S’il n’est pas installé, ajoutez-le avec le gestionnaire de paquets de votre distribution.

Sur Debian ou Ubuntu :

apt update && apt install -y openssl

Sur CentOS, AlmaLinux ou Rocky Linux :

dnf install -y openssl

Sur les systèmes plus anciens où dnf n’est pas disponible, yum install -y openssl fonctionne de la même manière.

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

Exécutez la commande ci-dessous depuis un répertoire dans lequel vous pouvez écrire, comme le répertoire personnel. Elle crée la clé privée et le CSR en une seule étape et inclut les Subject Alternative Names (SAN) que les navigateurs et CA modernes exigent :

openssl req -new -newkey rsa:2048 -nodes 
-keyout example.key 
-out example.csr 
-subj "/C=US/ST=New York/L=New York/O=Example LLC/CN=example.com" 
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Voici ce que fait chaque partie :

• req -new crée une nouvelle demande de signature de certificat.
• -newkey rsa:2048 génère une nouvelle clé privée RSA de 2048 bits. 2048 bits est le minimum actuel pour les certificats publics ; utilisez rsa:4096 si vous souhaitez une clé plus grande.
• -nodes laisse la clé privée non chiffrée (sans phrase de passe), afin qu’Apache puisse démarrer sans demander de mot de passe. C’est l’orthographe portable qui fonctionne sur toutes les versions d’OpenSSL.
• -keyout example.key écrit la clé privée. Gardez ce fichier privé et ne l’envoyez jamais à qui que ce soit.
• -out example.csr écrit le CSR que vous soumettez à la CA.
• -subj renseigne les champs du sujet directement dans la commande afin qu’elle s’exécute sans invites interactives. Définissez CN (Common Name) avec votre nom de domaine pleinement qualifié.
• -addext « subjectAltName=… » ajoute les entrées SAN. Les CA émettent en fonction de la liste SAN, incluez donc chaque nom d’hôte que le certificat doit couvrir.

Remplacez chaque espace réservé par vos informations réelles :

• example.com : votre domaine réel, à la fois dans le CN et dans la liste SAN.
• C, ST, L, O : votre code pays à deux lettres (en majuscules, par exemple US ou GB), votre état ou province, votre ville et le nom légal de votre organisation. Pour un certificat à validation de domaine (DV), ces champs ne sont pas vérifiés, mais la commande a tout de même besoin de valeurs valides.
• example.key et example.csr : les noms de fichiers que vous souhaitez, du moment que vous restez cohérent.

OpenSSL moderne signe la demande avec SHA-256 par défaut, ce qui est exigé par les CA, il n’y a donc pas d’option de condensé séparée à ajouter.

Sécuriser un wildcard ou des sous-domaines supplémentaires

Pour ajouter d’autres noms d’hôte, étendez la liste SAN avec des entrées DNS: supplémentaires séparées par des virgules, par exemple DNS:api.example.com. Pour un certificat wildcard, définissez le CN sur *.example.com et gardez le domaine racine dans la liste SAN. Un wildcard couvre exactement un niveau de sous-domaines (www.example.com, mail.example.com) mais pas le domaine racine seul (example.com), qui doit donc être listé séparément pour être couvert :

-addext "subjectAltName=DNS:*.example.com,DNS:example.com"

Vous préférez une clé ECDSA ?

Les clés ECDSA sont plus petites et plus rapides que RSA à niveau de sécurité équivalent, et sont prises en charge par tous les navigateurs actuels. Pour générer à la place une clé et un CSR P-256 (prime256v1), modifiez l’argument -newkey :

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout example.key 
-out example.csr 
-subj "/C=US/ST=New York/L=New York/O=Example LLC/CN=example.com" 
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"

L’option ec_param_enc:named_curve conserve la courbe stockée par son nom, ce qui est exigé par PKIX ; sans elle, certaines versions d’OpenSSL intègrent les paramètres complets de la courbe et la CA rejette la demande.

Étape 4 : Vérifiez le CSR

Avant de soumettre la demande, confirmez qu’elle contient le bon domaine et les bons SAN, et que sa signature est valide. Cette commande décode le CSR et vérifie la signature localement :

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

Recherchez verify OK dans le résultat, vérifiez que la ligne Subject affiche votre Common Name, et confirmez que la section X509v3 Subject Alternative Name liste chaque nom d’hôte attendu. Si un SAN est manquant, régénérez le CSR avec la valeur -addext correcte. Vous pouvez également coller la demande dans notre décodeur de CSR en ligne pour vérifier ces champs dans un navigateur.

Étape 5 : Repérez et soumettez le CSR

Listez le répertoire de travail pour confirmer que les deux fichiers existent :

ls -l example.key example.csr

Vous êtes sur un serveur Linux, ouvrez donc le CSR avec un visualiseur de terminal, pas avec un éditeur Windows. Affichez-le à l’écran avec :

cat example.csr

Copiez l’intégralité du bloc, y compris la première et la dernière ligne. Un CSR est délimité par des marqueurs CERTIFICATE REQUEST avec cinq traits d’union de chaque côté, et non par les marqueurs CERTIFICATE d’un certificat émis :

-----BEGIN CERTIFICATE REQUEST-----
MIIC...base64-encoded data...AB
-----END CERTIFICATE REQUEST-----

Collez ce bloc dans votre formulaire de commande SSL. Une fois que la CA a validé la demande et émis votre certificat, suivez notre guide sur l’installation d’un certificat SSL sur Sentora pour le déployer. Conservez le fichier example.key sur le serveur : vous en avez besoin avec le certificat émis pour activer HTTPS, et vous ne devez jamais l’envoyer à la CA ou à qui que ce soit d’autre.

Si vous préférez ne pas utiliser du tout la ligne de commande, vous pouvez créer la demande avec notre générateur de CSR et coller le résultat dans votre commande.