Générateur de certificats auto-signés

Un certificat et sa clé privée pour un service interne, sans mémoriser une incantation openssl : saisissez le nom commun, énumérez chaque nom et chaque IP que le certificat doit couvrir, choisissez la validité et la taille de clé, et téléchargez les deux fichiers PEM. Les clés sont générées localement dans votre navigateur et ne sont jamais téléversées : cette page ne fait aucune requête réseau, et la clé n’existe que dans votre onglet jusqu’à ce que vous l’enregistriez.

Les clés plus grandes sont plus lentes à générer : 4096 bits peut prendre un moment sur une machine modeste. Le travail se fait sur votre machine, dans cet onglet : laissez-le ouvert et laissez-le finir.

À quoi sert un certificat auto-signé

Un certificat auto-signé est un certificat dont l’émetteur et le sujet sont les mêmes : il se porte garant de lui-même. Cela ressemble à un défaut, et pour le web public c’en est un : le navigateur d’un visiteur n’a aucune raison de croire la parole d’un inconnu. Mais une grande part du TLS ne fait jamais face au public : tableaux de bord internes, environnements de laboratoire et de préproduction, services de laboratoire domestique, interfaces d’administration d’équipements réseau et conversations de service à service au sein d’une même organisation. Pour ceux-là, le public est fait de machines que vous contrôlez, et la question de la confiance a une autre réponse : vous installez le certificat (ou votre propre petite CA) dans les magasins de confiance que vous gérez, une fois, délibérément. En échange, vous obtenez chiffrement et identité à l’intérieur de vos propres murs sans qu’une CA publique apprenne jamais vos noms d’hôtes internes — des noms qui sont, en eux-mêmes, une carte de votre infrastructure.

Le rituel de génération était autrefois une commande openssl dont personne ne se souvenait et que tout le monde copiait-collait, avec des SAN boulonnés via un fichier de configuration parce que l’option correspondante n’existait pas dans les anciennes versions. Cette page existe pour que la forme du certificat soit visible à la place : les noms sont une liste que vous pouvez lire, la validité est un nombre de jours que vous choisissez en sachant qu’il expirera, et la taille de clé est une décision plutôt qu’une valeur par défaut que vous n’aviez jamais remarquée. Ce qu’elle ne fait délibérément pas, c’est prétendre être une CA : il n’y a ni chaîne, ni intermédiaire, ni rien à révoquer. Un service, un certificat, une date d’expiration à suivre.

Faire en sorte que les clients l’acceptent

Générer le certificat est la moitié facile ; la confiance est le déploiement. Sur une poignée de vos propres machines, ajouter le certificat au magasin de confiance du système d’exploitation (ou du navigateur) met fin aux avertissements pour de bon, et des outils comme curl et git acceptent un pointeur --cacert par commande au lieu de la dangereuse habitude de désactiver la vérification : l’option -k entraîne tout le monde à ignorer précisément l’avertissement qui détecterait une vraie attaque. Quand le public dépasse une poignée de machines, passez des certificats auto-signés isolés à une petite CA privée : signez avec elle les certificats de service, ne distribuez que le certificat de la CA, et la rotation cesse d’être une tournée de chaque client. Et quand un service s’avère finalement faire face au public, remplacez le certificat par un certificat de confiance publique : le vérificateur SSL vérifie ce qu’un serveur présente réellement une fois en ligne, ce qui est le moment où l’auto-signé cesse d’être un choix.

Outils associés : relisez n’importe quel certificat avec l’analyseur de certificats SSL, ou vérifiez ce qu’un serveur en direct présente avec le vérificateur SSL.

Lecture complémentaire : une routine de fiabilité — pourquoi les certificats internes et leurs dates d’expiration appartiennent à la même page de planification que les rotations et les sauvegardes.

La génération de certificats utilise node-forge, sous licence BSD-3-Clause, chargé uniquement lorsque vous appuyez sur Générer. Aucune partie de cet outil ne fait de requête réseau.

Questions fréquentes

Où devrais-je utiliser un certificat auto-signé ?

Sur des choses auxquelles seuls vous et vos propres systèmes parlez : tableaux de bord internes, environnements de laboratoire et de préproduction, services de laboratoire domestique, pages d’administration d’appareils, et comme substitut qui permet à un serveur de démarrer avant l’émission d’un vrai certificat. La règle est la portée : si le navigateur d’un inconnu le verra un jour, il lui faut à la place un certificat de confiance publique — ceux-là sont gratuits chez Let’s Encrypt.

Pourquoi les navigateurs avertissent-ils pour les certificats auto-signés ?

Parce qu’« auto-signé » signifie que le seul à se porter garant du certificat est lui-même. Le chiffrement fonctionne — la connexion est privée —, mais rien ne prouve que le serveur est bien celui qu’il prétend être, ce qui est la moitié du TLS qu’une autorité de certification fournit normalement. Les navigateurs avertissent donc jusqu’à ce que le certificat (ou une CA que vous contrôlez) soit ajouté au magasin de confiance des machines qui l’utilisent.

Pourquoi le nom commun apparaît-il aussi dans la liste des SAN ?

Les navigateurs modernes ignorent complètement le champ du nom commun et vérifient à la place la liste des noms alternatifs du sujet. Un certificat dont le nom principal ne figure pas dans sa propre liste de SAN échoue sur le nom même pour lequel il a été créé — l’erreur d’auto-signature la plus courante —, donc cette page ajoute toujours le nom commun aux SAN.

RSA 2048 bits suffit-il, ou devrais-je choisir 4096 ?

RSA 2048 bits est la base actuelle et convient aux services internes ; c’est ce que la plupart des certificats publics utilisent encore. 4096 bits achète une marge contre la cryptanalyse future au prix d’une génération plus lente et de poignées de main légèrement plus lentes. Cela a du sens pour une CA interne de longue durée ou un service que vous ne pouvez pas réémettre facilement. La génération se fait sur votre propre machine dans les deux cas — 4096 bits peut prendre un moment, et l’onglet travaille, il n’est pas bloqué.

Est-il sûr de générer une clé privée dans une page web ?

Sur cette page, oui, en raison de sa construction : la paire de clés est générée localement dans votre navigateur avec la bibliothèque node-forge, la page ne fait aucune requête réseau, et rien de ce que vous générez n’est téléversé, journalisé ou stocké. L’habitude générale vaut quand même la peine d’être gardée : ne générez des clés que sur des pages (et des machines) auxquelles vous faites confiance, et traitez le fichier de clé privée comme un secret dès l’instant où il existe.