Måndag morgon i tyska läkarmottagningar och apotek
Sedan måndag 12 oktober har många läkarmottagningar, apotek och kliniker i Tyskland haft svårt att nå Telematikinfrastruktur, det nationella hälsonätet, och Gematik rapporterar störningar för leverantörer vars konnektorer kommer från Secunet eller RISE. Tjänsterna som slutar fungera eller bara fungerar delvis är kontrollen av försäkrades basdata (VSDM), säker meddelandehantering (KIM), e-recept, den elektroniska patientjournalen och elektroniska sjukintyg.
Konnektorer från CGM är inte drabbade, säger Gematik, eftersom CGM inte använder den aktuella funktionen. Orsaken är det planerade bytet av DNS-rotnyckeln.
Gematik räknar med att alla Secunet- och RISE-konnektorer i drift drabbas under veckan om det inte kommer en rättelse, och verksamheter utan egen konnektor kan träffas om de ansluter via en datacenterkonnektor. Gematik kan ännu inte säga hur många konnektorer som är drabbade.
En kalender som var offentlig i 21 månader
Nyckelbytet stod i den offentliga kalendern i 21 månader, och den första arbetsdagen efter gav ändå ett avbrott.
| Datum | Händelse |
|---|---|
| 11 januari 2025 | Den nya rotnyckeln KSK-2024 (nyckeltagg 38696) publiceras i rotens DNSKEY-uppsättning |
| 11 augusti 2026 | ICANN publicerar vägledning om vad man kan förvänta sig under bytet |
| 6 oktober 2026 | Cloudflare varnar för att validerande resolvers måste lita på den nya nyckeln |
| 11 oktober 2026 | KSK-2024 börjar signera rotens DNSKEY-uppsättning och KSK-2017 (nyckeltagg 20326) slutar |
| 12 oktober 2026 | Gematik rapporterar störningar för Secunet- och RISE-konnektorer |
| 13 oktober 2026 | heise uppdaterar sin rapport med Gematiks svar |
ICANN:s vägledning bad operatörer av DNSSEC-validerande resolvers, leverantörer av DNS-programvara och alla med manuellt inställda förtroendeankare att bekräfta att deras system var redo före 11 oktober. Cloudflare tillade att en validerande resolver som inte litar på den nya nyckeln kan göra friska webbplatser onåbara, och att roten bara en gång tidigare hade bytt sin nyckelsigneringsnyckel.
Varför befintliga tunnlar överlevde och nya misslyckas
De drabbade konnektorerna saknar uppenbarligen det nya förtroendeankaret för internets rot, så de kan inte slå upp adresserna till VPN-åtkomsttjänsterna från Arvato och T-Systems och kan inte bygga en ny tunnel till hälsonätet.
Tunnlar som redan är uppe behöver inga nya namnuppslag och fortsätter därför att fungera. DNSKEY-posterna från roten ligger dessutom kvar i cachen i 48 timmar, vilket döljer felet tills en omstart eller återanslutning hittar en tom eller utgången cache. Därför rapporterar heise att drabbade operatörer inte bör starta om sina konnektorer.
Gematik beskriver en tillfällig lösning som den lokala tjänsteleverantören måste lägga in för hand, och guiden för Secunet-konnektorer rekommenderar att det nya förtroendeankaret läggs till även i konnektorer som fortfarande fungerar. För RISE finns ännu ingen separat guide, och RISE aviserade från 8 oktober firmware 6.2.3 med vad det kallade en viktig rättelse, men det är okänt om den åtgärdar felet. Varför konnektorerna inte tog över den nya nyckeln är fortfarande oklart: specifikationen kräver automatiska RFC 5011-uppdateringar för hälsonätets eget ankare, men det är inte klart att internetankaret får dem.
Prejudikatet från maj 2020
I slutet av maj 2020 kunde ungefär 80 000 av cirka 130 000 anslutna mottagningar och kliniker inte nå vissa av hälsonätets tjänster, och de drabbade konnektorerna kom från T-Systems, RISE och Secunet.
Gematik skyllde först på en felaktig post i sin lista över betrodda tjänsters status. Tidskriften c't kopplade senare avbrottet till ett nytt DNSSEC-rotförtroendeankare som sattes i maj 2020, i kombination med ett administrationsfel. I mitten av juni 2020 var synkroniseringen av basdata fortfarande störd hos mer än 40 000 mottagningar, och återhämtningen krävde uppdateringar på plats av tjänsteleverantörer eftersom fjärrunderhåll ofta inte var godkänt.
Vad du bör fråga leverantörerna före nästa rotbyte
Börja med varje enhet som bygger VPN-tunnlar eller själv validerar DNS, till exempel gateways, medicinska konnektorer och inbyggda enheter. Be varje leverantör bekräfta skriftligt hur dess förtroendeankare uppdateras, med RFC 5011 eller för hand, och om den redan känner till KSK-2024.
Testa en omstart eller återanslutning i ett underhållsfönster först efter den bekräftelsen och ha leverantörens manuella lösning redo. Cloudflare erbjuder ett beredskapstest baserat på RFC 8509 för den resolver som din webbläsare använder, och säger att de flesta webbplatsägare inte behöver göra något.
Lägg rotnyckelbyten och certifikatutgångar i samma ändringskalender som programvaruversioner. Det här avbrottet hade ett datum, en offentlig nyckel och en publicerad guide, och felet syntes först när datumet hade passerat.
Läs vidare: Yandex Cloud rådde kunder att hosta någon annanstans | Tre Windows-supportdatum inom 30 dagar
