Val av CA är ett säkerhetsbeslut

Val av CA är ett säkerhetsbeslut

De flesta väljer certifikatutfärdare (CA) efter pris eller vana. Det är ett misstag. Ditt val av CA påverkar hur brett ditt certifikat accepteras, hur snabbt du kan agera om din CA förlorar webbläsarnas förtroende, och vilka certifikattyper du har tillgång till.

Entrust-incidenten 2024, där Google Chrome drog in förtroendet för Entrust, visade tydligt konsekvenserna: tusentals organisationer tvingades hitta en ny CA. De som redan hade certifikat från mer än en CA klarade sig utan problem. Övriga fick betala med övertid och driftstopp.

Det nuvarande CA-landskapet

Det finns bara en handfull relevanta kommersiella CA-aktörer på marknaden:

• DigiCert (inkl. RapidSSL, GeoTrust, Thawte): Världens största kommersiella CA. Bredast distribuerade rotcertifikat. Övervägande västlig kundbas i USA och Europa. Äger varumärkena från Symantecs tidigare CA-verksamhet, och certifikaten under dem utfärdas nu från DigiCerts infrastruktur.
• GlobalSign (inkl. AlphaSSL): Internationell CA med övervägande västlig kundbas i USA och Europa, kompletterad av Japan. AlphaSSL är deras lågprisvarumärke och har nyligen bytt till G3-rotcertifikatet. Kan kräva ett korssignerat mellanliggande certifikat för äldre enheter.
• Sectigo (tidigare Comodo): Låga priser och stor marknadsandel i DV-segmentet. Övervägande västlig kundbas, koncentrerad kring amerikanska domäner. Använder ofta korssignerade mellanliggande certifikat. OV/EV-validering är i hög grad beroende av Dun & Bradstreet, vilket gör processen nästan omöjlig i Norden, där D&B-täckningen är begränsad.
• Certum: Polsk CA (Asseco Data Systems). Certifikat under eget varumärke säljs främst på den polska marknaden. CT-logganalyser visar att ungefär 80% av certifikaten under Certums rötter utfärdas via white-label-lösningar av tredje part, där kinesiska operatörer står för en betydande andel. En märkbar del av OV/EV-certifikaten utfärdas till aktörer i Iran och Nigeria, vilket ger en annan förtroendeprofil än de västliga CA:ernas.
• Buypass: Norsk CA. Kundbasen finns nästan uteslutande i Norge. Har stängt sin SSL-verksamhet. Alla befintliga kunder måste byta CA.
• Google Trust Services: Googles egen CA. Utfärdar uteslutande gratis DV-certifikat via ACME. Erbjuder varken OV eller EV.

Uppgifter om CA:ernas profil och marknadsposition per mars 2026.

Rotcertifikatens livscykel

Alla publikt betrodda SSL-certifikat har en certifikatkedja som slutar i ett rotcertifikat, förinstallerat i operativsystem och webbläsare. Rotcertifikatets ålder och distribution avgör hur brett ditt certifikat accepteras.

Rotcertifikat har en begränsad livslängd. Mozilla har formaliserat detta i sin Root CA Lifecycle-policy, som sätter gränser för hur länge nyckelmaterial i en rot-CA får användas. Det är kryptografisk hygien: ju längre en nyckel är i bruk, desto större är den ackumulerade risken. Se även Mozillas översikt över livscykeln för alla CA-aktörers rotcertifikat.

Mozilla, Apple, Google och Microsoft har var sitt certifikatlager med egna krav för att ta in och fasa ut rötter. När en rot löper ut eller tas bort slutar alla certifikat i den kedjan att fungera.

Den påtvingade migreringen bort från gamla rötter

