Certifikatlevetider falder til 47 dage
Fra 2029 skal alle offentlige TLS-certifikater fornyes minimum hver 47. dag. Det er vedtaget af CA/Browser Forum i SC-081v3 og gælder alle offentligt betroede certifikatudstedere.
Tidsplan for kortere levetider
15. marts 2026
Maksimal certifikatgyldighed reduceres til 200 dage. DCV-genbrug reduceres til 200 dage.
DigiCert implementerer allerede 24. februar 2026 med 199 dage. Sectigo og GlobalSign følger i marts.
15. marts 2027
Maksimal certifikatgyldighed reduceres til 100 dage. DCV-genbrug reduceres til 100 dage.
Det svarer til fornyelsesbehov cirka hver 85. dag, hvis man vil undgå nedetid.
15. marts 2029
Maksimal certifikatgyldighed reduceres til 47 dage. DCV-genbrug reduceres til 10 dage.
Det kræver fornyelse cirka hver 40. dag og domænevalidering cirka hver 10. dag.
Der er ingen fase i 2028. Spring fra 100 dage i 2027 direkte til 47 dage i 2029.
Fornyelsesvolumen stiger eksponentielt
Antallet af certifikatfornyelser pr. år stiger markant for hver fase. Her er et estimat baseret på antal servere med ét certifikat hver.
| Servere | 2025 (398 dage) | 2026 (200 dage) | 2027 (100 dage) | 2029 (47 dage) |
|---|---|---|---|---|
| 10 | ~10/år | ~18/år | ~37/år | ~78/år |
| 50 | ~46/år | ~91/år | ~183/år | ~389/år |
| 200 | ~184/år | ~365/år | ~730/år | ~1.554/år |
Hvorfor manuelle processer ikke skalerer
Cron-jobs og scripts
Et certbot-script på en enkelt server fungerer fint. Men 200 servere med forskellige platforme, nøgler og CA-krav kræver central orkestrering. Fejl i et script opdages typisk først, når certifikatet udløber.
Nøgleperson-afhængighed
Når fornyelse håndteres af en enkelt person, opstår risiko ved ferie, sygdom eller jobskifte. Med 47-dages certifikater er der ingen margin. Ét overset certifikat giver nedetid inden for uger.
Manglende overvågning
Uden central overvågning opdager man først problemer, når brugere melder fejl. Med kortere levetider sker det oftere. Et dashboard, der viser alle certifikater på tværs af infrastrukturen, er ikke længere rart at have. Det er et krav.
Netværksudstyr er det sværeste
Webservere med certbot eller ACME-klienter klarer sig ofte. Det er netværksudstyr, der bliver flaskehalsen.
FortiGate, F5, NetScaler, Palo Alto
Disse enheder har typisk ikke native ACME-support. Certifikatfornyelse kræver API-kald eller CLI-adgang, ofte med leverandørspecifikke formater og begrænsninger. Hvert mærke håndteres forskelligt.
Exchange, IIS, ADFS
Windows-servere med Exchange eller IIS kræver certifikatinstallation via PowerShell eller MMC, efterfulgt af service-binding. Det kan automatiseres, men kræver en agent, der kører lokalt med de rette rettigheder.
Heterogene miljøer
De fleste organisationer har en blanding af Linux, Windows, appliances og cloud-tjenester. En løsning, der kun dækker én platform, flytter bare problemet et nyt sted.
Sådan håndterer sslbrain det
Central scheduler
sslbrain kører en central scheduler, der automatisk fornyer certifikater før de udløber. Du konfigurerer certifikatet én gang. Scheduleren tilpasser sig automatisk til gældende levetider, uanset om det er 200, 100 eller 47 dage.
ACME-proxy
sslbrain Cloud fungerer som ACME-proxy til betalte CA'er (DigiCert, Sectigo, GlobalSign). Din sslbrain taler ACME, uanset hvilken CA der udsteder. Hvis du skifter CA, ændres konfigurationen ikke.
Agenter til alle platforme
sslbrain leverer agenter til Linux (SSH), Windows (WinRM og Service Agent) og netværksudstyr via API. Certifikater installeres automatisk på den rigtige platform i det rigtige format.
Overvågning og alerting
Alle certifikater overvåges centralt. Du kan se status på tværs af hele infrastrukturen i ét dashboard. Alerts sendes ved fejl, så du ikke skal opdage problemer via brugerklager.
Start nu, vær klar til 2029
Konfigurer dine certifikater én gang. Når levetiderne falder til 100 og derefter 47 dage, justerer sslbrain automatisk fornyelsesfrekvensen. Din konfiguration ændres ikke.
Det er den samme opsætning, uanset om certifikater lever i 200 dage eller 47 dage. Forskellen er, at sslbrain fornyer dem oftere.