Même nom de fichier ca.crt, certificat différent : que comparer

Deux profils fournissent tous deux un fichier nommé ca.crt, un tunnel monte et l’autre échoue avec une erreur de chaîne. Ouvrir les deux fichiers côte à côte tranche rarement la question, et désactiver la vérification la tranche dans la mauvaise direction. La question que l’erreur pose réellement est plus étroite : quel certificat chaque processus charge-t-il comme ancre de confiance, et les deux sont-ils le même objet ? Répondez d’abord à cela et le reste du diagnostic prend une direction. Le nom du fichier est une étiquette d’emballage, et le chemin écrit dans le profil n’est pas non plus faisant autorité, donc tout dépend de ce que le processus lit réellement.

Trouvez le certificat que le client charge réellement

OpenVPN accepte l’autorité sous deux formes, et la forme décide quels octets comptent. Un profil peut pointer vers un fichier externe avec ca, ou intégrer le certificat dans un bloc <ca> au sein du profil lui-même. Quand les deux existent, le bloc intégré gagne et le fichier à côté du profil n’est jamais ouvert.

Lisez le profil qui échoue et déterminez quelle forme il utilise avant de comparer quoi que ce soit. Une copie prise dans un répertoire voisin, ou dans le paquet d’où vient l’autre profil, ne vous dit rien sur ce à quoi ce processus fait confiance. Il en va de même pour le chemin dans la configuration : il se résout par rapport à l’endroit où le client a été lancé, qui n’est pas toujours le répertoire que vous regardez. Lisez le profil, pas le dossier.

Les certificats s’identifient par leur contenu : la clé publique, le sujet et l’émetteur, la fenêtre de validité et la signature sur tout cela. Deux fichiers aux octets identiques sont le même certificat quels que soient leurs noms, et deux fichiers du même nom peuvent être des autorités sans rapport. Le nom est une étiquette d’emballage, pas une identité.

Empreintez les deux copies avec openssl

Une empreinte est un hachage sur l’encodage DER du certificat, la forme que couvre la signature, donc les fins de ligne et le texte d’en-tête ne peuvent pas l’affecter. Calculez-la pour chaque fichier et vous avez deux chaînes hexadécimales séparées par des deux-points qui soit correspondent, soit non. Rien d’autre dans le certificat n’a besoin d’être lu pour répondre à la question de la comparaison.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Il est tentant de pointer openssl vers le profil lui-même, mais il lit le premier bloc de certificat qui apparaît dans le fichier, et un profil porte généralement <cert> avant <ca>. Extrayez le bloc d’autorité, puis empreintez le fichier extrait, car c’est la copie que le client utilisera réellement.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Des empreintes identiques signifient que le matériel de confiance est le même et que l’erreur de chaîne a une autre cause, ce qui est une autre enquête. Des empreintes différentes signifient des certificats différents, et c’est là que commence la section suivante.

Lisez un écart avant de supposer une attaque

Des empreintes différentes signifient des certificats différents et rien de plus. Une réémission, une rotation, une autorité renommée ou un lot périmé produisent tous des fichiers différents avec des histoires parfaitement légitimes. Lequel appartient au déploiement est une question pour l’opérateur ou pour le registre de déploiement, pas pour l’heure de modification du fichier. Les archives copient les horodatages, donc un fichier plus récent n’est pas automatiquement la bonne ancre.

Une racine qui se signe elle-même est normale, donc en trouver une n’est pas une preuve de problème. Le travail du vérificateur est de construire un chemin du certificat du serveur jusqu’à l’ancre qui lui a été remise, et une erreur de chaîne signifie généralement que ce chemin n’a pas pu être complété.

Vérifiez si l’ancre du profil qui échoue est une autorité dont le déploiement émet encore. Si l’empreinte ne correspond à rien dans le registre de déploiement, le profil est simplement périmé, et aucun réglage côté client ne corrigera cela.

Réparez la confiance sans désactiver la vérification

Le correctif à court terme est de désactiver la vérification ou d’ajouter chaque certificat de la chaîne comme ancre. Les deux font disparaître le message, et les deux changent quels serveurs le client acceptera désormais. Réactivez la vérification, installez l’ancre prévue et retestez.

Si la chaîne se construit maintenant mais qu’une autre erreur apparaît, c’est un progrès : la vérification du nom, les dates de validité et la révocation sont des contrôles distincts avec des messages distincts. Gardez la paire d’empreintes et le texte d’erreur d’origine ensemble dans le ticket, afin que la personne suivante voie quelle ancre a été chargée et laquelle était attendue. Une paire d’empreintes est assez petite pour être collée dans une note de passation, et l’occurrence suivante prend alors cinq minutes au lieu d’un après-midi.

Obtenez l’autorité correcte par le même canal authentifié que celui qui a livré le profil. Retirer un certificat du serveur parce que son sujet semble familier est un autre acte, et cela élargit discrètement ce à quoi le client fera confiance.