Branchen skifter til dedikerede TLS-rodcertifikater

Alle offentligt betroede certifikatudstedere flytter deres TLS-udstedelse til nye rodcertifikater, der udelukkende må bruges til TLS-serverautentificering. Sectigo gjorde det i foråret 2025, GlobalSign den 27. juli 2026, og DigiCert skifter standardvalget den 15. oktober 2026. Skiftet er ikke frivilligt, og det rammer alle, der driver en server med et offentligt certifikat.

Et nyt rodcertifikat er kun betroet på de klienter, der har fået det med i en opdatering. En Android 13-telefon, en iPhone på iOS 16 eller en Java-installation fra før juli 2025 kender ikke Sectigos nye rod. Løsningen er et cross-signet certifikat, der binder den nye rod til en gammel og bredt distribueret rod. På Linux tilføjer du certifikatet til kæden, og så er du færdig. På Windows Server skal du desuden deaktivere den nye rod lokalt og genstarte, fordi Schannel ellers vælger den korte kæde uanset hvad du installerer.

Hvorfor alle CA'er skifter rodcertifikat

De fire root-programmer, der afgør hvilke rodcertifikater der er betroet i praksis, har hver især indført krav om dedikerede TLS-hierarkier. En rod må ikke længere både udstede TLS-certifikater og S/MIME-certifikater eller code signing-certifikater. Kravene kom i denne rækkefølge:

• Chrome Root Program Policy v1.6 (i kraft 15. februar 2025): et hierarki skal være dedikeret til ét formål, og et intermediate under en TLS-rod må kun angive serverAuth. Fra 15. juni 2026 får rødder i hierarkier, der ikke opfylder kravet, en SCTNotAfter-dato, hvorefter nye certifikater fra hierarkiet ikke længere anerkendes.
• Microsoft Trusted Root Program Requirements v1.2 (i kraft 20. maj 2026): separate trust anchors pr. EKU fra 1. juli 2026, og nye rødder må højst have 10 års gyldighed.
• Mozilla Root Store Policy v3.1 (i kraft 1. juli 2026): nye rødder skal have ét formål, og rødder med to formål skal være overgået senest 31. december 2028. Mozilla fjerner desuden websites-tilliden 15 år efter at rodnøglen blev genereret. Nøgler fra 2008 til 2009 mister tilliden 15. april 2027, nøgler fra 2010 til 2011 den 15. april 2028.
• Apple Root Program Policy v2.0 (i kraft 1. august 2026): nye rødder må kun have ét trust purpose, og underordnede CA'er skal være enkeltformåls efter 1. juli 2027.

Mozillas 15-års-regel er den, der bider hårdest. USERTrust RSA (Sectigo) og GlobalSign Root CA - R3 er fra henholdsvis 2010 og 2009. De rødder sidder i stort set alt udstyr, der er produceret siden, og netop derfor kan de ikke blive ved. En nøgle, der har været i brug i 15 år, har akkumuleret for meget risiko til at være ankeret for hele internettets TLS-trafik.

Chromes grænse på to rødder pr. CA

Chrome Root Program Policy v1.8 (i kraft 5. februar 2026) sætter et loft: fra 15. september 2027 accepterer Chrome Root Store højst to selvsignerede rodcertifikater pr. CA-ejer. Alle CA'er skulle indsende deres konsolideringsplan senest 15. juni 2026.

Grænsen er årsagen til, at kompatibiliteten bliver sværere og ikke lettere over de næste år. En CA kan ikke beholde den gamle brede rod ved siden af den nye TLS-rod i det uendelige og lade kunderne vælge. DigiCert har allerede meldt ud, at Chrome fra 15. september 2027 kun understøtter de to G5-rødder. Når den gamle rod ryger ud af Chrome, forsvinder den langsomme, automatiske fornyelse af kompatibilitet, som gamle rødder ellers giver, og cross-signet bliver det eneste værktøj tilbage.

Tidslinje for skiftet

Datoerne stammer fra CA'ernes egne meddelelser og fra root-programmernes policy-dokumenter. Chromes egen root_store.textproto har på nogle rødder en tidligere SCTNotAfter-dato end den, CA'en oplyser. Hvor de to kilder er uenige, står CA'ens dato i tabellen.

