Comment générer un certificat auto-signé avec OpenSSL ?

Un certificat auto-signé est un certificat que vous vous délivrez vous-même au lieu de l’acheter auprès d’une autorité de certification. Les navigateurs ne lui font pas confiance automatiquement, il n’a donc pas sa place sur un site web public, mais c’est la manière la plus rapide de mettre en place HTTPS sur une machine de développement, un serveur de préproduction, un tableau de bord interne ou tout service qui ne sera jamais exposé sur l’internet public.

Ce guide vous montre comment créer un certificat auto-signé avec OpenSSL sous Windows, Linux et macOS. La commande est identique sur les trois systèmes. Vous verrez également comment vérifier que le certificat produit est réellement utilisable, et comment faire en sorte que votre propre machine lui fasse confiance afin que les avertissements du navigateur disparaissent.

Qu’est-ce qu’un certificat auto-signé

Un certificat auto-signé est un certificat numérique signé avec sa propre clé privée plutôt que par une autorité de certification (CA) de confiance. D’un point de vue cryptographique, c’est un certificat X.509 normal : il chiffre le trafic exactement aussi bien qu’un certificat acheté. Ce qui lui manque, c’est une chaîne de confiance. Rien en dehors de votre propre machine n’a de raison de lui faire confiance, donc les navigateurs affichent un avertissement jusqu’à ce que vous leur indiquiez le contraire.

Cela rend les certificats auto-signés adaptés pour :

• Le développement local, où vous avez besoin de HTTPS pour que les cookies, les service workers ou un SDK de paiement se comportent comme ils le feront en production.
• Les services internes tels qu’un tableau de bord intranet, un panneau de surveillance ou une interface de gestion d’appareils sur un réseau privé.
• Les tests et la préproduction, où vous souhaitez répéter une configuration TLS sans y consacrer un certificat.
• Les serveurs d’origine derrière un proxy qui accepte un certificat non fiable sur le tronçon interne, comme Cloudflare en mode Full.

Ils ne sont pas adaptés à tout ce qu’un véritable visiteur va charger. Nous détaillons cette distinction plus bas, dans la section sur les cas où il ne faut pas en utiliser.

Avant de commencer : vérifiez votre OpenSSL

Vous avez besoin de l’outil en ligne de commande OpenSSL. Vérifiez ce que vous avez :

openssl version

• Linux : OpenSSL est préinstallé sur la plupart des distributions. Si ce n’est pas le cas, consultez notre guide sur comment installer OpenSSL sur Ubuntu.
• Windows : OpenSSL n’est pas inclus. Suivez nos instructions sur comment installer OpenSSL sur Windows, puis exécutez la commande depuis l’invite de commandes ou PowerShell.
• macOS : Apple fournit LibreSSL, un fork d’OpenSSL, comme commande openssl intégrée, donc cela renvoie quelque chose comme LibreSSL 3.3.6 plutôt qu’une version d’OpenSSL.

La commande principale de ce guide fonctionne aussi bien sur LibreSSL 3.3.6 que sur les versions récentes d’OpenSSL, donc les utilisateurs Mac peuvent utiliser l’outil intégré. Si vous préférez avoir un véritable OpenSSL (certaines des commandes facultatives ci-dessous en ont besoin), installez-le avec le gestionnaire de paquets Homebrew et appelez-le par son chemin complet :

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

Sur les Mac Intel, le chemin est plutôt /usr/local/opt/openssl@3/bin/openssl. Pour plus de détails sur la lecture du résultat, consultez notre guide sur comment vérifier votre version d’OpenSSL.

Comment créer un certificat auto-signé avec OpenSSL

Étape 1 : Ouvrez un terminal

Sous Linux, appuyez sur Ctrl + Alt + T ou recherchez « Terminal » dans votre menu d’applications. Sous macOS, ouvrez Applications, puis Utilitaires, puis Terminal, ou appuyez sur Cmd + Espace et tapez « Terminal ». Sous Windows, appuyez sur Win + R, tapez cmd, et appuyez sur Entrée.

Étape 2 : Déplacez-vous dans le dossier où vous voulez les fichiers

OpenSSL écrit son résultat dans le répertoire où vous vous trouvez actuellement, pas dans le répertoire où OpenSSL est installé. Créez un dossier pour ce certificat et déplacez-vous à l’intérieur pour que la clé et le certificat se retrouvent dans un endroit où vous pourrez les trouver :

mkdir my-cert
cd my-cert

Sous Windows, utilisez les deux mêmes commandes dans l’invite de commandes. N’exécutez pas les commandes depuis l’intérieur du dossier du programme OpenSSL : sous Windows, ce répertoire n’est souvent pas accessible en écriture pour un utilisateur normal, et mélanger vos clés avec les fichiers binaires les rend faciles à perdre.

