Où vivent n, e, d, p et q de RSA dans un fichier de clé VPN

Les lettres d’une explication RSA nomment des champs à l’intérieur d’un objet, pas des fichiers qu’un outil PKI distribue. Un fichier de clé privée contient une structure dont les premiers champs sont publics et dont les champs suivants ne doivent jamais quitter la machine qui termine le tunnel. Entre ces deux faits se trouvent la plupart des questions pratiques sur le fichier qui répond à quelle question. Ce guide lit d’abord la structure, puis les commandes qui l’inspectent sans la déverser.

Confirmez que la clé est RSA avant de chercher des nombres premiers

Un certificat prouve qu’une clé existe et a été signée ; il ne prouve pas que la clé est RSA. Les systèmes peuvent reposer sur des courbes elliptiques ou Ed25519, et la même disposition de répertoires les sert tous. Vérifiez l’algorithme avant de chercher des facteurs premiers qui n’ont jamais été là.

Ces trois commandes en lecture seule répondent à la question et enregistrent la version de l’outil.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

La version compte parce que les noms d’options ont bougé entre versions majeures. Dans la sortie du certificat, trouvez la ligne de l’algorithme de clé publique et la taille de la clé ; dans la sortie de la clé, une clé RSA imprime un module et un exposant public. Une clé de courbe elliptique imprime à la place une courbe nommée, et aucune recherche n’en tirera n ni q.

Lisez la structure plutôt que le base64

PEM est du base64 enveloppé dans des lignes d’en-tête, et le décoder donne du DER, c’est-à-dire une structure sérialisée et non un seul entier énorme. Les clés privées RSA voyagent dans deux conteneurs courants, PKCS#1 et PKCS#8, et les deux se résolvent au même ensemble de nombres.

Dans le cas de deux nombres premiers, la structure privée porte neuf champs : une version, le module n, l’exposant public e, l’exposant privé d, les nombres premiers p et q, deux exposants CRT et un coefficient CRT. RFC 8017 section A.1 définit ces composants et la disposition ASN.1, et il autorise aussi plus de deux nombres premiers, ce qui explique qu’un analyseur général puisse imprimer des entrées premières supplémentaires. Remarquez l’ordre, car il explique une erreur fréquente : la moitié publique est stockée dans le fichier privé, donc la présence d’un champ public ne rend pas ce fichier sûr à partager. Tout ce qui suit est la matière qui doit rester sur l’hôte.

L’encodage ajoute une couche facile à confondre avec le contenu. openssl asn1parse dessine la structure comme un arbre pour que l’ordre des champs devienne visible, et il ne déchiffre rien ni ne dit si la clé est utilisable.

Associez un certificat à une clé sans imprimer la clé

La question qui suit est généralement de savoir si un certificat et une clé vont ensemble. Comparer les modules y répond, mais copie aussi de la matière proche du privé dans une transcription de terminal qui peut finir dans un ticket. Comparer les moitiés publiques répond à la même question sans rien de sensible à l’écran.

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

Des fichiers identiques signifient que le certificat porte la moitié publique de cette clé, et une différence signifie que vous tenez la mauvaise paire. Cet écart est la cause la plus fréquente d’un tunnel qui négocie allègrement puis refuse l’authentification. Retirez ensuite les deux fichiers temporaires ; ils ne contiennent rien de secret, mais un répertoire de travail propre se raisonne plus facilement au milieu d’un incident.

Sachez ce que les fichiers voisins ne sont pas

Un certificat n’est pas une clé publique chiffrée que le pair déverrouille avec le certificat de la CA ; c’est une liaison signée entre une clé publique et des données d’identité. La clé de signature privée de la CA reste séparée de son propre certificat et de chaque clé client. Une demande n’est pas un certificat non plus : elle porte les informations demandées et la clé publique avec une signature sur la demande, ce qui en fait une entrée d’enrôlement plutôt qu’une preuve de droit.

Deux de ces entrées se confondent assez souvent avec les paramètres RSA pour qu’on les nomme deux fois. Un fichier de paramètres Diffie-Hellman contient des paramètres de groupe pour l’établissement de clé et aucun nombre premier RSA, bien qu’il s’imprime aussi comme un grand premier. Une liste de révocation publie l’état des certificats et n’est pas un endroit où un exposant privé pourrait se cacher.

Chaque ligne d’inventaire devrait donc consigner quatre choses : le type d’objet, le propriétaire, l’usage et si de la matière privée est incluse. La dernière colonne décide où le fichier peut être copié, et c’est celle que les gens sautent.

Enregistrez l’appariement, puis vérifiez la poignée de main

Avant de changer quoi que ce soit, enregistrez la sortie de vérification avec la date et la version d’OpenSSL. Une rotation ultérieure peut alors être comparée à des preuves plutôt qu’à la mémoire.

openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates

Après la comparaison de la clé publique, exercez le chemin qui consomme la paire : montez le tunnel, confirmez que le certificat est présenté et accepté, et vérifiez quelle identité la passerelle a consignée. Si la clé et le certificat correspondent et que l’authentification échoue encore, la faute est dans la confiance, le mappage d’identité ou la politique d’accès, pas dans l’appariement.

Pour un retour arrière, gardez la clé et le certificat précédents dans un répertoire daté et restaurez les deux ensemble, jamais l’un des deux. Une clé sans son certificat et un certificat sans sa clé échouent à l’identique de l’extérieur, ce qui rend les paires à moitié restaurées coûteuses à démêler à deux heures du matin.