Alla stora CA-aktörer befinner sig mitt i en påtvingad migrering bort från sina äldre, brett distribuerade rotcertifikat. Mozillas Root CA Lifecycle-policy kräver att nyckelmaterial i ett rotcertifikat inte är äldre än 15 år från det datum nyckeln skapades (inte från certifikatets utfärdandedatum) för TLS, och 18 år för S/MIME. Datumet fastställs utifrån den granskade rapporten från nyckelceremonin (key ceremony), eller för äldre rötter (före juli 2012) utifrån certifikatets "Valid From"-datum. När gränsen nås tar Mozilla bort roten från sitt certifikatlager, och certifikat utfärdade från den roten slutar fungera i Firefox.

CA-aktörerna kan inte förnya sina gamla rötter eller förlänga livslängden. De måste skapa helt nya nyckelpar, genomföra en granskad nyckelceremoni och ansöka om att tas in i alla fyra stora certifikatlager (Mozilla, Apple, Google, Microsoft) från början. Mozilla rekommenderar att CA-aktörer ansöker om inkludering av sin nästa rot minst 2 år innan den gamla roten slutar vara betrodd. Det tar tid innan en ny rot når alla enheter via OS- och webbläsaruppdateringar. Det finns tecken på att Google Chrome på sikt vill ha tätare rotation än 15 år, kanske ner till 5 år, men det är ännu inget formellt krav.

Flera rötter som är över 20 år gamla har redan tagits bort, och fler är på väg ut. Mozilla slutade lita på rötter från före 2006 i april 2025, och näst på tur är rötter från 2008-2012. Resultatet är att de gamla rötterna, som är förinstallerade i praktiskt taget alla enheter, gradvis försvinner och ersätts av nyare rötter med kortare historik och lägre kompatibilitet med äldre system. Korssignering används som övergångslösning, men gör certifikatkedjan mer komplex. Se Mozillas fullständiga tidplan för utfasning för alla CA-aktörer.

Från nu och fram till mitten av 2029 måste flera CA-aktörer ge upp de gamla, brett distribuerade rötterna som i åratal har gett nästan universell kompatibilitet. Varje gång en rot fasas ut förlorar kunder med äldre enheter kompatibilitet, och CA-aktören måste bevisa att deras nya rot är lika pålitlig. Det är en turbulent period för branschen.

Utgångsdatum kontra borttagning ur webbläsarna

När en rot "dör" finns det två datum att hålla isär: certifikatets utgångsdatum (hårdkodat i certifikatet, vanligtvis 20-30 år framåt) och datumet då webbläsarna slutar lita på roten (den dag webbläsarna tar bort roten från sitt certifikatlager via en programuppdatering). Rötter överlever sällan till sitt faktiska utgångsdatum, eftersom webbläsarna tar bort dem först.

Källor: Mozilla CA Root Lifecycles, GlobalSign Upcoming Changes, DigiCert Hierarchy Transition, Sectigo Root Migration, Certum New Root CAs, Let's Encrypt Certificates, Google Trust Services Repository, Chrome Root Program Term Limit

Alla CA-aktörers nästa generation av rotcertifikat följer samma mönster: dedikerade rötter med ett enda syfte. De gamla rötterna användes för flera syften (TLS, kodsignering, S/MIME och Client Auth från samma rot), medan de nya rötterna enbart används för TLS Server Authentication. Det betyder att EKU Client Authentication försvinner från alla nya certifikat.

Vilken generation en CA befinner sig i är till stor del en fråga om tajming. DigiCert har cirka 2 år längre kvar på sin G2-rot än vad GlobalSign hade på R3. Det beror inte på teknisk skicklighet utan på när nycklarna råkade skapas. AlphaSSL (GlobalSign) har redan bytt till de nya rötterna, vilket krävde ett korssignerat mellanliggande certifikat för att fungera i vissa klienter. Sectigo har nästan alltid använt korssignering (bland annat för sin tidigare AddTrust CA), så övergången är mindre synlig.

Mellanliggande certifikat, korssignering och nya krav

Mellan rotcertifikatet och ditt servercertifikat ligger ett eller flera mellanliggande certifikat. Alla CA-aktörer byter mellanliggande certifikat löpande, och de kommer att behöva göra det oftare framöver.

