Comment générer une clé client VPN et soumettre une CSR à la signature

Tôt ou tard, un utilisateur VPN propose d'envoyer une clé privée par e-mail pour que l'administrateur puisse créer un certificat, et c'est précisément cette offre qu'il faut refuser. Le flux qui fonctionne garde la clé sur le client dès la première commande : le client la génère, envoie une demande de signature de certificat, l'émetteur la vérifie et l'autorise, et le certificat signé revient se placer à côté de la clé qui l'a créé. La liste de contrôle ci-dessous échoue en mode fermé à chaque étape, et c'est là tout l'intérêt, car deux des cinq étapes sont justement celles que les gens sautent quand ils sont pressés.

Étape 1 : générez la clé là où elle vivra

Générez sur la machine qui détiendra la clé, et laissez-la là. Une clé logicielle finit dans un fichier aux permissions restrictives ; une clé adossée à un matériel ou à un magasin géré ne devient jamais un fichier, et son chemin d'enrôlement est généralement un outil distinct plutôt qu'une commande OpenSSL. Dans les deux cas, personne n'a besoin de voir la moitié privée.

Le flux logiciel ressemble à ceci, la clé et la demande étant créées dans une seule session :

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

La ligne umask compte plus qu'il n'y paraît. Sans elle, la clé est écrite lisible par tous sur un système permissif par défaut, et copier le fichier plus tard propage cela. Réutiliser une clé existante est légitime lorsqu'elle est déjà protégée et conforme à votre politique ; en générer une nouvelle par appareil est plus facile à justifier.

Étape 2 : mettez l'identité dans la demande, pas dans l'e-mail

Décidez ce que le VPN authentifie réellement avant que la demande ne soit créée, car cette réponse appartient à l'intérieur de la CSR. OpenVPN associe traditionnellement l'identité du client au nom commun du certificat, et des outils comme strongSwan font correspondre une chaîne d'identité au sujet ou à un nom alternatif du sujet. Un e-mail qui dit que je m'appelle alice n'est pas une preuve, et une demande dont le sujet dit la même chose n'est que légèrement meilleure.

Ajoutez un nom alternatif du sujet lorsque votre vérificateur en contrôle un, car la correspondance moderne ignore souvent l'ancien CN :

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Gardez le CN court, stable et lié au compte plutôt qu'à un modèle d'ordinateur portable. Un nom contenant le numéro de série de l'appareil de l'utilisateur est un problème de support qui attend le premier remplacement de matériel.

Étape 3 : vérifiez la demande avant de la signer

L'émetteur vérifie deux choses différentes, et les confondre est l'erreur classique. D'abord, que la demande est cohérente en interne : la signature se vérifie contre la clé publique qu'elle porte. Ensuite, que le demandeur a droit à ce que la demande exige, et aucune vérification cryptographique ne peut répondre à cela.

La partie mécanique tient en une commande, et elle devrait afficher un résultat de vérification avec le sujet :

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Notez ce que cela prouve. Une demande qui se vérifie montre seulement que l'expéditeur détenait la clé privée correspondante au moment de la soumission ; elle ne prouve pas que l'expéditeur est la personne nommée dans le sujet, et elle n'autorise pas l'accès au groupe ou à la route demandés. La revue d'enrôlement est une porte séparée, et une demande portant sur un groupe que personne n'a approuvé devrait être rejetée plutôt que modifiée en silence.

Étape 4 : autorisez, puis signez avec des extensions explicites

La signature est le moment où l'AC décide de la politique au lieu d'accepter la demande mot pour mot. La validité, l'usage de la clé et l'extension de rôle appartiennent à un fichier d'extensions, pas à des valeurs par défaut que vous ne vous rappellerez pas six mois plus tard. Un certificat client pour l'authentification VPN a besoin de l'authentification client comme usage.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Utilisez -CAserial avec le fichier de série existant si l'un est déjà en service, et gardez la clé de l'AC hors ligne ou dans le magasin protégé que votre politique nomme. Les numéros de série des certificats doivent être uniques par émetteur ; recréer le fichier de série de zéro risque des collisions qui rendent la révocation ambiguë.

Consignez ce qui a été émis : numéro de série, sujet, identité demandée, personne approbatrice et expiration. Ce registre est ce dont dépend ensuite une décision de révocation, et il ne peut pas être reconstruit à partir du seul certificat si la trace d'enrôlement ne vit que dans une boîte aux lettres.

Étape 5 : installez-le à côté de la clé correspondante et prouvez la paire

Le client reçoit le certificat et la chaîne de l'émetteur, jamais une clé. Avant de vous connecter, confirmez que le certificat s'apparie réellement avec la clé déjà présente sur le disque, car une paire qui ne correspond pas produit un échec de poignée de main déroutant bien plus tard :

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Les deux empreintes doivent correspondre. Connectez-vous ensuite et confirmez que l'identité que le serveur journalise est celle que vous avez autorisée, et pas seulement que le tunnel s'est monté. Si la clé est perdue ou l'appareil remplacé, la réponse est la révocation plus une nouvelle demande depuis le nouvel appareil ; demander à l'administrateur de renvoyer une clé venue d'ailleurs ne récupère pas l'original et casse silencieusement le modèle qui rendait la demande sûre.