Klokken er 08.15. En borger forsøger at booke tid til en pasfornyelse via kommunens selvbetjeningsportal. I stedet for bookingsystemet ser de en rød advarsel i browseren: "Din forbindelse er ikke privat" med en skræmmende fejlkode. De lukker fanen og ringer til rådhuset.
Inden middag er helpdesken oversvømmet. IT-chefen ringes op. Leverandøren kontaktes. Et certifikat udløb kl. 00.00 — og ingen opdagede det.
Det er ikke et hypotetisk scenarie. Det sker i danske kommuner hvert år.
Hvad borgeren oplever
Alle moderne browsere — Chrome, Firefox, Safari, Edge — viser en blokeringsside når de møder et udløbet TLS-certifikat. Siden er designet til at stoppe brugeren, ikke at forklare tekniske detaljer.
Browseren viser typisk ordene "Din forbindelse er ikke privat" (Chrome) eller "Advarsel: Potentiel sikkerhedsrisiko forude" (Firefox). Der er et lille link til at fortsætte alligevel, men det er skjult og forudsætter at brugeren ved hvad et certifikat er — det gør de fleste ikke.
Resultatet er at borgere der forsøger at benytte digitale selvbetjeningsløsninger — det offentlige Danmarks investering i at flytte borgerkontakt online — stopper op og vælger en analog kanal i stedet: telefon eller fremmøde.
De direkte konsekvenser for kommunen
Helpdesk-overbelastning. Borgere der møder fejl ringer til kommunen. I de første timer af en nedetid kan helpdesken modtage 5-20 gange det normale antal opkald om det berørte system, afhængigt af systemets brug.
Manglende selvbetjening. Systemer der ikke er tilgængelige betyder at borgere falder tilbage på manuelle kanaler — telefon, e-mail, fremmøde. Det sætter pres på de administrative funktioner der betjener borgerne direkte.
Tillidssvækkelse. En borger der møder en sikkerhedsadvarsel på kommunens hjemmeside vil ikke nødvendigvis forstå den tekniske årsag. Mange vil associere det med et kompromitteret system og undgå det fremover — selv efter problemet er løst.
GDPR-implikationer. Hvis den berørte tjeneste behandler personoplysninger — og det gør de fleste borgervendte systemer — er nedetid potentielt en overtrædelse af tilgængelighed som en del af informationssikkerheden under GDPR Artikel 32.
NIS2 og certifikatnedetid
Fra november 2024 er kommuner som "vigtige enheder" underlagt NIS2's hændelsesrapporteringskrav. Et certifikatudløb der forårsager nedetid på borgervendte systemer kan kvalificere som en "væsentlig hændelse" — særligt hvis det berører:
- Et "væsentligt antal" brugere (ikke defineret præcist, men tolkes bredt)
- Systemer der er kritiske for borgernes adgang til offentlige ydelser
- Systemer der behandler særlige kategorier af personoplysninger (sundhed, sociale ydelser)
En væsentlig hændelse skal rapporteres til tilsynsmyndigheder inden for 24 timer (tidlig varsel) og 72 timer (egentlig notifikation). Et certifikatudløb er en af de hændelser der potentielt udløser denne rapporteringspligt — og som er trivielt forebyggelig.
Scenariet der faktisk er det farlige
Det er ikke borgerportalen der er det farligste certifikat at miste. Det er de interne systemer.
Mange kommuner har fagsystemer — ESDH, hjemmeplejesystemer, EOJ, lønssystemer — der kræver TLS internt. Disse systemer opdager medarbejderne måske ikke er nede, fordi de tolker fejlen som et IT-problem og venter. Data lagres ikke, beslutninger udstilles, sagsbehandling stoppes op.
Internt udløbne certifikater opdages typisk langsommere end eksternt tilgængelige — fordi ingen borger ringer og fortæller det.
Hvad der er nødvendigt for at undgå det
Løsningen er enkel at beskrive og sværere at implementere manuelt: et komplet register over alle certifikater med udløbsdatoer, koblet til en alarmering der varsler i god tid.
I kommunal kontekst er "god tid" ikke 30 dage — det er 60-90 dage. Årsagen er processerne: leverandørdialog, udbudsovervejelser ved større systemer, ændringsprocesser der kræver godkendelse. Et certifikat der udløber om 30 dage men sidder på et leverandørhosted system kan ikke altid fornys inden da.
Derudover er det afgørende at registret er komplet. De certifikater der udløber uventet er næsten altid dem ingen vidste eksisterede — et subdomæne der engang blev oprettet til et projekt, et leverandørsystem der kørte på kommunens domæne, et testmiljø der aldrig kom ned.