CA/Browser Forum har infört krav på att mellanliggande certifikat ska vara dedikerade till ett enda syfte. Ett mellanliggande certifikat som utfärdar DV-certifikat får inte också utfärda OV-certifikat. De nya dedikerade TLS-rötterna (som GlobalSigns R46/E46) är dessutom begränsade till enbart Server Authentication. EKU Client Authentication och andra syften tas bort, så certifikat utfärdade från dessa rötter kan endast användas för TLS-serverautentisering. Se vår artikel om EKU Client Authentication om ändringen.

När en CA byter rotcertifikat utfärdar den vanligtvis korssignerade mellanliggande certifikat som extra kedjecertifikat. Servern skickar med dem i TLS-handskakningen så att äldre klienter kan bygga en kedja till det gamla rotcertifikatet, medan nyare klienter använder det nya. På Windows är det nästan omöjligt att tvinga kedjan åt rätt håll via certifikatlagret, eftersom det kräver att det gamla rotcertifikatet inaktiveras först.

Den moderna kedjan är kort: servercertifikat → Mellanliggande CA G3 → Rot-CA G3.

Med korssignering skickar servern en längre kedja: servercertifikat → Mellanliggande CA G3 → Korssignerat mellanliggande G2 → Rot-CA G2. En klient som har G3-roten i sitt certifikatlager stannar vid Mellanliggande CA G3 och ignorerar resten. En klient som bara har G2-roten följer hela kedjan till Rot-CA G2.

Det extra korssignerade mellanliggande certifikatet har också nackdelar. Det ökar antalet bytes i varje TLS-handskakning, vilket kostar några millisekunder för den som mäter. På servrar som inte hanterar det korrekt, till exempel Windows, kan det ge problem med kedjevalet eftersom certifikatlagret själv försöker bygga den kortaste kedjan.

Föråldrade mellanliggande certifikat ger fel

Många administratörer är vana vid att mellanliggande certifikat håller i åratal och återanvänder kedjefiler från tidigare installationer. Det fungerar inte längre. CA-aktörerna byter mellanliggande certifikat oftare, och om servern skickar en föråldrad kedja misslyckas TLS-anslutningen. Chrome hämtar själv saknade mellanliggande certifikat via AIA (Authority Information Access), så Chrome-användare märker det sällan. Det är lite paradoxalt: Google argumenterar för att CRL- och OCSP-uppslag är för långsamma och integritetskränkande för att webbläsaren ska göra dem, och ignorerar dem därför helt. Men saknade kedjecertifikat hämtar Chrome gärna själv, eftersom det är den delen användarna klagar på. Kontrollen av återkallelse hoppas över eftersom den kan "fördröja" sidvisningen. Firefox, äldre mobilwebbläsare och många API-klienter hämtar inte saknade mellanliggande certifikat, och anslutningen misslyckas.

Ett välkänt exempel: Sectigos gamla AddTrust External CA Root löpte ut i maj 2020 och orsakade utbredda problem eftersom många servrar fortfarande skickade den föråldrade AddTrust-kedjan istället för den nya USERTrust-roten.

Ett nyare exempel: i juni 2025 bytte Sectigo mellanliggande certifikat för sina PositiveSSL-produkter från den väletablerade USERTrust RSA-roten till den nya Sectigo Public Server Authentication Root R46 (nyckel från 2021). Windows-servrar byggde automatiskt kedjan till den nya roten, som ännu inte fanns i alla certifikatlager, och IIS-installationer misslyckades. Vi fick ändringen uppskjuten för våra kunder, men från juni 2026 kan den inte skjutas upp längre, och Sectigo-kunder får en större förändring av vilken rotkedja deras certifikat använder.

Hämta alltid den aktuella kedjan från CA-aktörens dokumentation vid varje installation och återutfärdande. Återanvänd inte gamla kedjefiler.

Bytet till dedikerade TLS-rotcertifikat berör alla tre CA-aktörer vi säljer från, och det är den enskilda förändring som just nu kostar mest arbete på Windows Server. Datumen per CA, vad ett korssignerat certifikat gör och vad du behöver göra som kund står samlat i Branschen byter till dedikerade TLS-rotcertifikat.

