TLS overvågning er ikke det samme som at sætte en kalenderreminder om certifikatudløb. Det er løbende automatisk scanning der dækker alle de måder et TLS-certifikat og en TLS-konfiguration kan fejle — og giver dig besked i god tid inden det sker.
Denne guide forklarer hvad TLS overvågning egentlig dækker, hvilke konkrete problemer det opdager, og hvordan du opsætter det i din organisation.
Hvad TLS overvågning dækker — og hvad det ikke er
De fleste teams starter med at overvåge udløbsdatoer. Det er nødvendigt — men det er kun én dimension af TLS-risiko. Et certifikat kan teknisk set ikke være udløbet, og stadig udgøre en betydelig risiko:
- Svage cipher suites: Certifikatet er gyldigt, men serveren tilbyder RC4, 3DES eller andre kryptografisk svage algoritmer
- Forældet protokol: TLS 1.0 og TLS 1.1 er disabled i moderne browsere men kan stadig være aktiveret på serverne
- Kædefejl: Certifikatkæden er ufuldstændig — intermediate-certifikatet er ikke installeret korrekt
- OCSP-problemer: Certifikatet er udstedt men tilbagekaldt, og OCSP-valideringen virker ikke korrekt
- Domænedækning: Certifikatet dækker ikke alle de domæner det burde
- Manglende HSTS: Serveren serverer HTTPS men sender ikke HTTP Strict Transport Security-headeren
TLS overvågning der kun ser på udløbsdatoer er som en bilinspektion der kun tjekker om bilen har benzin.
De syv ting TLS-scanning faktisk tjekker
1. Certifikatudløb og fornyelsesvindue
Det mest basale: hvornår udløber certifikatet, og hvornår skal det fornyes? Med kommende 47-dages certifikater i 2029 skal dette scannes dagligt — ikke én gang om måneden.
2. Certifikatkæde og intermediate-certifikater
En fuldstændig og korrekt certifikatkæde fra leaf-certifikat til root-CA er afgørende. Browsere og API-klienter opfører sig forskelligt ved kædefejl — nogle accepterer dem, andre fejler stille. Scanning opdager kædeproblemer proaktivt.
3. OCSP-tilbagekaldelse
Certifikater kan tilbagekaldes inden udløb hvis den private nøgle kompromitteres. OCSP-scanning (Online Certificate Status Protocol) tjekker om et certifikat er aktivt eller tilbagekaldt — en check mange manuelle processer springer over.
4. TLS-protokolversion
Servere der stadig tilbyder TLS 1.0 eller 1.1 er sårbare over for kendte angreb og opfylder ikke moderne sikkerhedsstandarder. Scanning identificerer endpoints der bruger forældede protokoller.
5. Cipher suites og kryptografisk styrke
TLS-karaktergivning (A+ til F) er en samlet vurdering der inkluderer hvilke cipher suites serveren tilbyder, om forward secrecy understøttes, og om svage algoritmer som RC4 eller NULL-cipher er tilgængelige.
6. HTTP-sikkerhedsheaders
HSTS (HTTP Strict Transport Security), Content-Security-Policy, X-Frame-Options og X-Content-Type-Options er headers der styrker TLS-sikkerheden. Scanning identificerer manglende eller fejlkonfigurerede headers.
7. Certificate Transparency-logs
CT-logs er offentlige registre over alle udstedte certifikater. Overvågning af CT-logs opdager certifikater udstedt til dine domæner som du ikke selv har bestilt — et tegn på enten skygge-IT eller et kompromis.
Internet-vendt vs. intern TLS overvågning
En typisk organisations TLS-certifikater fordeler sig på to kategorier med meget forskellig synlighed:
Internet-vendte certifikater er tilgængelige fra internettet og kan scannes direkte. Disse er relativt lette at overvåge og opdages også via CT-logs.
Interne certifikater — på AD-servere, intranet-systemer, mail-servere, CI/CD-pipelines, og intern API-kommunikation — er kun tilgængelige indefra netværket. De overses systematisk ved ekstern scanning, men de er ofte de der forårsager mest overraskelse ved udløb, fordi ingen ved de eksisterer.
En komplet TLS overvågningsløsning skal dække begge. CertControl gør dette via en on-premise agent der installeres i organisationens netværk og sender scanningsdata til platformen — uden at kræve indgående forbindelser.
Scanningshyppighed: Hvornår er "en gang om dagen" nok?
For de fleste organisationer er daglig scanning tilstrækkeligt i dag. Med 47-dages certifikater fra 2029 vil daglig scanning stadig være passende, men alarmtærsklerne skal justeres ned — man kan ikke vente 30 dage med at sende den første alarm på et 47-dages certifikat.
Anbefalet alarmstrategi for 47-dages certifikater: første alarm ved 21 dage, eskalering ved 14 dage, kritisk alarm ved 7 dage. Med ACME-automation bliver spørgsmålet irrelevant — certifikater fornys automatisk.
Sådan opsætter du TLS overvågning i praksis
- Inventariser dine endpoints: Begynd med de internet-vendte systemer. CT-log-scanning kan hjælpe med at opdage subdomæner du ikke kendte til.
- Definer kritikalitet: Ikke alle certifikater er lige kritiske. Kategoriser endpoints som kritiske, vigtige og normale — alarmniveauerne bør afspejle dette.
- Opsæt alarmmodtagere: Specificér hvem der modtager hvilke alarmer. Undgå fælles postbokse uden klar ejerskab.
- Inkludér interne netværk: Deploy en agent til interne netværk. Interne certifikater er mindst lige så vigtige som internet-vendte.
- Evaluer ACME-automation: For certifikater der kan fornys automatisk, overvej at implementere ACME. Det eliminerer udløbsrisikoen for disse certifikater helt.
- Dokumentér processen: Beskriv hvem der gør hvad ved en udløbsalarm. Det er denne dokumentation NIS2-tilsyn og ISO 27001-revisorer forventer at se.
Hvad adskiller god TLS overvågning fra dårlig
De vigtigste markører:
- Dækning: Dækker den alle endpoints, inklusiv interne? Eller kun dem man husker at tilføje?
- Alarmer til rette modtagere: Når alarmer frem til den der kan handle, eller bare til en generisk adresse?
- Mere end udløb: Opdager den TLS-konfigurationsproblemer, kædefejl og CT-anomalier?
- Historik: Er der dokumentation for hvornår certifikater blev scannet, hvilke alarmer der er sendt, og hvad der skete?
Historikken er særligt vigtig ved compliance — det er den der beviser at overvågningen var løbende og ikke lavet til lejligheden.
Hvad CertControl overvåger — og hvordan
De syv ting guiden beskriver at overvåge er præcis hvad CertControl dækker i hver scancyklus:
- Udløbsdatoer med konfigurerbare advarselsvinduer. Advarsler ved 90, 60, 30 og 14 dage routes til navngivne certifikatejere. Med 47-dages certifikater fra 2029 er ACME-automatisering den skalerbare løsning — CertControl håndterer HTTP-01 og DNS-01 challenges og advarer kun hvis automatiseringen fejler.
- Komplet certifikatkædevalidering. Manglende mellemomsætninger, udløbne mellemomsætninger, forældte algoritmer i kæden og kædevalideringsfejl dukker op som navngivne findings med specifikke diagnostik — ikke generiske TLS-fejl.
- TLS-protokolversion og cipher suite-vurdering. CertControls cipher probe tester mod syv kategorier af svage konfigurationer. Hvert endepunkt får en TLS-grad med strafpoint for hvert problem.
- HTTP-sikkerhedsheadere. HSTS-tilstedeværelse og max-age, CSP, X-Frame-Options og X-Content-Type-Options kontrolleres som del af endepunktets samlede sikkerhedsposturoversigt.
- CT-log-overvågning for nye udstedelser. CertControl overvåger CT-logs kontinuerligt for nye certifikater på dine domæner og advarer om nye udstedelser i realtid — hvad enten det er skygge-IT, mis-udstedelse eller forventede automatiske fornyelser.
- Interne certifikater via on-premise agent. Agenten installeres bag firewall og scanner interne endpoints — AD-servere, intranet, CI/CD, interne API'er — uden indgående forbindelser. Interne certifikater indgår i det samme register og alarmsystem som eksternt tilgængelige.
- OCSP-tilbagekaldelsestilstand. Tilbagekaldelsestilstand, OCSP-responders tilgængelighed og stapling-konfiguration kontrolleres per scancyklus med findings for certifikater der mangler stapling.