Générateur de CSR

Parce qu'une clé privée qui arrive sur le serveur de quelqu'un d'autre répond à la définition même du secteur d'une clé compromise, quoi que ce serveur en fasse ensuite.

Les Baseline Requirements du CA/Browser Forum la définissent sans laisser de place à la discussion : « Une clé privée est considérée comme compromise si sa valeur a été divulguée à une personne non autorisée, ou si une personne non autorisée y a eu accès. » Aucun mésusage n'est nécessaire. L'arrivée suffit.

Ce n'est pas théorique. En 2020, DigiCert a trouvé 337 clés privées que des clients avaient collées à côté de leur demande, a révoqué tous les certificats concernés et l'a signalé publiquement : « en envoyant la clé privée à DigiCert avec le CSR, le client a compromis la clé privée », en ajoutant que « la seule partie d'un CSR que nous utilisons est la clé publique ». Un générateur qui crée la clé sur son propre serveur et vous en remet une copie l'a, selon cette définition, déjà compromise. Cette page ne peut pas faire cela : crypto.subtle.generateKey s'exécute dans votre navigateur, dans un cadre isolé qui n'a le droit de se connecter nulle part, et la page autour n'en voit que la clé publique.

ECDSA P-256 pour tout ce qui est nouveau : elle est aussi solide qu'une clé RSA de 3072 bits, bien plus petite, et autorisée par les règles que suit toute autorité de certification publique. RSA 2048 quand un ancien équipement doit lire la clé.

Le NIST place P-256 et RSA-3072 à la même force de sécurité de 128 bits, et ne donne aucune force propre à RSA-4096 : le palier suivant de son tableau est de 7680 bits. Une clé de 4096 bits impose donc à chaque visiteur un travail de négociation supplémentaire, sans gain documenté. P-384 est le palier de 192 bits, et les Baseline Requirements autorisent aussi P-521, mais Let's Encrypt refuse P-521 : une demande peut être parfaitement légale et échouer quand même chez l'AC que vous comptiez utiliser.

Ed25519 est proposée ici parce qu'elle est excellente pour SSH, pour la signature et pour une AC privée — mais aucune autorité de certification publique n'émettra de certificat TLS pour cette clé. Les règles listent RSA et les trois courbes du NIST, puis précisent qu'« aucun autre algorithme ni taille de clé n'est autorisé ». Il en va de même pour ML-DSA, post-quantique : le vote qui l'aurait permis en TLS public a été clos sans être adopté en octobre 2026. Le générateur l'indique à côté de chaque choix plutôt que de vous laisser l'apprendre par un e-mail de refus.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr crée la clé et la demande en une seule étape.

Le générateur écrit la commande correspondant à ce que vous avez rempli, noms alternatifs et chaque extension compris, et nos tests la font passer par OpenSSL pour vérifier qu'elle crée le même sujet et les mêmes extensions que la page. Ajoutez -subj "/CN=example.com" pour éviter les questions, -addext "subjectAltName=DNS:example.com,DNS:www.example.com" pour les noms, et -utf8 pour qu'un nom accentué survive. -nodes laisse la clé non chiffrée : OpenSSL 3 préfère la nouvelle écriture -noenc mais accepte toujours -nodes, qui est la seule écriture que connaisse le LibreSSL intégré à macOS. Ce LibreSSL ne peut pas créer de clé Ed25519 du tout ; utilisez OpenSSL 1.1.1 ou une version ultérieure pour en créer une.

Pour vérifier ce que vous avez créé : openssl req -in example.com.csr -text -verify -noout affiche chaque champ et vérifie l'auto-signature, en s'arrêtant avant d'afficher quoi que ce soit si la signature échoue. Pour confirmer que la clé appartient à la demande, comparez openssl req -in example.com.csr -pubkey -noout avec openssl pkey -in example.com.key -pubout. Aucune norme n'attribue d'extension de fichier à un CSR : .csr, .pem, .req et .txt sont donc tous corrects.