L’Effet Domino du Certificat SSL : Pourquoi renouveler ne suffit pas

Quand un simple renouvellement de certificat met à terre toute votre infrastructure. Retour d’expérience sur la gestion de la confiance dans les architectures distribuées.


C’est un classique de l’administration système : votre calendrier vous rappelle que le certificat SSL de votre serveur LDAP expire bientôt. Vous générez la nouvelle demande, vous recevez le fichier .crt, vous l’installez sur le serveur, et vous redémarrez.

Le service LDAP est vert (systemctl status : OK). Le port 636 répond. Vous pensez avoir fini.

Pourtant, quelques minutes plus tard, votre téléphone sonne : « Plus personne ne peut se connecter au Portail Applications« .

Que s’est-il passé ? Bienvenue dans le piège de la chaîne de confiance.

Le Scénario : Une Réaction en Chaîne

Prenons un exemple concret tiré d’une intervention récente sur notre infrastructure :

  1. L’Origine: Le certificat du serveur LDAP est renouvelé. Pour des raisons techniques ou de sécurité, l’autorité de certification (l’entité qui signe le certificat) change ou évolue.
  2. Le Pivot : Le serveur SSO CAS (cas.test.fr) dépend de ce LDAP pour authentifier les utilisateurs. Pour se connecter, il établit une liaison sécurisée (ldaps://).
  3. L’Impact : D’autres serveurs applicatifs dépendent eux-mêmes du CAS pour gérer les sessions utilisateurs.

Le Problème : La Confiance est une Route à Double Sens

En SSL/TLS, on se focalise souvent sur le serveur : « Est-ce qu’il présente le bon certificat ? ». Mais on oublie souvent le client : « Est-ce que le client fait confiance à celui qui a signé ce certificat ?« .

Dans notre cas, le serveur CAS agit comme un client du LDAP.

Lorsque le LDAP lui présente son tout nouveau certificat signé par, le serveur CAS consulte son carnet d’adresses interne (le Truststore ou cacerts en Java).

Si ce carnet est obsolète – parce que le serveur n’a pas été mis à jour depuis longtemps – il ne trouve pas cette nouvelle autorité.

Verdict : SunCertPathBuilderException. Java refuse la connexion par sécurité.

Conséquence : Le CAS ne démarre pas correctement (erreur 404), et par ricochet, les services qui en dépendent se retrouvent aveugles.

La Spécificité Java (Le Piège du cacerts)

Contrairement à un navigateur web (Chrome, Firefox) ou à des outils système (curl, wget) qui utilisent les magasins de certificats mis à jour automatiquement par le système d’exploitation, les applications Java utilisent souvent leur propre magasin isolé : le fichier cacerts de la JVM.

Si vous mettez à jour votre OS (Debian, RedHat), le cacerts de Java, lui, ne bouge pas forcément. Il reste figé dans le temps, ne connaissant que les autorités qui existaient lors de son installation.

Les Bonnes Pratiques pour Éviter le Crash

Pour ne plus subir cet effet domino, la gestion des certificats doit être globale :

1. Cartographier les Dépendances

Ne voyez pas vos serveurs comme des îles.

  • « Qui consomme mon service LDAP ? » -> CAS.
  • « Qui consomme mon service CAS ? » -> Applications Web.

Si vous touchez au LDAP, vous devez vérifier le CAS. Si vous touchez au certificat du CAS, vous devez aussi mettre à jour le cacerts des serveurs hébergeant vos applis Web, et ainsi de suite.

2. Mettre à Jour les Clients (Truststores)

Avant même de changer le certificat du serveur, assurez-vous que tous ses clients possèdent la chaîne de certification (Root CA et Intermediate CA) dans leur magasin de confiance.

  • Pour Java : keytool -import -keystore ...
 /usr/lib/jvm/java-11-oracle/bin/keytool -import \
    -alias "geant-harica-2025" \
    -keystore /usr/lib/jvm/java-11-oracle/lib/security/cacerts \
    -storepass changeit \
    -file ldap_chain_2.crt \
    -noprompt
  • Pour Linux : update-ca-certificates

3. Automatiser

La gestion manuelle des cacerts est sujette à l’oubli. Utilisez des outils comme Ansible pour déployer systématiquement les nouveaux certificats racines sur l’ensemble de votre parc de serveurs (y compris les JVMs).


En résumé : Un certificat SSL n’est pas juste un fichier sur un serveur. C’est une relation de confiance. Et comme dans toute relation, il faut que les deux parties soient d’accord pour que ça fonctionne.