Étape 3 : Exécutez la commande de certificat

Cette seule commande génère la clé privée et le certificat auto-signé ensemble. Remplacez example.com et www.example.com par les noms sous lesquels votre service sera réellement accessible :

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Gardez-la sur une seule ligne. L’invite de commandes et les shells Unix utilisent des caractères de continuation de ligne différents, et une seule ligne fonctionne partout. Utilisez des guillemets doubles, pas des guillemets simples, pour la même raison : l’invite de commandes ne traite pas les guillemets simples comme des guillemets.

Voici ce que fait chaque partie :

• req -x509 : produit un certificat signé et finalisé plutôt qu’une demande de signature de certificat.
• -newkey rsa:2048 : crée une nouvelle clé privée RSA de 2048 bits dans le cadre de la même commande. 2048 bits est le minimum actuel et une valeur par défaut raisonnable. Utilisez rsa:4096 si votre politique exige une clé plus grande, au prix de poignées de main plus lentes.
• -keyout private.key : le nom de fichier pour la clé privée.
• -out certificate.crt : le nom de fichier pour le certificat.
• -days 365 : la durée de validité du certificat. Consultez la section sur la validité ci-dessous avant de modifier cette valeur.
• -nodes : laisse la clé privée non chiffrée, afin que votre serveur web puisse démarrer sans qu’un humain ait à taper une phrase secrète.
• -addext « subjectAltName=… » : la liste des noms d’hôte pour lesquels le certificat est valide. Sans cela, le certificat ne correspond à rien.
• -addext « basicConstraints=critical,CA:FALSE » : marque le certificat comme un certificat d’entité finale (serveur) plutôt qu’une autorité de certification.
• -addext « extendedKeyUsage=serverAuth » : indique que le certificat est destiné à authentifier un serveur TLS. Les plateformes Apple considèrent ceci comme obligatoire.

Pourquoi les trois options -addext sont importantes

Ces trois indicateurs font la différence entre un certificat qui fonctionne et un certificat que les clients refusent purement et simplement. Ils valent la peine d’être compris, car un certificat auto-signé créé sans eux échoue de trois manières qui sont faciles à mal diagnostiquer.

Le Subject Alternative Name est l’endroit où résident les noms d’hôte. Les navigateurs ont cessé de lire le champ Common Name il y a des années et ne font désormais correspondre le nom d’hôte qu’avec l’extension Subject Alternative Name (SAN). Un certificat sans SAN ne correspond à aucun site, quel que soit le caractère correct du Common Name. Listez tous les noms que vous utiliserez, séparés par des virgules. Pour un service local, vous pouvez aussi inclure une adresse IP :

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

Sans CA:FALSE, OpenSSL vous construit un certificat d’autorité de certification. Lorsque req -x509 est laissé à ses valeurs par défaut, il définit basicConstraints sur critical, CA:TRUE, ce qui décrit une autorité de certification et non un serveur web. Chrome et Safari acceptent cela sur un certificat serveur. Firefox ne le fait pas, et s’arrête avec MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Vous pouvez toujours cliquer sur Avancé et ajouter une exception, mais vous contourneriez alors un certificat que vous savez déjà malformé, et d’autres clients placent la limite à des endroits différents. Passer basicConstraints=critical,CA:FALSE évite cette situation dès le départ.

La version LibreSSL fournie par macOS se comporte différemment ici : laissée à ses valeurs par défaut, elle écrit un certificat X.509 version 1 sans aucune extension, donc vous n’avez pas le problème CA:TRUE mais vous n’avez pas non plus de Subject Alternative Name. Fournir les extensions explicitement vous donne le même certificat correct sur les deux outils.

Sans serverAuth, les plateformes Apple rejettent le certificat. Les exigences publiées par Apple pour les certificats de confiance stipulent qu’un certificat de serveur TLS doit porter une extension ExtendedKeyUsage contenant l’OID id-kp-serverAuth. Un certificat sans cela échoue à la validation de certificat macOS sous la politique TLS avec le message « Invalid Extended Key Usage for policy », même lorsque le certificat est fourni comme sa propre ancre de confiance. Firefox et Chrome sont plus tolérants et traitent un ExtendedKeyUsage manquant sur un certificat serveur comme autorisé, donc cela est facile à manquer jusqu’à ce qu’un Mac ou un iPhone soit l’appareil qui ne se connectera pas. Ajouter extendedKeyUsage=serverAuth ne coûte rien sur les autres plateformes et c’est ce qu’une CA publique délivrerait de toute façon.

Étape 4 : Renseignez les détails du certificat

