strongSwan : type de clé, chargeur et mauvais backend

Les extensions de fichier n’identifient pas les algorithmes de clé, et une enveloppe .pem peut contenir du matériel RSA ou ECDSA. PEM décrit comment les octets sont emballés, tandis que RSA et ECDSA nomment des algorithmes différents, et un fichier PKCS12 est encore autre chose. strongSwan charge les identifiants via des plugins et un backend de configuration, si bien qu’un certificat peut apparaître dans une liste alors que la clé privée ne devient jamais utilisable. Séparez ces couches avant de modifier le moindre secret.

Encodage, algorithme et empaquetage sont trois couches

Un fichier de clé a un encodage, un algorithme et souvent un conteneur. PEM est l’enveloppe base64 familière ; DER en est la contrepartie binaire ; PKCS12 regroupe un certificat avec sa clé et sa chaîne. Un fichier de chaîne de certificats est encore un autre conteneur, et il ne contient généralement aucune clé privée. Aucune de ces étiquettes ne dit si le matériel à l’intérieur est RSA ou ECDSA.

Lisez l’algorithme dans l’objet lui-même. Le nom commercial d’un fournisseur ou une extension de fichier ne sont pas des preuves, car le même émetteur peut délivrer différents types de clés.

Comparez les clés publiques avant d’accuser le chargeur

Un certificat qui se charge prouve que le certificat a été analysé, pas que sa clé privée soit présente ou utilisable. Dérivez la clé publique du certificat et de la clé privée proposée, puis comparez les deux empreintes. Si l’une des extractions échoue, arrêtez-vous là, car l’empreinte d’une sortie vide ne prouve rien. Des empreintes identiques prouvent que la paire va ensemble, et rien de plus sur l’adéquation du certificat à la tâche.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

La seconde commande touche du matériel privé sur votre machine mais n’émet que la moitié publique. Gardez-le ainsi, et ne collez jamais une clé privée dans un ticket. Si la clé est chiffrée, laissez l’outil pris en charge demander la phrase de passe au lieu de la placer sur une ligne de commande où la liste des processus peut l’exposer.

ipsec.secrets hérité ou identifiants swanctl

strongSwan a deux chemins d’identifiants couramment utilisés. L’ancienne pile starter lit les entrées propres au type depuis ipsec.secrets, et chaque entrée doit nommer le type correct pour le matériel. La pile swanctl et vici charge les clés depuis son propre répertoire d’identifiants via sa propre configuration. Modifier le fichier que le backend en cours d’exécution ne lit pas ne change rien.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Déterminez quel backend tourne réellement, puis placez la clé là où ce backend regarde. manuel hérité strongSwan 5.9 définit les entrées de secrets propres au type, et ce n’est pas la documentation de swanctl. Mélanger les deux produit un démon qui ignore un fichier que l’administrateur croit faire autorité. Un rechargement qui ne signale aucune erreur signifie seulement que la configuration a été analysée.

Lisez l’événement de chargement et le résultat d’authentification

Après un rechargement contrôlé, lisez la sortie de chargement du démon lui-même pour la clé concernée. Un certificat listé dans un vidage d’état ne montre pas que la clé privée lui a été associée.

Si un client échoue encore, gardez séparés l’événement serveur et l’erreur client. La validation de chaîne, la correspondance d’identité et la compatibilité des méthodes sont des questions ultérieures avec leurs propres preuves. Notez le résultat avec le chemin exact de la clé et l’empreinte que vous avez comparée, car la relève suivante répétera sinon le même rechargement. Remplacer l’AC n’est pas la première réponse à une incohérence de chargeur.