CA/Browser Forum har stemt enstemmigt. I marts 2029 vil offentligt betroede TLS-certifikater have en maksimal levetid på 47 dage. For organisationer der manuelt styrer hundredvis af certifikater er dette ikke et fremtidsproblem — overgangen startede i marts 2026 med 200-dages maksimum. Vinduet til at bygge automatisering er nu.

I det meste af TLS's historie blev certifikatlevetider målt i år. To år blev standarden maksimum i 2020. Et år blev presset af Apple og Google kort efter. Nu er industrien på vej mod 47 dage — ca. seks uger — som det hårde loft.

Sikkerhedsrationalet er solidt. Kortere certifikatlevetider begrænser eksponeringsvinduet når en privat nøgle kompromitteres. De tvinger organisationer til at bygge pålidelige fornyelsesprocesser frem for at behandle certifikater som sæt-og-glem-infrastruktur. Og de gør certifikatagility til virkelighed frem for et teoretisk mål — når I kan rotere certifikater på seks uger som en rutinemæssig sag, bliver reaktion på et CA-kompromis eller algoritmeudfasning en operationel opgave frem for en krise.

Den operationelle udfordring er betydelig. En organisation med 500 certifikater fornyer ca. 500 gange om året i dag. Under 47-dages levetider kræver de samme 500 certifikater ca. 4.000 fornyelser om året. Manuelle processer der er knap bæredygtige nu vil være fuldstændigt uholdbare.

Faseopdelt overgangsplan — hvad gælder hvornår

Ændringen sker ikke natten over. CA/Browser Forum har sat en faseopdelt tidslinje:

  • Marts 2026: Maksimal certifikatlevetid falder til 200 dage. Domænevalideringsdata skal opdateres hver 200. dag.
  • Marts 2027: Maksimal levetid falder til 100 dage.
  • Marts 2029: Endelig håndhævelse — 47-dages maksimal levetid, domænevalideringsopdatering hvert 10. dag.

10-dages domænevalideringsopdateringen i 2029 er særligt betydningsfuld. Det betyder at selv hvis I automatiserer certifikatudstedelse, skal selve domænevalideringsprocessen køre kontinuerligt — ikke kun ved fornyelse. ACME-protokollen håndterer dette naturligt; manuelle CA-portalprocesser gør ikke. For en dybere forklaring af ACME Server og ARI, se vores artikel om ACME Server og koordineret fleetfornyelse.

Hvem påvirkes mest

Virkningen af kortere levetider er ikke ensartet. Den afhænger helt af hvordan certifikater aktuelt styres:

Teams der allerede bruger ACME-automatisering — Let's Encrypt, ZeroSSL eller en CA med ACME-understøttelse — vil næppe mærke det. Deres værktøj håndterer allerede 90-dages certifikater. Skift til 47 dage ændrer fornyelsesfrekvensen men ikke den operationelle byrde, da fornyelser sker automatisk.

Teams der bruger manuel fornyelse via CA-portaler vil mærke overgangen mest akut. En proces der krævede én handling per certifikat per år vil kræve næsten otte. I enhver meningsfuld skala bryder dette folk.

Teams med hybride tilgange — noget automatiseret, noget manuelt — vil opdage at den manuelle del bliver stadig mere uholdbar og presset til at automatisere alt accelererer. Læs mere om forskellene i manuel vs. automatisk certifikatstyring.

Interne certifikater på private CA'er er ikke direkte underlagt CA/Browser Forum-regler, men presset til at standardisere på kortere levetider og automatiseret rotation bygger sig op i industrien alligevel.

Hvorfor ACME er den eneste skalerbare løsning — og hvad det forudsætter

ACME (Automatic Certificate Management Environment) er den protokol Let's Encrypt byggede og som nu er standardiseret som RFC 8555. Den automatiserer den fulde certifikatlivscyklus: domænevalidering, udstedelse, installation og fornyelse — uden menneskelig intervention. Se vores guide til forebyggelse af certifikatudløb for praktiske skridt til at komme i gang.

For at ACME kan fungere pålideligt i stor skala skal et par ting være på plads:

  • HTTP-01 eller DNS-01 challenge-understøttelse. ACME validerer domæneejerskab ved at placere et token på en velkendt URL (HTTP-01) eller i en DNS TXT-record (DNS-01). Jeres infrastruktur skal understøtte en af disse. DNS-01 kræves til wildcard-certifikater og er nyttig til tjenester der ikke kan betjene HTTP-challenges.
  • Automatiserede DNS-opdateringer (til DNS-01). Hvis jeres DNS styres af en udbyder med en API er automatisering ligetil. Hvis DNS-ændringer kræver en ticket til et separat team kræver DNS-01 automatisering procesændringer først.
  • Certifikatlagring og -distribution. Fornyede certifikater skal nå de tjenester der bruger dem. Dette er ofte den sværeste del — særligt for organisationer med certifikater installeret på hardware-load-balancers, F5-enheder, HSM'er eller andre systemer der ikke har native ACME-understøttelse.
  • Overvågning af fornyelsesfejl. Automatisering der fungerer 99% af tiden fejler stadig 1% af tiden. Uden overvågning af fornyelsesfejl går en fejlet fornyelse uopdaget indtil certifikatet udløber og noget bryder ned.

Tilfælde hvor ACME ikke gælder

