Avant de le convertir : clé SSH ou certificat OpenVPN

L’import échoue avec une erreur de certificat, alors le geste évident ressemble à une conversion. Cet instinct mène les gens sur une voie où l’extension du fichier change et où le rejet reste exactement le même. Une ligne ssh-ed25519 dans authorized_keys et un certificat client OpenVPN sont des objets d’identification distincts, avec des émetteurs différents, des encodages différents et des chemins de révocation différents. Passer ces contrôles dans l’ordre vous dit en une minute si une conversion peut aider, ne serait-ce qu’un peu.

Quel objet détenez-vous réellement ?

Il y a cinq choses que les gens appellent une clé, et une seule d’entre elles est ce qu’un profil TLS attend. Une clé publique SSH est une seule ligne de texte avec un préfixe de type et une charge base64. Un certificat OpenSSH est cette clé plus une signature, des principals et des options, produits par ssh-keygen agissant comme sa propre petite CA. Un certificat X.509 est une structure entièrement différente, qui porte un sujet, une fenêtre de validité, des extensions et une signature d’une autorité de certification. Une clé privée est la moitié secrète, et un lot émis est généralement un certificat plus sa chaîne plus la clé privée dans un seul fichier.

Le premier test coûte une commande. Pointez openssl sur le fichier et demandez-lui d’analyser la structure du certificat :

openssl x509 -in client.crt -noout -subject -issuer

Si cela échoue avec une erreur de chargement impossible ou PEM, le fichier n’est pas un certificat X.509 quel que soit le nom que vous lui avez donné. Un renommage ne réécrit pas l’ASN.1 à l’intérieur, et envelopper une ligne de clé publique dans un en-tête PEM ne le fait pas davantage.

Le profil demande-t-il seulement un certificat ?

Les certificats clients sont une méthode d’authentification parmi plusieurs, et beaucoup de profils TLS qui fonctionnent n’en demandent jamais. Un serveur peut authentifier les utilisateurs via un greffon, un nom d’utilisateur et un mot de passe, ou un backend à jetons, tout en exigeant du client qu’il vérifie l’identité du serveur. Si le profil ne porte aucune directive de certificat client, aucun certificat ne sera jamais demandé, et aucune conversion ne fera demander un certificat à la passerelle.

Les anciennes configurations à clé statique sont un troisième cas. Elles précèdent la poignée de main TLS et attendent un fichier de secret pré-partagé, ce qui explique pourquoi coller une clé publique dans ce champ ne peut pas fonctionner non plus. Lisez ce que le profil demande réellement avant de conclure que l’identifiant est incorrect.

Ce que le réencodage peut et ne peut pas faire

Les clés privées ont bel et bien des conteneurs alternatifs légitimes. La même clé RSA ou EC peut être écrite en PEM traditionnel, en PKCS#8, ou dans un lot PKCS#12, et les outils convertissent volontiers entre eux. Les clés publiques ont une histoire similaire : ssh-keygen peut produire la forme RFC 4716 d’une clé SSH, et OpenSSH comprend aussi son propre format de certificat. Tout cela est de la représentation, et la représentation n’est pas la confiance.

Ce qu’une conversion ne peut pas faire, c’est créer une signature d’une autorité de certification qui n’a jamais vu votre clé. Un certificat est une assertion d’un émetteur selon laquelle une clé publique donnée appartient à un sujet donné pour un usage donné. Le réencodage conserve les octets de la clé et laisse l’assertion absente, si bien que la passerelle n’a rien à valider contre son magasin de confiance.

C’est l’étape où la plupart des tentatives échouent en silence : le fichier se termine désormais par .crt, le client le lit sans se plaindre, et la poignée de main avorte quand même parce que le pair ne peut pas construire de chaîne vers un émetteur de confiance.

Où l’autorité de certification entre en jeu

Une véritable inscription commence par une paire de clés que vous contrôlez et une demande de signature de certificat qui porte le sujet attendu par l’opérateur. L’opérateur vérifie le droit, signe la demande avec la clé de la CA et renvoie le certificat émis avec toute chaîne intermédiaire que le client doit présenter. Le client a ensuite besoin du certificat de la CA qui l’a signé, car c’est lui qui permet de confirmer que le serveur auquel il parle appartient au même déploiement.

Ce dernier fichier est facile à oublier et impossible à substituer. La clé de signature de la CA elle-même n’appartient jamais à la configuration du client, et aucune conversion locale ne produit la chaîne que vous étiez censé recevoir.

Ce que vous coûte la réutilisation de la clé SSH

Supposons qu’une conversion ait effectivement produit quelque chose d’acceptable. Réutiliser une même paire de clés pour l’accès SSH et l’authentification VPN couple encore deux décisions de sécurité indépendantes. Supprimer une entrée d’authorized_keys arrête les connexions SSH, et cela ne fait rien à un certificat que la CA du VPN a déjà émis pour la même clé publique. Le côté VPN se révoque par son propre mécanisme, c’est-à-dire la liste de révocation des certificats ou le registre d’inscription de l’opérateur.

La liste de contrôle se termine donc par une condition d’arrêt plutôt que par une astuce. Si openssl n’analyse pas le fichier comme un certificat, arrêtez la conversion et décrivez ce que vous avez : clé SSH, certificat SSH, certificat X.509, clé privée ou lot. Si le profil ne demande pas de certificat client, arrêtez-vous et demandez quelle méthode d’authentification le serveur attend. Ce n’est que lorsque les deux réponses pointent vers X.509 que l’inscription devient l’étape suivante, et cette conversation va bien plus vite avec le bon nom dans la première phrase.