OpenSSL demande les champs qui composent le Distinguished Name. Appuyez sur Entrée pour ignorer l’un d’entre eux, mais renseignez-en au moins un, et faites-en le Common Name. La version LibreSSL sur macOS s’arrête avec « error, no objects specified in config file » et n’écrit rien si vous laissez tous les champs vides. Les valeurs ci-dessous sont des exemples, utilisez donc les vôtres :

• Country Name : le code à deux lettres de votre pays, par exemple FR.
• State or Province Name : écrit en entier, par exemple Île-de-France.
• Locality Name : votre ville, par exemple Paris.
• Organization Name : le nom de votre entreprise ou projet, par exemple Example Inc.
• Organizational Unit Name : l’équipe responsable, par exemple IT.
• Common Name : le nom d’hôte principal, par exemple example.com. Utilisez le même nom que celui que vous avez mis en premier dans la liste Subject Alternative Name.
• Email Address : une adresse de contact, par exemple [email protected]. Facultatif.

Seul le Common Name a vraiment de l’importance ici, et seulement comme étiquette : la correspondance de nom d’hôte est effectuée par le Subject Alternative Name que vous avez déjà défini sur la ligne de commande. Tout le reste est descriptif.

Vous remarquerez que la commande ne demande jamais de mot de passe de challenge. Cette invite appartient aux demandes de signature de certificat, et c’est un champ vestigial que les CA ignorent ou rejettent généralement. Comme cette commande produit un certificat finalisé plutôt qu’une demande, l’invite n’apparaît pas du tout.

Étape 5 : Vérifiez le certificat avant de l’utiliser

Ne sautez pas cette étape. Un certificat auto-signé peut être généré avec succès et rester quand même inutilisable, et l’échec ne se manifeste que plus tard sous la forme d’une erreur de navigateur. Relisez le certificat :

openssl x509 -in certificate.crt -noout -text

Dans le bloc des extensions X509v3, vous recherchez exactement trois choses :

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Si la ligne Subject Alternative Name est manquante, le certificat ne correspondra à aucun nom d’hôte. Si Basic Constraints indique CA:TRUE, Firefox s’arrêtera dessus. Si la ligne Extended Key Usage est manquante, les plateformes Apple refuseront le certificat. Dans l’un de ces cas, supprimez les deux fichiers et réexécutez la commande avec les trois options -addext présentes.

Sur OpenSSL 3.x, vous pouvez demander uniquement ces extensions au lieu de lire tout le certificat :

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

L’indicateur -ext n’existe pas dans la version LibreSSL fournie par macOS, qui signale « unknown option -ext ». Sur un Mac standard, utilisez la version -text ci-dessus.

Pour confirmer que le certificat et la clé vont bien ensemble, comparez leurs modules. Les deux commandes doivent afficher le même hachage :

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

Le certificat lui-même est un fichier texte. En l’ouvrant dans un éditeur de texte, vous verrez un bloc en base64 entre les lignes BEGIN CERTIFICATE et END CERTIFICATE, qui est ce que vous collez dans les panneaux de contrôle qui demandent le certificat plutôt qu’un téléchargement de fichier.

Variantes de la commande

Le générer sans aucune invite

Pour les scripts et les pipelines CI, fournissez le Distinguished Name avec -subj et la commande s’exécute sans intervention :

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Utiliser une clé EC au lieu de RSA

Les clés à courbe elliptique sont plus petites et plus rapides que RSA pour une force équivalente, et chaque navigateur actuel les prend en charge. P-256 est le choix standard :

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Le résultat est signé avec ecdsa-with-SHA256. Restez avec RSA si vous devez prendre en charge d’anciens clients embarqués ou des versions Java héritées, qui manquent parfois de support EC.

Utilisez un véritable OpenSSL pour cela. La version LibreSSL sur macOS accepte la commande, mais elle écrit la courbe dans le certificat comme un ensemble complet de paramètres explicites au lieu de l’identifiant standard P-256. La RFC 5480 stipule que la forme explicite ne doit pas être utilisée dans les certificats, et macOS lui-même rejette un certificat encodé de cette manière.

Vérifiez le résultat avec openssl x509 -in certificate.crt -noout -text : vous voulez voir une ligne indiquant « ASN1 OID: prime256v1 », pas un bloc listant Prime, A, B, et Generator. Sur un Mac standard, utilisez soit la commande RSA ci-dessus, soit installez d’abord OpenSSL via Homebrew.

-nodes ou -noenc ?

Les deux indicateurs font la même chose : ils empêchent OpenSSL de chiffrer la clé privée avec une phrase secrète. OpenSSL 3.x a ajouté -noenc comme nom plus clair et liste -nodes comme obsolète, bien qu’il l’accepte encore. LibreSSL, fourni par macOS, ne reconnaît pas du tout -noenc et renvoie une erreur.