Vad är CA-flexibilitet?

CA-flexibilitet innebär att din infrastruktur inte är beroende av en enskild certifikatutfärdare. Om din CA förlorar webbläsarnas förtroende, blir uppköpt av en konkurrent, ändrar prismodell eller helt enkelt inte kan leverera tillräckligt snabbt, kan du byta utan att bygga om ditt arbetsflöde.

I praktiken kräver det:

1. Tillgång till mer än en CA. Ha avtal med minst två CA-aktörer så att du kan byta utan att starta en inköpsprocess under tidspress.
2. Möjlighet att snabbt byta alla certifikat. Med ACME-automatisering och ARI (ACME Renewal Information) kan din klient själv upptäcka när ett certifikat bör förnyas i förtid, till exempel vid ett CA-byte eller en återkallelse. Utan automatisering är ett CA-byte ett manuellt projekt som tar veckor.
3. Flexibla nyckelstorlekar. Nyckeltyp och nyckelstorlek ska gå att ändra i konfigurationen. RSA 2048 är den svagaste nyckeln som fortfarande används för SSL och är redan begränsad för S/MIME och kodsignering, där certifikat ska hålla i flera år.

ECDSA-nycklar är markant snabbare i TLS-handskakningen än RSA. Det är särskilt relevant för servrar med många samtidiga anslutningar. Minimum bör vara RSA 3072 eller ECDSA P-256.

Kvantdatorer och certifikatnycklar

På en korrekt konfigurerad server används certifikatets nyckel endast för autentisering under TLS-handskakningen. När servern använder ECDHE- eller DHE-nyckelutbyte (vilket alla moderna TLS 1.2- och TLS 1.3-konfigurationer gör), genereras en unik sessionsnyckel för varje anslutning via Perfect Forward Secrecy (PFS). Den faktiska datakrypteringen hanteras av dessa tillfälliga sessionsnycklar med chiffer som AES-256-GCM, inte av certifikatets nyckel.

Det betyder att "save now, decrypt later"-scenariot, där en angripare samlar in krypterad trafik idag och dekrypterar den med en framtida kvantdator, inte påverkas av certifikatets nyckelstorlek. Sessionsnycklarna är unika per anslutning och existerar inte efter att sessionen avslutats. Det förutsätter dock att servern inte tillåter äldre chiffersviter utan PFS (t.ex. TLS_RSA_WITH_AES_256_CBC_SHA), där certifikatets privata nyckel används direkt för nyckelutbytet. Med sådana chiffersviter aktiverade är all insamlad trafik i fara den dag nyckeln kan knäckas.

Den verkliga risken med kvantdatorer är realtidsattacker: när de första staterna får kapacitet att knäcka certifikatnycklar kan de potentiellt utföra osynliga man-in-the-middle-attacker mot känsliga system genom att generera falska certifikat eller utge sig för att ha ett äkta certifikat i realtid. För sådana system kan det vara vettigt att använda nycklar som tar längre tid att knäcka. När de första kvantdatorerna kan knäcka RSA 2048 kommer det sannolikt att dröja 1-3 år innan RSA 4096 också kan knäckas. Beräkningen per nyckel tar förmodligen timmar till dagar, så det avgörande är inte tiden per nyckel utan övergångsperioden då starkare nycklar ännu inte är sårbara.

Se därför till att servern bara erbjuder moderna chiffersviter. Inaktivera alla chiffersviter utan PFS, alla chiffer i CBC-läge och allt under TLS 1.2. Använd IIS Crypto på Windows eller Mozilla SSL Configuration Generator för att konfigurera detta korrekt. TLS 1.3 stöder enbart chiffersviter med PFS och är det säkraste valet.

5. Inga CA-specifika beroenden i koden. Hårdkodade mellanliggande certifikat, pinning till specifika utfärdare (HPKP) eller CA-specifika API-integrationer gör dig sårbar.
6. CAA-poster som tillåter mer än en CA. Om din DNS bara tillåter en CA via CAA-poster kan du inte byta snabbt. Lägg till alla CA-aktörer du kan tänkas vilja använda. Se vår artikel om CAA-poster.

