Passage de notre AC à Let’s Encrypt (pannes possibles)
Nous vous écrivons au sujet d’un problème récent survenu à la suite de notre passage des certificats
SSL de GoDaddy à ceux de Let’s Encrypt. Un petit nombre de nos clients ont signalé une erreur
CERT_HAS_EXPIRED lors du lancement d’Assemblies depuis des systèmes clients anciens. Ce message
suggère que le système du client considère le certificat SSL de notre serveur comme expiré, ce qui
empêche la connexion.
Face à ces problèmes, nous souhaitons présenter un bref bilan de ce qui s’est passé, de ses causes et des mesures que nous prenons pour éviter de tels incidents à l’avenir.
-
Ce qui s’est passé
Le 3 juillet, nous sommes passés de GoDaddy à Let’s Encrypt pour nos certificats SSL. Le 4 juillet, deux clients ont commencé à signaler une erreur
CERT_HAS_EXPIREDlors de la création d’Assemblies. -
Cause profonde
Après investigation, nous avons compris que ce problème était lié à un cas connu de dépréciation chez Let’s Encrypt en septembre 2021 (voir l’avis d’expiration de DST Root CA X3 pour plus d’informations). En substance, certains systèmes n’ont pas mis à jour leur magasin de certificats de confiance (un ensemble stocké de certificats de confiance) pour y inclure le nouveau certificat racine de Let’s Encrypt et continuent de s’appuyer sur un certificat racine expiré. Cette situation peut notamment se produire sur des systèmes de production anciens ou rarement mis à jour. Dans les deux cas signalés, il s’agissait de conteneurs Docker qui n’avaient pas été mis à jour depuis un certain temps (par exemple :
php:7.0-apache). Il s’agit généralement de conteneurs, car si le système d’exploitation hôte n’avait pas été mis à jour, il aurait eu des problèmes pour se connecter à tout serveur utilisant Let’s Encrypt. Les administrateurs l’auraient donc probablement déjà remarqué plus tôt. Vous pourriez désormais rencontrer des problèmes avec des conteneurs Docker conçus pour cet usage, utilisés uniquement pour se connecter à Transloadit et qui n’ont pas été mis à jour depuis plusieurs années. -
Pourquoi nous ne l’avons pas détecté
Lors de notre migration et de nos tests, nous n’avons pas pris en compte l’impact potentiel sur les systèmes anciens qui s’appuient encore sur le certificat déprécié DST Root CA X3. Nous regrettons profondément cet oubli.
-
Mesures à venir
- Communication : À l’avenir, nous nous engageons à informer les clients bien à l’avance de tout changement susceptible d’affecter votre service, afin que vous puissiez vous préparer et effectuer les ajustements nécessaires.
- Tests approfondis : Nous élargirons nos procédures de test pour prendre en compte le plus large éventail possible de situations rencontrées par les utilisateurs, y compris les systèmes qui ne sont pas à jour.
- Assistance : Nous continuerons à proposer une assistance et des solutions aux personnes touchées par ce changement, en vous accompagnant dans la mise à jour de vos magasins de certificats de confiance si nécessaire.
Nous recommandons aux personnes concernées de mettre à jour le magasin de certificats de confiance de leur système pour y inclure le nouveau certificat racine de Let’s Encrypt. Il suffit généralement de mettre à jour le système d’exploitation (du conteneur) ou les paquets logiciels concernés. Nous comprenons que cette solution puisse ne pas convenir à tous les clients et nous sommes là pour vous conseiller et vous aider. Veuillez contacter l’assistance si vous êtes concernés.
Chez Transloadit, nous tenons beaucoup à préserver la rétrocompatibilité et proposons généralement des avis préalables ainsi que des parcours de mise à niveau en douceur pour l’ensemble de nos services. Dans ce cas, en tant que fondateur, j’ai personnellement supervisé l’assurance qualité et le déploiement progressif, et j’ai estimé que le changement était sans risque. Je me suis trompé et je vous présente mes excuses pour cette erreur et les problèmes occasionnés.
Nous continuerons à travailler sans relâche pour assurer un service sûr et fiable à tous nos clients.