ca md too weak : réémettre le certificat ou baisser le niveau ?

Un OpenVPN qui fonctionnait le mois dernier échoue maintenant au démarrage avec ca md too weak, et le profil sur le disque est octet pour octet celui qui fonctionnait. Le message concerne la signature du certificat d'une autorité de certification, non le chiffrement des données, le condensat auth ni le mot de passe du compte. Trois conditions décident si le correctif est un nouveau matériel d'identité, une nouvelle chaîne ou un changement délibéré de politique. Traitez-les dans l'ordre, et vous éviterez l'issue habituelle où le tunnel revient en affaiblissant chaque connexion TLS de l'hôte.

Ce que l'erreur nomme réellement

OpenSSL lève cette erreur de vérification pendant qu'il construit une chaîne, lorsque le certificat agissant comme CA porte un condensat de signature que le niveau de sécurité de la bibliothèque n'accepte plus. MD5 est refusé au niveau par défaut, et SHA-1 est refusé dès que le niveau est relevé. Le condensat du certificat feuille compte ici moins que celui de l'émetteur qui le signe. La même politique peut refuser une racine qui était parfaitement ordinaire le jour de son émission.

C'est pourquoi modifier auth ou data-ciphers ne change rien à cette panne. Ces réglages régissent la protection des paquets après la poignée de main, alors que l'objet refusé est un document d'identité examiné avant qu'un tunnel existe. Un certificat peut se tenir confortablement dans sa fenêtre de validité et porter malgré tout une signature que la bibliothèque n'acceptera pas.

Gardez les contrôles séparés dans votre tête et l'erreur cesse de paraître mystérieuse. Les dates de validité, l'usage de la clé et le condensat de signature sont des tests indépendants, et exactement l'un d'eux vient d'échouer.

Première condition : l'objet refusé est-il la racine ?

Imprimez chaque certificat du profil et lisez les champs subject et issuer. Une racine auto-signée affiche la même valeur dans les deux, et son algorithme de signature est celui sur lequel repose toute la chaîne. Quand le condensat faible s'y trouve, chaque feuille en dessous hérite du problème. Notez l'algorithme à côté du subject pour que la comparaison ultérieure soit mécanique plutôt que de mémoire.

Les fichiers CA groupés contiennent souvent plusieurs blocs : identifiez donc le bloc réellement chargé au lieu de supposer que le premier est fautif. La commande openssl x509 -in ca.pem -noout -subject -issuer -text décrit un certificat à la fois, ce qui impose de scinder le paquet d'abord s'il en contient davantage. Comparez l'algorithme de signature imprimé au condensat que vous attendriez de l'époque de création de la racine.

Une feuille signée en SHA-256 sous une racine faible échoue encore, car la vérification de chaîne remonte jusqu'en haut. C'est cet ordre qui rend la condition suivante importante.

Deuxième condition : contrôlez-vous l'émetteur ?

Si la racine appartient à votre organisation, le correctif durable est une nouvelle racine avec un condensat moderne, plus des feuilles réémises, livrées en une seule mise à jour de profil. Cela coûte une fenêtre de maintenance et un plan pour les appareils qui ne peuvent pas prendre la mise à jour le même jour.

Si un tiers a émis la chaîne, le correctif est une demande à cet opérateur, et la seule action locale utile est de cesser de dépendre de l'ancien matériel. Modifier le texte PEM ou réenregistrer le fichier ne change rien de ce que couvre la signature.

Un cas intermédiaire mérite d'être nommé : une racine interne antérieure aux valeurs par défaut actuelles mais qui signe encore du matériel auquel d'autres systèmes se fient. La remplacer suppose d'auditer chaque consommateur, y compris les équipements qui épinglent l'ancien certificat par empreinte. Comptez ces consommateurs avant de planifier le changement, car un remplacement de racine qui en oublie un échange une erreur de démarrage contre une panne.

Troisième condition : ce que la baisse du niveau accepte aussi

Baisser le niveau de sécurité, ou choisir le profil de certificats hérité d'OpenVPN, fait de nouveau accepter l'ancien condensat au client. Cela relâche aussi d'autres contrôles de la même bibliothèque, pour chaque connexion que ce processus établit.

Cela peut se défendre en laboratoire, ou comme pont court le temps de préparer le matériel de remplacement, à condition que l'exception soit limitée à un profil et porte une date de fin. Comme réglage permanent sur un hôte partagé, elle élargit silencieusement ce à quoi chaque client TLS de la machine se fiera.

Consignez l'exception avec un responsable et une étape de retrait. Un changement de niveau non documenté est indistinguable d'une erreur six mois plus tard, et l'ingénieur suivant ne saura pas que ce fut jamais une décision.

La décision, écrite comme une règle

Remplacez la chaîne quand vous contrôlez l'émetteur et pouvez énumérer ses consommateurs. Escaladez vers l'émetteur quand ce n'est pas le cas. Ne baissez le niveau que comme exception datée et délimitée, avec le remplacement déjà planifié. Tout le reste laisse le même certificat en place et déplace le risque vers un endroit moins visible.

Retestez ensuite le profil depuis un client propre, confirmez que la poignée de main aboutit, et conservez le texte exact du refus s'il échoue encore. Un message d'erreur précis est la chose la moins chère que vous puissiez remettre à qui possède la couche suivante.