Hvad et cross-signet certifikat gør

Et cross-signet certifikat er den nye rod udstedt en gang til, denne gang signeret af en gammel rod. Nøglen og navnet er de samme som i den nye rod. Kun signaturen er en anden.

Serveren sender kæden servercertifikat, udstedende intermediate, cross-signet certifikat. En klient, der allerede har den nye rod, standser ved det udstedende intermediate og ignorerer resten. En klient, der kun har den gamle rod, følger kæden et led længere ned og validerer mod den gamle rod. Én kæde dækker begge klienttyper.

Prisen er størrelse. Hvert ekstra led i kæden koster omkring et kilobyte i hver eneste TLS-handshake. Når de gamle klienter er væk, fjerner CA'en cross-signet igen, og kæden bliver kort.

Fortilfælde: Let's Encrypt, Google Trust Services og Certum

Let's Encrypt er det bedst dokumenterede eksempel. ISRG Root X1 blev udstedt i 2015 og var ikke bredt betroet i de første år. Let's Encrypt lod derfor deres certifikater cross-signe af DST Root CA X3, en rod fra 2000, og gjorde den lange kæde til standard 4. maj 2021. Da DST Root CA X3 udløb 30. september 2021, fejlede klienter med OpenSSL 1.0.x alligevel, fordi de validerer den kæde, serveren præsenterer, i stedet for at stoppe ved den rod, de selv stoler på. Android-enheder ældre end 7.1.1 fortsatte med at virke, fordi Android ignorerer udløbsdatoen på et rodcertifikat.

Let's Encrypt beholdt den lange kæde som standard indtil 8. februar 2024 og fjernede cross-signet helt 6. juni 2024. Der gik altså næsten tre år fra roden var i alle nye trust stores, til den kunne stå alene. Let's Encrypt opgjorde selv, at skiftet fra lang til kort kæde fjernede omkring 40 procent af de bytes, der sendes i handshaket.

Google Trust Services kører den samme model: GTS Root R1 er cross-signet af GlobalSign Root CA (R1) frem til 28. januar 2028, og Google gør stadig den lange, bagudkompatible kæde til standard. Den korte kæde ligger som alternativ via ACME, og Google skriver selv, at den korte kæde kan mangle kompatibilitet med udstyr fra før 2018.

Certum udsteder fra Certum Trusted Root CA siden 15. september 2025 og leverer cross-signede certifikater fra Certum Trusted Network CA, som selv mister tilliden 15. april 2027. Certum oplyser, at de nye rødder kan mangle på Android ældre end 14.

Mønstret er ens hos alle fire: den nye rod kommer først, cross-signet dækker overgangen i to til tre år, og først derefter bliver kæden kort igen. Det er også derfor, cross-signede kæder ikke er en fejl eller en nødløsning. De er den planlagte del af skiftet.

Hvorfor Windows er sværere end Linux

På Linux bestemmer serverkonfigurationen kæden direkte. ssl_certificate i nginx og SSLCertificateFile i Apache sender præcis den fil, du peger på, i den rækkefølge den står. Tilføjer du det cross-signede certifikat til filen, sender serveren den lange kæde. Der er ikke mere i det.

Windows bygger kæden selv. Microsoft beskriver det i KB 954755: "A certificate chain of a configured server authentication certificate is built in the local computer context. In this way, IIS determines the set of certificates that it sends to clients." Serveren udleverer altså den kæde, som Schannel selv finder frem til ud fra maskinens certifikatlagre, ikke en kæde du har skrevet ned.

Når begge veje er mulige, vælger Windows den korteste. Microsoft beskriver konsekvensen i KB 2831004 og kalder adfærden by design: "the client computer can verify the certificate only by using the longer certification path ... So the certificate validation fails."

Microsofts egen anvisning er at fjerne den korte vej lokalt: "delete or disable the certificate from the certification path that you don't want to use", via Properties og Disable all purposes for this certificate, efterfulgt af "Restart the server if the issue is still occurring".

