De fleste certifikatudløb der forårsager nedbrud sker ikke fordi ingen satte en alarm op. De sker fordi alarmen nåede den forkerte person, forsvandt i en fælles postboks ingen tjekker, eller fordi den person der sad med ansvaret ikke var tilgængelig da alarmen kom.
Alarmopsætning er ikke en teknisk udfordring. Det er en organisatorisk udfordring med tekniske konsekvenser.
Hvorfor e-mail-remindere og kalenderalarmer fejler
Fælles postbokse uden ejerskab. Alarmen sendes til it@virksomhed.dk. Alle forventer at nogen anden håndterer det. Ingen gør det.
Personbundne remindere. En kalenderalarm er sat op af den person der installerede certifikatet. Den person skifter job. Reminderen eksisterer stadig i den gamle kalender. Ingen ved det.
For sen første alarm. Et certifikat med 90 dages levetid og én alarm ved 14 dage er under pres. Med 47-dages certifikater (fra 2029) er en enkelt alarm ved 14 dage uacceptabel — der er ingen buffer.
Ingen eskalering. Alarmen sendes, modtageren er syg eller på ferie. Ingen backup-modtager. Certifikatet udløber.
Kontekstfri alarmer. Emailen siger "certifikat udløber om 7 dage." Hvem skal gøre hvad? Ikke klart. Handlingen forsinkes.
Anbefalet alarmstrategi: tærskler og eskalering
En effektiv alarmstrategi har tre lag:
Lag 1: Tidlig advarsel (60 eller 30 dage)
Første alarm er orienterende — "vi skal handle inden for en måned." Sendes til certifikatejeren og backup-personen. Ingen eskalering endnu, men det skaber synlighed tidligt.
For kritiske systemer: brug 60 dage. For standard systemer: 30 dage er tilstrækkeligt.
Lag 2: Handlingsalarm (14 dage)
Her skal fornyelsesprocessen være startet. Alarmen bør indeholde konkret information: certifikatets domæne, udstedende CA, og et direkte link til fornyelsesproceduren eller platformen.
Sendes til certifikatejeren og IT-leder / sikkerhedsleder.
Lag 3: Kritisk alarm (7 dage og 1 dag)
Eskaleringsalarm. Sendes til certifikatejeren, backup-modtageren, og ledelsesniveauet. 7-dages alarmen er "dette er en kritisk situation." 1-dages alarmen er "dette er en nødsituation."
Overvej at inkludere en webhook der poster direkte til en Slack-kanal som teamet aktivt bruger — ikke kun e-mail.
Alarmstrategi med 47-dages certifikater
Fra 2029 er de fleste TLS-certifikater 47 dage. Det ændrer alarmstrategien fundamentalt:
| Certifikatlevetid | Første alarm | Handlingsalarm | Kritisk alarm |
|---|---|---|---|
| 1 år (365 dage) | 60 dage | 30 dage | 14 og 7 dage |
| 90 dage | 30 dage | 14 dage | 7 og 1 dag |
| 47 dage (fra 2029) | 21 dage | 10 dage | 5 og 1 dag |
Alternativet til disse tætte alarmer er ACME-automation: certifikater fornyes automatisk, og alarmerne aktiveres kun hvis automationen fejler. Det er den eneste skalerbare løsning ved 47-dages certifikater.
Hvem bør modtage hvilke alarmer
Alarmmodtagere bør defineres pr. certifikat eller certifikatgruppe — ikke kun globalt:
- Primær modtager: Den tekniker eller team der er ansvarlig for certifikatets fornyelse
- Backup-modtager: Backup-person der træder til hvis primær ikke er tilgængelig
- Eskalering: IT-leder eller sikkerhedsleder ved kritiske alarmer
- Webhook: Teamets Slack/Teams-kanal til synlighed på tværs af teamet
Undgå at sende alle alarmer til alle. En postboks der modtager 50 daglige alarmer behandler dem som støj.
Hvad alarmen bør indeholde
En nyttig certifikat-udløbsalarm bør indeholde:
- Certifikatets domæne(r)
- Nøjagtig udløbsdato og tid (UTC)
- Dage til udløb
- Udstedende CA og certifikattype
- Link til fornyelse eller til platformen
- Navn på primær ansvarlig
En alarm uden kontekst forsinkker handling. En alarm med komplet kontekst giver modtageren alt de skal bruge for at handle inden for 5 minutter.
Sådan håndterer CertControl alarm-opsætning
Guiden ovenfor beskriver hvad god certifikatalarmering kræver. CertControl implementerer præcis dette:
- Konfigurerbare tærskler per certifikat. Du kan sætte forskellige advarselsintervaller for forskellige certifikater: 90 dage for leverandørcertifikater med lange fornyelsesledtider, 21 dage for ACME-automatiserede certifikater. Én global tærskel passer ikke alle situationer — CertControl er bygget til at differentiere.
- Navngivne modtagere per certifikat. Hvert certifikat i CertControl har en tildelt ejer. Advarsler routes til den specifikke person eller det team der er ansvarligt for fornyelse — ikke udsendt til alle. Backup-modtagere kan konfigureres, og webhooks sender advarsler til Slack- eller Teams-kanaler.
- Alarm-indhold med fuld kontekst. CertControls advarsler indeholder domæne, nøjagtig udløbsdato, dage til udløb, udstedende CA og link til certifikat-detaljsiden i platformen — alt hvad modtageren skal bruge for at handle med det samme.
- ACME-automatisering som alternativ til alarmtræthed. For certifikater der kan automatiseres eliminerer CertControls ACME-integration fornyelsesprocessen helt. Advarsler udløses kun hvis automatiseringen fejler — ikke ved hvert planlagte fornyelses tidspunkt. Det er den eneste skalerbare løsning ved 47-dages certifikater.
- Alarm-log til compliance. Alle advarsler logges med tidsstempel og modtager. Denne log er dokumentationen for at overvågning var aktiv — relevant for NIS2-tilsyn og ISO 27001-revisioner der beder om bevis for at alarmer faktisk udløste.