Varför en enda CA inte räcker

Utöver Entrust-incidenten har vi sett flera exempel på att CA-aktörer plötsligt inte kan leverera:

• Symantec 2017: Google drog in förtroendet för alla Symantec-certifikat (inkl. GeoTrust, Thawte, RapidSSL). DigiCert tog över verksamheten, men alla befintliga certifikat måste återutfärdas.
• StartCom/WoSign 2016: Båda CA-aktörerna togs bort från certifikatlagren efter systematiskt missbruk.
• GlobalSign OCSP-avbrott 2016: GlobalSign skickade av misstag ut OCSP-svar som markerade certifikat som återkallade. Svaren cachades av webbläsare och CDN:er, och många webbplatser med GlobalSign-certifikat var otillgängliga i flera dagar. Kunder som hade en alternativ CA kunde byta. Resten fick vänta.
• Fel i GlobalSigns mellanliggande CA 2020: Ett tekniskt fel i GlobalSigns mellanliggande CA ledde till återkallelse av tusentals certifikat.
• Buypass 2025: Den norska CA-aktören slutade utfärda SSL-certifikat. Kunder som enbart använde Buypass var tvungna att hitta en ny CA under tidspress.

Ingen CA är immun mot problem, och förr eller senare drabbas även din. Se till att kunna byta CA, eller ännu hellre att redan ha avtal med mer än en.

CA-aktörernas styrkor och svagheter

De tre stora CA-aktörerna har olika fokusområden:

• DigiCert har fokuserat på tekniska lösningar och plattformsintegrationer. De har det mest kompatibla rotcertifikatet av de tre. Å andra sidan stiger priset varje år, och kundtjänsten i Europa är inte alltid deras starkaste sida.
• GlobalSign har behållit fokus på OV/EV-lösningar med smidig validering, särskilt i Europa och Skandinavien. Vi på FairSSL utför OV-validering på uppdrag av GlobalSign på svenska och danska, oftast inom en timme.
• Sectigo har låga priser på DV-certifikat. OV/EV-validering av skandinaviska organisationer är en helt annan historia: det kräver alltid direktkontakt med Sectigos support och helst verifiering via Dun & Bradstreet. Det går inte snabbt. Vi har valt att ta bort Sectigos OV/EV-produkter från vårt sortiment av just den anledningen.

Tills GlobalSign bytte rotcertifikat på AlphaSSL rekommenderade vi AlphaSSL för kombinationen av pris och kompatibilitet. Med bytet till G3 och de kompatibilitetsproblem det medförde är RapidSSL och Thawte 123 nu våra billigaste certifikat med bred kompatibilitet.

Alla CA-aktörers rotcertifikat har fasta utgångsdatum, och de planerar redan för nästa generation. Våra rekommendationer ändras i takt med detta under de kommande åren, och vi vet redan att flera rotcertifikat kommer att bytas ut.

FairSSL:s tillvägagångssätt

Vi säljer certifikat från tre oberoende CA-aktörer: DigiCert, GlobalSign och Sectigo. Vi ägs inte av och är inte bundna till någon specifik CA. Vi rekommenderar den produkt som passar uppgiften bäst, oavsett varumärke.

Hostingleverantörer och IT-konsulter som återförsäljer certifikat bör ha avtal med minst två CA-aktörer. Det minskar exponeringen vid CA-problem och ger kunderna en reell reservplan.

Rekommendationer

1. Använd minst två CA-aktörer i produktion.
2. Automatisera utfärdande och installation med ACME, så att ett CA-byte blir trivialt.
3. Kontrollera dina CAA-poster och se till att alla relevanta CA-aktörer är tillåtna.
4. Lås inte certifikat till specifika CA-aktörer i kod eller konfiguration (pinning).
5. Håll ett öga på CA-nyheter. Följ ändringarna i Googles och Mozillas certifikatlager. Det är där problemen visar sig först.