Ændringen rammer hele maskinen, ikke kun webserveren. Schannel og maskinens certifikatlagre er fælles for IIS, Exchange (OWA, ActiveSync, EWS, Autodiscover, Outlook Anywhere, MAPI over HTTP, POP, IMAP og SMTP), RD Gateway og RD Web, AD FS og Web Application Proxy, SQL Server, NPS med EAP-TLS og PEAP samt LDAPS på domænecontrollere. Deaktiverer du en rod for at tvinge kæden, tvinger du den for dem alle.

Cachen er den sidste forskel. Kædedata caches i den proces, der byggede kæden, så iisreset eller en enkelt tjenestegenstart er ikke en garanteret rydning. En fuld genstart af serveren er den eneste pålidelige metode.

Hvad FairSSL gør

DigiCert: vi bliver på G2. Vores CertCentral-konto er sat til G2-hierarkiet, og vi bliver der så længe DigiCert tillader det. DigiCert tilbagetrak den 15. maj 2026 de ikke-TLS intermediates under Global Root G2 og G3, så de to rødder allerede er dedikeret til TLS og opfylder kravet. DigiCert skifter standardvalget til G5 den 15. oktober 2026 og oplyser, at kunder med kritiske afhængigheder af G2 og G3 skal kontakte deres account manager. Det er den vej, vi går. Chrome understøtter kun de to G5-rødder fra 15. september 2027, og DigiCert-certifikater bestilt hos os vil frem til da kæde op til DigiCert Global Root G2 fra 2013.

Den lange kæde er standard. Certifikatpakker hentet i vores kontrolpanel og kæder leveret via ACME indeholder det cross-signede certifikat, hvor CA'en har udstedt et. Du får bagudkompatibiliteten uden at bede om den. Vil du have den korte kæde, kan du hente den som alternativ via ACME, ligesom hos Let's Encrypt og Google Trust Services.

Kompatibilitetsskjolde på hvert produkt. Hvert produkt viser fem skjolde, ét pr. root store: Windows, Apple, Android, Linux og Java. Skjoldene fortæller hvor længe den rod, produktet faktisk udstedes fra, har været i den enkelte store. Ved siden af står kædens længde og hvor mange cross-signede led der skal til for at nå den bredeste gamle rod, plus en markering når Windows kræver en deaktiveret rod. Beregningen er dokumenteret på siden om kompatibilitet for rodcertifikater.

Vejledninger pr. CA. Fremgangsmåden på Windows Server er den samme for alle tre CA'er, men filnavne, rodnavne og intermediates er forskellige. Der er derfor en vejledning pr. CA med de konkrete filer: Sectigo, GlobalSign og AlphaSSL og DigiCert G5.

Hvad du skal gøre

Kender du din ældste klient? Start der. Certifikater fra de nye rødder validerer uden videre på nyt udstyr. Det er de gamle klienter, der afgør om du skal gøre noget: Android 13 og ældre, iOS 16 og ældre på Sectigos rod, Java-installationer der ikke har fået opdateringerne fra 2024 og 2025, embedded udstyr og maskiner uden internetadgang, der ikke kan hente nye rødder.

Kører du Linux? Tilføj det cross-signede certifikat til kædefilen efter det udstedende intermediate, og genindlæs webserveren. Bruger du vores certifikatpakke eller vores ACME-server, har du den allerede.

Kører du Windows Server? Importér både det udstedende intermediate og det cross-signede certifikat til Intermediate Certification Authorities i maskinens certifikatlager, deaktiver eller karantæneér den nye rod, eksportér PFX-filen med kæde igen, og genstart serveren. Læs vejledningen for din CA, inden du går i gang.

Tjek udefra bagefter. Lokale kommandoer som certutil -verify viser serverens egen opfattelse af kæden, ikke den kæde klienten modtager. Brug vores SSL Scanner eller openssl s_client -showcerts. Det sidste certifikat i den udleverede kæde skal være udstedt af den gamle rod, du sigter efter.

Skiftet er en engangsopgave pr. server, og den skal laves i et vindue hvor serveren må genstarte. Har du ikke tid eller lyst til at gøre det selv, laver vi det for jer via vores installationsservice.