Alla offentligt betrodda certifikatutfärdare flyttar sitt TLS-utfärdande till nya rotcertifikat som enbart får användas till TLS-serverautentisering. Sectigo gjorde det våren 2025, GlobalSign den 27 juli 2026 och DigiCert byter standardvalet den 15 oktober 2026. Bytet är inte frivilligt och det berör alla som driver en server med ett offentligt certifikat.
Ett nytt rotcertifikat är bara betrott på de klienter som fått det via en uppdatering. En Android 13-telefon, en iPhone på iOS 16 eller en Java-installation från före juli 2025 känner inte till Sectigos nya rot. Lösningen är ett korssignerat certifikat som binder den nya roten till en gammal och brett distribuerad rot. På Linux lägger du certifikatet i kedjan och sedan är du klar. På Windows Server måste du dessutom inaktivera den nya roten lokalt och starta om, eftersom Schannel annars väljer den korta kedjan oavsett vad du installerar.
Varför alla CA-aktörer byter rotcertifikat
De fyra rotprogram som avgör vilka rotcertifikat som faktiskt är betrodda har var för sig infört krav på dedikerade TLS-hierarkier. En rot får inte längre både utfärda TLS-certifikat och S/MIME-certifikat eller certifikat för kodsignering. Kraven kom i denna ordning:
- Chrome Root Program Policy v1.6 (i kraft 15 februari 2025): en hierarki ska vara dedikerad till ett enda syfte och ett mellanliggande certifikat under en TLS-rot får bara ange
serverAuth. Från 15 juni 2026 får rötter i hierarkier som inte uppfyller kravet ett SCTNotAfter-datum, varefter nya certifikat från hierarkin inte längre godtas. - Microsoft Trusted Root Program Requirements v1.2 (i kraft 20 maj 2026): separata förtroendeankare (trust anchors) per EKU från 1 juli 2026, och nya rötter får ha högst 10 års giltighet.
- Mozilla Root Store Policy v3.1 (i kraft 1 juli 2026): nya rötter ska ha ett enda syfte, och rötter med två syften ska vara utfasade senast 31 december 2028. Mozilla tar dessutom bort tilliten för webbplatser 15 år efter att rotnyckeln genererades. Nycklar från 2008 till 2009 förlorar tilliten 15 april 2027, nycklar från 2010 till 2011 den 15 april 2028.
- Apple Root Program Policy v2.0 (i kraft 1 augusti 2026): nya rötter får bara ha ett enda förtroendesyfte, och underordnade CA ska ha ett enda syfte från 1 juli 2027.
Mozillas 15-årsregel biter hårdast. USERTrust RSA (Sectigo) och GlobalSign Root CA - R3 är från 2010 respektive 2009. De rötterna sitter i i stort sett all utrustning som tillverkats sedan dess, och just därför kan de inte fortsätta. En nyckel som varit i bruk i 15 år har samlat på sig för mycket risk för att vara ankaret för hela internets TLS-trafik.
Chromes gräns på två rötter per CA
Chrome Root Program Policy v1.8 (i kraft 5 februari 2026) sätter ett tak: från 15 september 2027 accepterar Chrome Root Store högst två självsignerade rotcertifikat per CA-ägare. Alla CA skulle lämna in sin konsolideringsplan senast 15 juni 2026.
Gränsen är skälet till att kompatibiliteten blir svårare och inte lättare de närmaste åren. En CA kan inte behålla den gamla breda roten vid sidan av den nya TLS-roten hur länge som helst och låta kunderna välja. DigiCert har redan meddelat att Chrome från 15 september 2027 bara stöder de två G5-rötterna. När den gamla roten faller ur Chrome försvinner den kompatibilitet som en gammal rot långsamt bygger upp genom automatiska uppdateringar, och det korssignerade certifikatet är det enda verktyg som återstår.
Tidslinje för bytet
| Datum | Händelse |
|---|---|
| 15 apr 2025 | Sectigo utfärdar EV-certifikat från Sectigo Public Server Authentication Root R46 (RSA) och E46 (ECC) |
| 15 maj 2025 | Sectigo flyttar OV-utfärdandet till R46/E46 (InstantSSL, Sectigo OV) |
| 2 jun 2025 | Sectigo flyttar DV-utfärdandet till R46/E46 (PositiveSSL, EssentialSSL, Sectigo DV) |
| 15 sep 2025 | Certum utfärdar TLS från Certum Trusted Root CA och Certum EC-384 CA |
| 7 jan 2026 | Let's Encrypt tar sina Gen Y-rötter (Root YR och Root YE) i bruk |
| 15 maj 2026 | DigiCert återkallar sina icke-TLS mellanliggande certifikat under Global Root G2 och G3, så att båda rötterna är dedikerade till TLS |
| 15 jun 2026 | Chrome sätter SCTNotAfter på rötter i hierarkier som inte är dedikerade till TLS |
| 27 jul 2026 | GlobalSign flyttar alla kund- och partnerprodukter till R46 (RSA) och E46 (ECC), inklusive AlphaSSL |
| 13 sep 2026 | GlobalSign flyttar övriga konton. Certifikat utfärdade från rötter med flera syften efter detta datum blir enligt GlobalSign inte betrodda av Google Chrome |
| 15 okt 2026 | DigiCert utfärdar som standard från DigiCert TLS RSA4096 Root G5 och TLS ECC P384 Root G5. Gäller DigiCert, GeoTrust, Thawte, RapidSSL och Encryption Everywhere, DV, OV och EV |
| 1 mar 2027 | DigiCert tar bort clientAuth EKU från offentliga TLS-certifikat |
| 15 apr 2027 | Chrome och Mozilla tar bort tilliten till GlobalSign Root CA - R3. Sectigo anger samma datum för USERTrust RSA och USERTrust ECC |
| 15 sep 2027 | Chromes gräns på två självsignerade rötter per CA-ägare träder i kraft. Chrome Root Store stöder därefter bara DigiCerts två G5-rötter |
| 15 apr 2029 | Chrome tar bort tilliten till GlobalSign Root CA - R5 (ECC) |
Datumen kommer från CA-aktörernas egna meddelanden och från rotprogrammens policydokument. Chromes egen root_store.textproto har för vissa rötter ett tidigare SCTNotAfter-datum än det CA-aktören uppger. Där källorna skiljer sig står CA-aktörens datum i tabellen.
Vad ett korssignerat certifikat gör
Ett korssignerat certifikat är den nya roten utfärdad en gång till, den här gången signerad av en gammal rot. Nyckeln och namnet är desamma som i den nya roten. Bara signaturen skiljer sig.
Servern skickar kedjan i ordningen servercertifikat, utfärdande mellanliggande certifikat och korssignerat certifikat. En klient som redan har den nya roten stannar vid det utfärdande mellanliggande certifikatet och ignorerar resten. En klient som bara har den gamla roten följer kedjan ett steg längre och validerar mot den gamla roten. En enda kedja täcker båda klienttyperna.
Nackdelen är storleken. Varje extra länk i kedjan kostar ungefär ett kilobyte i varje TLS-handskakning. När de gamla klienterna är borta tar CA-aktören bort det korssignerade certifikatet igen och kedjan blir kort.
Föregångare: Let's Encrypt, Google Trust Services och Certum
Let's Encrypt är det bäst dokumenterade exemplet. ISRG Root X1 utfärdades 2015 och var inte brett betrodd de första åren. Let's Encrypt lät därför sina certifikat korssigneras av DST Root CA X3, en rot från 2000, och gjorde den långa kedjan till standard den 4 maj 2021. När DST Root CA X3 gick ut den 30 september 2021 misslyckades ändå klienter med OpenSSL 1.0.x, eftersom de validerar den kedja servern presenterar i stället för att stanna vid den rot de själva litar på. Android-enheter äldre än 7.1.1 fortsatte att fungera, eftersom Android ignorerar utgångsdatumet på ett rotcertifikat.
Let's Encrypt behöll den långa kedjan som standard till den 8 februari 2024 och tog bort det korssignerade certifikatet helt den 6 juni 2024. Det gick alltså nästan tre år från att roten fanns i alla nya certifikatlager till att den kunde stå ensam. Let's Encrypt räknade själva ut att bytet från lång till kort kedja tog bort omkring 40 procent av de byte som skickas i handskakningen.
Google Trust Services kör samma modell: GTS Root R1 är korssignerad av GlobalSign Root CA (R1) fram till 28 januari 2028, och Google har fortfarande den långa bakåtkompatibla kedjan som standard. Den korta kedjan finns som alternativ via ACME, och Google skriver själva att den korta kedjan kan sakna kompatibilitet med utrustning äldre än 2018.
Certum utfärdar från Certum Trusted Root CA sedan 15 september 2025 och levererar korssignerade certifikat från Certum Trusted Network CA, som själv förlorar tilliten 15 april 2027. Certum uppger att de nya rötterna kan saknas på Android äldre än 14.
Mönstret är detsamma hos alla fyra: den nya roten kommer först, korssigneringen täcker övergången i två till tre år, och först därefter blir kedjan kort igen. Korssignerade kedjor är alltså varken ett fel eller en nödlösning. De är den planerade delen av bytet.
Varför Windows är svårare än Linux
På Linux styr serverkonfigurationen kedjan direkt. ssl_certificate i nginx och SSLCertificateFile i Apache skickar exakt den fil du pekar på, i den ordning innehållet står. Lägger du det korssignerade certifikatet i filen skickar servern den långa kedjan. Mer än så är det inte.
Windows bygger kedjan själv. 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." Servern levererar alltså den kedja som Schannel själv får fram ur maskinens certifikatlager, inte en kedja du har skrivit ned.
När båda vägarna är möjliga väljer Windows den kortaste. Microsoft beskriver följden i KB 2831004 och kallar beteendet avsiktligt (by design): "the client computer can verify the certificate only by using the longer certification path ... So the certificate validation fails."
Microsofts egen anvisning är att ta bort den korta vägen lokalt: "delete or disable the certificate from the certification path that you don't want to use", via Properties och Disable all purposes for this certificate, följt av "Restart the server if the issue is still occurring".
Fallgropen i samma KB: "if the Turn off Automatic Root Certificates Update Group Policy setting is disabled or not configured on the server, the certificate ... you don't want to use may be enabled or installed when the next chain building occurs." Windows hämtar själv rotcertifikat från Windows Update under kedjebygget. Raderar du bara den nya roten kommer den tillbaka. Sectigo har därför tagit fram en .reg-fil som i stället flyttar deras nya rötter till Disallowed-lagret, där den automatiska uppdateringen inte kan återinföra dem.
Ändringen påverkar hela maskinen, inte bara webbservern. Schannel och maskinens certifikatlager delas av IIS, Exchange (OWA, ActiveSync, EWS, Autodiscover, Outlook Anywhere, MAPI över HTTP, POP, IMAP och SMTP), RD Gateway och RD Web, AD FS och Web Application Proxy, SQL Server, NPS med EAP-TLS och PEAP samt LDAPS på domänkontrollanter. Inaktiverar du en rot för att tvinga fram den långa kedjan, gäller det för alla dessa tjänster.
Cachen är den sista skillnaden. Kedjedata cachas i den process som byggde kedjan, så iisreset eller omstart av en enskild tjänst rensar inte cachen med säkerhet. En fullständig omstart av servern är den enda tillförlitliga metoden.
Vad FairSSL gör
DigiCert: vi stannar på G2. Vårt CertCentral-konto är inställt på G2-hierarkin och vi stannar där så länge DigiCert tillåter det. DigiCert återkallade den 15 maj 2026 de icke-TLS mellanliggande certifikaten under Global Root G2 och G3, så de två rötterna är redan dedikerade till TLS och uppfyller kravet. DigiCert byter standardvalet till G5 den 15 oktober 2026 och uppger att kunder med kritiska beroenden av G2 och G3 ska kontakta sin kontaktperson hos DigiCert. Det är den vägen vi går. Chrome stöder bara de två G5-rötterna från 15 september 2027, och DigiCert-certifikat beställda hos oss kedjar fram till dess upp till DigiCert Global Root G2 från 2013.
Den långa kedjan är standard. Certifikatpaket som hämtas i vår kontrollpanel och kedjor som levereras via ACME innehåller det korssignerade certifikatet där CA-aktören har utfärdat ett. Du får bakåtkompatibiliteten utan att be om den. Vill du ha den korta kedjan kan du hämta den som alternativ via ACME, precis som hos Let's Encrypt och Google Trust Services.
Kompatibilitetssköldar på varje produkt. Varje produkt visar fem sköldar, en per certifikatlager: Windows, Apple, Android, Linux och Java. Sköldarna visar hur länge den rot produkten faktiskt utfärdas från har funnits i respektive lager. Bredvid står kedjans längd och hur många korssignerade länkar som krävs för att nå den bredaste gamla roten, plus en markering när Windows kräver en inaktiverad rot. Beräkningen är dokumenterad på sidan om kompatibilitet för rotcertifikat.
Guider per CA. Tillvägagångssättet på Windows Server är detsamma för alla tre CA-aktörer, men filnamn, rotnamn och mellanliggande certifikat skiljer sig åt. Därför finns en guide per CA med de konkreta filerna: Sectigo, GlobalSign och AlphaSSL och DigiCert G5.
Vad du behöver göra
Känner du din äldsta klient? Börja där. Certifikat från de nya rötterna validerar utan vidare på ny utrustning. Det är de gamla klienterna som avgör om du behöver göra något: Android 13 och äldre, iOS 16 och äldre mot Sectigos rot, Java-installationer som inte fått uppdateringarna från 2024 och 2025, inbyggd utrustning och maskiner utan internetåtkomst som inte kan hämta nya rötter.
Kör du Linux? Lägg det korssignerade certifikatet i kedjefilen efter det utfärdande mellanliggande certifikatet och ladda om webbservern. Använder du vårt certifikatpaket eller vår ACME-server har du det redan.
Kör du Windows Server? Importera både det utfärdande mellanliggande certifikatet och det korssignerade certifikatet till Intermediate Certification Authorities i maskinens certifikatlager, inaktivera eller sätt den nya roten i karantän, exportera PFX-filen med kedja igen och starta om servern. Läs guiden för din CA innan du börjar.
Kontrollera utifrån efteråt. Lokala kommandon som certutil -verify visar serverns egen bild av kedjan, inte den kedja klienten tar emot. Använd vår SSL Scanner eller openssl s_client -showcerts. Det sista certifikatet i den levererade kedjan ska vara utfärdat av den gamla rot du siktar på.
Bytet görs en gång per server och ska göras i ett servicefönster där servern kan startas om. Har du inte tid eller lust att göra det själv gör vi det åt dig via vår installationstjänst.