Générer des certificats TLS avec openssl : clé, CSR et CA

Un service interne (une API, un intranet, un broker) a souvent besoin d'un certificat TLS sans passer par une autorité publique. openssl permet de tout produire soi-même : une clé privée, une demande de signature (CSR), un certificat auto-signé pour un test rapide, et surtout une autorité de certification interne (CA) capable de signer les certificats de tous vos services. Ce guide déroule chaque étape, puis montre comment faire approuver votre CA par les machines clientes. Pour administrateurs intermédiaires, toutes distributions. C'est un objectif LFCS. Commandes testées avec OpenSSL 3.

Ce que vous allez apprendre

Distinguer clé privée, CSR et certificat, et qui signe quoi.
Générer une clé et une demande de signature avec un subjectAltName.
Créer un certificat auto-signé pour un test.
Monter une autorité de certification interne et signer des certificats avec.
Installer une CA dans le magasin de confiance du système.

Trois objets à ne pas confondre

Avant les commandes, le vocabulaire, car toute la manipulation en découle :

La clé privée est le secret du serveur. Elle ne quitte jamais la machine et signe les échanges. Tout repose sur sa confidentialité.
Le CSR (Certificate Signing Request) est une demande : il contient l'identité du serveur (son nom de domaine) et sa clé publique, et il est envoyé à une autorité pour signature.
Le certificat est le CSR signé par une autorité. Il prouve que la clé publique appartient bien à l'identité annoncée, parce qu'une autorité de confiance l'a validé.

Un certificat auto-signé court-circuite l'autorité : le serveur signe son propre certificat. Pratique pour un test, mais aucun client ne lui fait confiance par défaut. Une autorité de certification interne (CA) résout cela : on lui fait confiance une fois, et elle signe ensuite tous les certificats de l'organisation.

Générer une clé privée

La clé se génère avec openssl genpkey. Une taille de 2048 bits en RSA est le minimum courant ; 4096 pour une CA, plus durable.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out server.key

Créer une demande de signature (CSR)

Le CSR associe la clé à une identité. Le champ décisif est le subjectAltName (SAN) : depuis des années, les navigateurs et clients ignorent le CN et n'acceptent que les noms listés dans le SAN. Un certificat sans SAN est refusé.

openssl req -new -key server.key -out server.csr \
  -subj "/C=FR/O=Exemple SARL/CN=www.exemple.test" \
  -addext "subjectAltName=DNS:www.exemple.test,DNS:exemple.test"

Vérifiez le contenu de la demande, en particulier le SAN :

openssl req -in server.csr -noout -subject
openssl req -in server.csr -noout -text | grep -A1 "Subject Alternative Name"

subject=C = FR, O = Exemple SARL, CN = www.exemple.test
    X509v3 Subject Alternative Name:
        DNS:www.exemple.test, DNS:exemple.test

Le raccourci : un certificat auto-signé

Pour un test local ou un service jamais exposé, un certificat auto-signé suffit, sans CSR ni autorité :

openssl req -x509 -key server.key -out selfsigned.crt -days 365 \
  -subj "/CN=www.exemple.test" \
  -addext "subjectAltName=DNS:www.exemple.test"

Il fonctionne immédiatement pour chiffrer, mais chaque client affichera un avertissement, puisque personne ne connaît son signataire. C'est là qu'intervient la CA interne.

Monter une autorité de certification interne

Une CA est simplement une clé et un certificat marqués comme autorité. La contrainte basicConstraints=CA:TRUE est ce qui autorise ce certificat à en signer d'autres.

Générer la clé de la CA, plus longue car elle protège toute la chaîne.
Fenêtre de terminal
```
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ca.key
```

Créer le certificat racine de la CA, auto-signé et valable plusieurs années.

openssl req -x509 -key ca.key -out ca.crt -days 3650 \
  -subj "/C=FR/O=Exemple SARL/CN=Autorite Interne Exemple" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

Vérifier que le certificat est bien une autorité.

openssl x509 -in ca.crt -noout -ext basicConstraints

X509v3 Basic Constraints: critical
    CA:TRUE

Signer un certificat avec la CA

La CA signe maintenant le CSR du serveur. L'option -copy_extensions copy est essentielle : sans elle, le subjectAltName du CSR serait perdu, et le certificat produit inutilisable.

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out server.crt -days 365 -copy_extensions copy

Certificate request self-signature ok

Le certificat porte désormais l'identité du serveur, signée par votre autorité, et conserve son SAN :

openssl x509 -in server.crt -noout -subject -issuer
openssl x509 -in server.crt -noout -ext subjectAltName

subject=C = FR, O = Exemple SARL, CN = www.exemple.test
issuer=C = FR, O = Exemple SARL, CN = Autorite Interne Exemple

Confirmez enfin que la chaîne est valide, c'est-à-dire que le certificat est bien signé par la CA :

openssl verify -CAfile ca.crt server.crt

server.crt: OK

Faire approuver la CA par les clients

Le serveur présente maintenant server.crt, mais les clients ne connaissent pas encore l'autorité qui l'a signé. Il faut installer le certificat de la CA (ca.crt, jamais la clé) dans le magasin de confiance de chaque machine cliente. La procédure diffère selon la famille de distribution.

RHEL/AlmaLinux
Debian/Ubuntu

sudo cp ca.crt /etc/pki/ca-trust/source/anchors/exemple-interne.crt
sudo update-ca-trust
trust list | grep "Autorite Interne Exemple"

sudo cp ca.crt /usr/local/share/ca-certificates/exemple-interne.crt
sudo update-ca-certificates

Le fichier doit porter l'extension .crt, sinon update-ca-certificates l'ignore.

Une fois la CA approuvée, tout certificat qu'elle a signé est accepté sans avertissement par les outils du système (navigateurs en ligne de commande, curl, clients applicatifs). Sur RHEL, trust list confirme l'ajout avec la mention trust: anchor.

À retenir

Trois objets : la clé privée (secret du serveur), le CSR (demande d'identité + clé publique), le certificat (CSR signé).
Le subjectAltName est obligatoire ; le CN seul est ignoré par les clients modernes.
Un certificat auto-signé dépanne pour un test ; une CA interne (basicConstraints=CA:TRUE) est la vraie solution pour plusieurs services.
À la signature, -copy_extensions copy préserve le SAN du CSR ; sans lui, le certificat est inutilisable.
On distribue ca.crt dans le magasin de confiance (update-ca-trust ou update-ca-certificates), jamais la clé de la CA.

Prochaines étapes

Diagnostiquer les erreurs TLS Lire un certificat et déboguer une chaîne avec openssl s_client

HTTP et HTTPS Comment TLS sécurise le web, du handshake au certificat