Ce guide utilise -nodes car c’est l’option qui fonctionne sur toutes les versions que vous êtes susceptible de rencontrer, y compris un Mac standard. Si vous êtes sur OpenSSL 3.x et souhaitez éviter l’orthographe obsolète, remplacez par -noenc. Rien d’autre ne change.

Si vous supprimez complètement l’indicateur, OpenSSL chiffre la clé avec une phrase secrète que vous choisissez, et votre serveur web vous la demandera alors à chaque redémarrage. C’est rarement ce que vous voulez pour un certificat de développement.

Faites en sorte que votre machine fasse confiance au certificat

Un certificat auto-signé correct produit toujours un avertissement du navigateur, car rien ne lui a indiqué de lui faire confiance. L’ajouter à votre magasin de confiance local est ce qui désactive l’avertissement, et c’est généralement tout le but d’en créer un.

Ne faites cela que sur des machines que vous contrôlez, et uniquement pour des certificats que vous avez générés vous-même. Un certificat de confiance est fiable pour tous les sites qu’il désigne, alors traitez la clé privée en conséquence et ne la partagez jamais.

Trousseau macOS

Ajoutez le certificat au trousseau système et marquez-le comme fiable pour TLS. Il vous sera demandé votre mot de passe administrateur :

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

La partie -p ssl limite la confiance aux connexions TLS. Omettez-la et le certificat sera fiable pour tous les usages connus de macOS, y compris la signature de code, ce qui est bien plus que ce dont un certificat de développement a besoin.

Pour le faire via l’interface à la place, double-cliquez sur le fichier de certificat pour ouvrir Trousseau d’accès, trouvez l’entrée sous le trousseau System, ouvrez-la, développez Confiance, et réglez Lors de l’utilisation de ce certificat sur Toujours faire confiance. Pour annuler cela plus tard, supprimez l’entrée dans Trousseau d’accès.

Magasin de certificats Windows

Ouvrez l’invite de commandes en tant qu’administrateur (appuyez sur Win + R, tapez cmd, puis appuyez sur Ctrl + Maj + Entrée) et ajoutez le certificat au magasin des autorités de certification racines de confiance :

certutil -addstore -f "Root" certificate.crt

Vous pouvez aussi double-cliquer sur le fichier de certificat, choisir Installer le certificat, sélectionner Ordinateur local, puis Placer tous les certificats dans le magasin suivant, et naviguer jusqu’à Autorités de certification racines de confiance. Pour le supprimer plus tard, ouvrez certmgr.msc et supprimez l’entrée de ce magasin.

ca-certificates sous Linux

Sous Debian et Ubuntu, copiez le certificat dans le répertoire des ancres locales et reconstruisez le paquet. Le fichier doit conserver une extension .crt sinon l’outil de mise à jour l’ignorera :

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

Sur RHEL, CentOS, AlmaLinux, Rocky et Fedora, les chemins sont différents :

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

L’exception Firefox

Firefox conserve son propre magasin de confiance plutôt que d’utiliser celui du système d’exploitation. Sous Windows et macOS, il lit également par défaut les racines ajoutées au magasin du système, donc les étapes ci-dessus le couvrent normalement. Sous Linux, ce n’est pas le cas, donc le certificat doit être importé directement dans Firefox : ouvrez Paramètres, puis Vie privée & Sécurité, faites défiler jusqu’à Certificats, cliquez sur Afficher les certificats, ouvrez l’onglet Autorités, et utilisez Importer.

Redémarrez le navigateur après l’une de ces modifications. Les navigateurs mettent en cache les décisions relatives aux certificats, et une session obsolète est une raison fréquente pour laquelle l’avertissement semble persister après un import correct.

Quand ne pas utiliser un certificat auto-signé

Ne le mettez jamais sur un site que le public visitera. Chaque visiteur reçoit un avertissement de sécurité en pleine page, et ceux qui continuent quand même ont été formés à cliquer précisément à travers l’avertissement qui les protège d’une véritable attaque. Il n’y a par ailleurs aucun moyen pour un visiteur de distinguer votre certificat auto-signé de celui d’un attaquant, ce qui est précisément la raison pour laquelle les navigateurs s’en méfient. Nous entrons dans les détails dans notre article sur les dangers des certificats auto-signés.

Les certificats auto-signés échouent aussi à des exigences pratiques au-delà de l’avertissement du navigateur. Les processeurs de paiement, les magasins d’applications, les applications mobiles avec épinglage de certificat, et la plupart des régimes de conformité exigent un certificat provenant d’une CA reconnue. Pour tout ce qui est destiné au public, utilisez un certificat délivré par une autorité de certification de confiance, que vous demandez avec une CSR et validez avant l’émission. Une fois qu’il est en production, confirmez l’installation avec notre SSL Checker.