Générateur de clés RSA
Générez une nouvelle paire de clés RSA avec un module de 2048 ou 3072 bits et l’exposant public 65537. Vous obtenez la clé privée au format PEM PKCS #8 non chiffré, la clé publique au format PEM SPKI, la ligne OpenSSH ssh-rsa correspondante avec son empreinte SHA-256, les algorithmes RS et PS qu’elle peut signer ainsi que l’empreinte JWK RFC 7638 à utiliser comme identifiant de clé. Chaque paire est créée avec le module crypto de Node pour cette requête et n’est jamais enregistrée.
Foire aux questions
Dois-je choisir 2048 ou 3072 bits ?
Le RSA 2048 bits reste le minimum courant et est accepté partout, y compris par les bibliothèques JWT qui refusent les clés plus petites. 3072 bits correspond au niveau de sécurité de 128 bits recommandé par NIST SP 800-57 au-delà de 2030, au prix de signatures plus volumineuses et d’une signature plus lente. Les tailles supérieures, comme 4096 bits, ne sont pas proposées, car leur génération prend un temps imprévisible sur un serveur partagé.
Quels formats le résultat utilise-t-il ?
La clé privée est encodée en PEM PKCS #8 (BEGIN PRIVATE KEY) et la clé publique en PEM SubjectPublicKeyInfo (BEGIN PUBLIC KEY). OpenSSL, Java, .NET, Go, Node, jose et la plupart des autres bibliothèques peuvent lire les deux. La ligne de clé publique OpenSSH est également fournie pour les fichiers authorized_keys.
La clé privée est-elle chiffrée ?
Non, la clé privée est renvoyée sans phrase secrète afin de pouvoir être directement collée dans d’autres outils. Pour la protéger au repos, exécutez openssl pkey -in key.pem -aes256 -out key-encrypted.pem et ne conservez que le fichier chiffré. Gardez la copie non chiffrée hors du contrôle de version.
Comment obtenir le format PKCS #1 (BEGIN RSA PRIVATE KEY) ?
Certains logiciels plus anciens attendent la forme traditionnelle PKCS #1. Avec OpenSSL 3, exécutez openssl pkey -in key.pem -traditional -out key-rsa.pem pour convertir le fichier PKCS #8. Le matériel de la clé reste identique ; seul l’encapsulation change.
Puis-je utiliser la clé pour SSH ?
Oui. Placez la ligne ssh-rsa dans ~/.ssh/authorized_keys sur le serveur et enregistrez la clé privée PEM comme fichier d’identité avec les permissions 600, car OpenSSH lit les clés RSA encodées en PEM. De nombreux serveurs préfèrent désormais les clés Ed25519, que le générateur de clés Ed25519 crée.
Qu’est-ce que l’empreinte JWK ?
Il s’agit du hachage SHA-256 7638 des membres JWK requis de la clé publique, encodé en base64url. Il identifie la clé indépendamment de son format, ce qui en fait une bonne valeur kid pour les JWT et les documents JWKS. Le convertisseur JWK affiche la même valeur pour cette clé.
Quels algorithmes JWT cette clé peut-elle signer ?
Une clé RSA peut signer RS256, RS384 et RS512 (PKCS #1 v1.5), ainsi que PS256, PS384 et PS512 (RSA-PSS). Utilisez la clé privée PEM avec le générateur JWT et fournissez aux vérificateurs la clé publique PEM ou son JWK. L’algorithme est une propriété de la signature : une même clé peut donc en prendre en charge plusieurs.
La clé générée est-elle enregistrée quelque part ?
Non. La paire de clés est créée en mémoire pour votre requête, renvoyée une seule fois dans le résultat et jamais consignée ni enregistrée. Si vous la perdez, générez une nouvelle paire, car personne ne peut la récupérer pour vous.
À quoi sert l’option de commentaire ?
Le commentaire est ajouté à la ligne de clé publique OpenSSH, généralement sous la forme user@host ou d’une étiquette comme deploy-2026, afin que vous puissiez reconnaître la clé dans authorized_keys. Il ne modifie ni la clé ni ses empreintes. Les commentaires sont limités à 200 caractères et les espaces successifs sont réduits à un seul espace.
À quel point les clés sont-elles aléatoires ?
Les nombres premiers proviennent du générateur aléatoire cryptographiquement sécurisé du système d’exploitation, via OpenSSL, la même source que celle utilisée par les serveurs pour leurs propres clés. Chaque requête produit une nouvelle paire de clés indépendante. L’exposant public est toujours 65537, la valeur standard.