ACME fungerer godt til webservere, API'er og tjenester med internettilgængelige endepunkter. Det er vanskeligere eller umuligt for nogle almindelige certifikatanvendelsestilfælde:

  • Klientcertifikater og mutual TLS — ACME er designet til servercertifikater. Klientcertifikatudstedelse og rotation kræver andet værktøj.
  • Kodesigneringscertifikater — ikke dækket af ACME.
  • Certifikater der kræver Extended Validation (EV) — EV involverer identitetsverifikationstrin der ikke kan automatiseres.
  • Hardware security modules og smartkort — certifikater lagret i hardware kræver ofte leverandørspecifikt værktøj til rotation.
  • Air-gappede eller fuldt isolerede miljøer — ACME kræver udgående internetadgang til CA'en. Fuldt isolerede miljøer kræver offline- eller privat CA-løsninger. For interne servere med udgående internetadgang er CertControl ACME Server (Scale-plan) løsningen: certbot eller Posh-ACME på serveren kontakter CertControl, som proxyer ordren til den konfigurerede CA — serverne behøver ikke direkte adgang til CA'en.

Hvad I skal kortlægge inden stramningerne accelererer

200-dages maksimummet er allerede i kraft. Hvis I ikke er begyndt endnu er det praktiske første skridt en audit af jeres nuværende certifikatbeholdning:

  1. Tæl jeres certifikater efter fornyelsesmetode. Hvilke er allerede automatiserede via ACME? Hvilke kræver manuel fornyelse? Hvilke styres af tredjeparter? De manuelle er jeres højeste prioritet.
  2. Identificer afhængigheder af langlivede certifikater. Nogle processer antager at certifikater er gyldige i et år eller mere — backup-valideringsprocedurer, revisionsdokumentationscyklusser, manuelle installationsworkflows. Disse skal ændres.
  3. Kortlæg jeres certifikatdistributionsveje. For hvert certifikat — hvordan ankommer et fornyet certifikat til installation? Hvis svaret involverer et menneske der kopierer filer er det en proces der har brug for automatisering inden 2029.
  4. Tjek CA-kompatibilitet. Ikke alle CA'er understøtter ACME. Hvis jeres nuværende CA-relationer er med udbydere der kun tilbyder portalbaseret udstedelse er det nu tid til at evaluere alternativer eller forhandle ACME-adgang.

Hvordan CertControl understøtter overgangen

CertControl inkluderer to ACME-tilstande. Som ACME-klient (Business-plan) henter CertControl certifikater fra Let's Encrypt eller en anden understøttet CA på jeres vegne — HTTP-01 automatisk, DNS-01 via et enkelt valideringstrin. Private nøgler lagres krypteret med AES-256-GCM, og certifikater deployes direkte til målserveren. Som ACME Server (Scale-plan, RFC 8555) agerer CertControl selv som ACME-endpoint for jeres interne servere: certbot, acme.sh eller Posh-ACME på serverne kontakter CertControl, som proxyer ordren til den konfigurerede CA. Med DNS-plugin konfigureret er fornyelse zero-touch — ingen manuel handling overhovedet. ACME Server inkluderer ARI (RFC 9773): CertControl signalerer det optimale fornyelsesvindue til certbot, acme.sh og Posh-ACME — en kritisk evne i takt med at certifikatlevetiden falder til 47 dage og fornyelsesvinduet indsnævres tilsvarende. CertControl overvåger anmodningsstatus løbende — så problemer dukker op som advarsler frem for nedbrud.

For certifikater der ikke kan automatiseres sporer CertControl dem i det samme register med konfigurerbare advarselsvinduer — og giver teams mest mulig tid til de manuelle trin der stadig er nødvendige. Den kombinerede visning af automatiserede og manuelle certifikater sikrer at intet falder gennem hullet mellem de to tilgange.

Ofte stillede spørgsmål

Hvornår træder 47-dages grænsen i kraft?

Den er faseopdelt. Maksimal levetid falder til 200 dage i marts 2026, til 100 dage i marts 2027 og til 47 dage i marts 2029. 200-dages loftet er allerede i kraft.

Gælder 47-dages reglen for interne eller private CA-certifikater?

Nej. CA/Browser Forum-reglerne gælder kun offentligt betroede certifikater. Private CA-certifikater er ikke direkte berørt, men de fleste teams vælger alligevel kortere levetider og automatiseret rotation for dem.

Hvor meget ekstra arbejde skaber en 47-dages levetid?

Cirka en otte-dobling af antallet af fornyelser. En beholdning på 500 certifikater, der i dag fornyes en gang om året, ville kræve omkring 4.000 fornyelser om året — ikke bæredygtigt med manuelle processer.

Er ACME-automatisering nok til at håndtere 47-dages certifikater?

For servercertifikater med HTTP-01 eller DNS-01 challenge-understøttelse, ja. ACME dækker ikke klientcertifikater, kodesignering, EV-certifikater eller hardware-lagrede nøgler, som stadig kræver separat værktøj og længere advarselsvinduer.

Hvad skal jeg kortlægge inden reglerne strammes yderligere?

Tæl certifikater efter fornyelsesmetode, identificer afhængigheder af langlivede certifikater, kortlæg hvordan fornyede certifikater distribueres, og bekræft at jeres CA understøtter ACME. De manuelle certifikater har højeste prioritet.

Se platformen Book demo