Lundi matin dans les cabinets et pharmacies allemands
Depuis le lundi 12 octobre, de nombreux cabinets médicaux, pharmacies et cliniques d'Allemagne peinent à joindre la Telematikinfrastruktur, le réseau de santé national, et la Gematik signale des perturbations pour les prestataires dont les connecteurs viennent de Secunet ou de RISE. Les services en panne ou partiellement en panne sont la vérification des données de l'assuré (VSDM), la messagerie sécurisée (KIM), les e-ordonnances, le dossier patient électronique et les arrêts maladie électroniques.
Les connecteurs de CGM ne sont pas touchés, dit la Gematik, car CGM n'utilise pas la fonction en cause. La cause est le changement programmé de la clé racine DNS.
La Gematik s'attend à ce que tous les connecteurs Secunet et RISE en service soient touchés au cours de la semaine sans correctif, et les sites sans connecteur propre peuvent l'être s'ils passent par un connecteur de centre de données. La Gematik ne peut pas encore dire combien de connecteurs sont touchés.
Un calendrier public depuis 21 mois
Le changement de clé figurait depuis 21 mois dans le calendrier public, et le premier jour ouvré suivant a quand même apporté une panne.
| Date | Événement |
|---|---|
| 11 janvier 2025 | La nouvelle clé racine KSK-2024 (key tag 38696) est publiée dans l'ensemble DNSKEY de la racine |
| 11 août 2026 | L'ICANN publie un guide sur ce qu'il faut attendre du changement |
| 6 octobre 2026 | Cloudflare avertit que les résolveurs validants doivent faire confiance à la nouvelle clé |
| 11 octobre 2026 | KSK-2024 commence à signer l'ensemble DNSKEY de la racine et KSK-2017 (key tag 20326) s'arrête |
| 12 octobre 2026 | La Gematik signale des perturbations pour les connecteurs Secunet et RISE |
| 13 octobre 2026 | heise met à jour son article avec les réponses de la Gematik |
Le guide de l'ICANN demandait aux exploitants de résolveurs validants DNSSEC, aux éditeurs de logiciels DNS et à quiconque a des ancres de confiance configurées à la main de confirmer que leurs systèmes étaient prêts avant le 11 octobre. Cloudflare a ajouté qu'un résolveur validant qui ne fait pas confiance à la nouvelle clé peut rendre inaccessibles des sites web en bonne santé, et que la racine n'avait changé sa clé de signature de clés qu'une seule fois auparavant.
Pourquoi les tunnels existants tiennent et les nouveaux échouent
Aux connecteurs touchés manque apparemment la nouvelle ancre de confiance racine d'internet, si bien qu'ils ne peuvent pas résoudre les adresses des services d'accès VPN d'Arvato et de T-Systems ni monter un nouveau tunnel vers le réseau de santé.
Les tunnels déjà établis n'ont pas besoin de nouvelles résolutions de noms et continuent donc de fonctionner. Les enregistrements DNSKEY de la racine restent aussi 48 heures en cache, ce qui masque la panne jusqu'à un redémarrage ou une reconnexion qui trouve un cache vide ou expiré. C'est pourquoi heise rapporte que les exploitants touchés ne devraient pas redémarrer leurs connecteurs.
La Gematik décrit un contournement que le prestataire sur site doit appliquer à la main, et son guide pour les connecteurs Secunet recommande d'ajouter la nouvelle ancre de confiance même aux connecteurs qui fonctionnent encore. Pour RISE, il n'existe pas encore de guide séparé, et RISE a annoncé à partir du 8 octobre le micrologiciel 6.2.3 avec ce qu'il a qualifié de correction importante, mais on ignore si elle règle cette panne. Pourquoi les connecteurs n'ont pas repris la nouvelle clé reste flou : la spécification exige des mises à jour automatiques RFC 5011 pour l'ancre propre du réseau de santé, mais rien n'indique que l'ancre d'internet en bénéficie.
Le précédent de mai 2020
Fin mai 2020, environ 80 000 des quelque 130 000 cabinets et cliniques connectés n'ont pas pu joindre certains services du réseau de santé, et les connecteurs touchés venaient de T-Systems, de RISE et de Secunet.
La Gematik a d'abord incriminé une entrée erronée dans sa liste d'état des services de confiance. Le magazine c't a ensuite relié la panne à une nouvelle ancre de confiance racine DNSSEC posée en mai 2020, combinée à une erreur d'administration. À la mi-juin 2020, la synchronisation des données de base restait perturbée dans plus de 40 000 cabinets, et le rétablissement a exigé des mises à jour sur site par des prestataires, parce que la maintenance à distance n'était souvent pas autorisée.
Ce qu'il faut demander à vos fournisseurs avant le prochain changement de racine
Commencez par tout appareil qui monte des tunnels VPN ou valide le DNS lui-même, comme les passerelles, les connecteurs médicaux et les équipements embarqués. Demandez à chaque fournisseur de confirmer par écrit comment son ancre de confiance se met à jour, par RFC 5011 ou à la main, et s'il connaît déjà KSK-2024.
Ne testez un redémarrage ou une reconnexion dans une fenêtre de maintenance qu'après cette confirmation, et gardez sous la main le contournement manuel du fournisseur. Cloudflare propose un test de préparation fondé sur la RFC 8509 pour le résolveur qu'utilise votre navigateur, et indique que la plupart des exploitants web n'ont rien à faire.
Mettez les changements de clé racine et les expirations de certificats dans le même calendrier de changements que les versions logicielles. Cette panne avait une date, une clé publique et un guide publié, et le défaut n'est apparu qu'une fois la date passée.
À lire ensuite: Yandex Cloud invite ses clients à héberger ailleurs | Trois fins de support Windows en moins de 30 jours
