Val av CA är ett säkerhetsbeslut

Val av CA är ett säkerhetsbeslut

De flesta väljer certifikatutfärdare (CA) baserat på 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 flera CA-aktörer klarade sig utan problem. Resten fick betala priset i form av övertid och nedtid.

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 det tidigare Symantec CA, som nu utfärdas 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, nyligen bytt till G3-rotcertifikatet. Kan kräva cross-signed intermediate för äldre enheter.
• Sectigo (tidl. Comodo): Billigaste bland de stora CA:erna. Stor marknadsandel i DV-segmentet. Övervägande västlig kundbas, koncentrerad kring amerikanska domäner. Använder ofta cross-signed intermediates. 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). Egna varumärkescertifikat täcker övervägande 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, en annorlunda trust-profil än de västliga CA:erna.
• Buypass: Norsk CA. Kundbas nästan uteslutande på den norska marknaden. Har stängt sin SSL-verksamhet. Alla befintliga kunder måste migrera.
• 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 publika SSL-certifikat kedjar upp till ett rotcertifikat som är 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 alla CA-aktörers rotcertifikatslivscykler.

Mozilla, Apple, Google och Microsoft underhåller varsin trust store med individuella krav för inkludering och utfasning. När en rot löper ut eller tas bort, slutar alla certifikat i den kedjan att fungera.

Den tvingande migreringen från gamla rötter

Alla stora CA-aktörer befinner sig mitt i en tvingande migrering bort från sina äldre, brett distribuerade rotcertifikat. Mozillas Root CA Lifecycle-policy kräver att nyckelmaterial i ett rotcertifikat inte får vara ä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 auditerade key ceremony-rapporten, 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 sin trust store, 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, genomgå en auditerad key ceremony och ansöka om inkludering i alla fyra stora trust stores (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 distrustas. Det tar tid att distribueras till alla enheter via OS- och webbläsaruppdateringar. Det finns indikationer på att Google Chrome på sikt vill ha en tätare rotation än 15 år, möjligen ner till 5 år, men det är ännu inget formellt krav.

Med rötter som är över 20 år gamla har flera redan tagits bort och fler är på väg ut. Rötter från före 2006 är redan distrusted av Mozilla (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. Cross-signing används som en bro under övergångsperioden, men tillför komplexitet till certifikatkedjan. Se Mozillas fullständiga distrust-tidplan för alla CA-aktörer.

Från nu och fram till mitten av 2029 måste flera CA-aktörer döda sina darlings: de gamla, brett distribuerade rötterna som har gett nästan universell kompatibilitet i åratal. Varje gång en rot stängs ner 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.

Kryptografiskt utgångsdatum vs browser distrust

När en rot "dör" är det viktigt att skilja mellan två datum: certifikatets utgångsdatum (hårdkodat i certifikatet, typiskt 20-30 år framåt) och browser distrust-datumet (den dag webbläsarna tar bort roten från sin trust store via en mjukvaruuppdatering). Idag överlever rötter sällan till sitt faktiska utgångsdatum. Webbläsarna dödar 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. Där de gamla rötterna var multi-purpose (TLS, Code Signing, S/MIME, Client Auth från samma rot), har de nya rötterna enbart 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 är inte en teknisk bedrift, det är ren slump när nycklarna skapades. AlphaSSL (GlobalSign) har redan bytt till de nya rötterna, vilket krävde ett cross-signed intermediate för att fungera i vissa klienter. Sectigo har nästan alltid använt cross-signing (bland annat för sin tidigare AddTrust CA), så övergången är mindre synlig.

Intermediates, cross-signing och nya krav

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

CA/Browser Forum har infört krav på att intermediates ska vara dedikerade till ett enda syfte. Ett intermediate som utfärdar DV-certifikat får inte också utfärda OV-certifikat. De nya dedikerade TLS-rötterna (som GlobalSigns R46/E46) är också begränsade till uteslutande 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 för detaljer kring denna ändring.

När en CA byter rotcertifikat utfärdar de typiskt cross-signed intermediates 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 certificate store, eftersom det kräver att det gamla rotcertifikatet inaktiveras först.

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

Med cross-signing skickar servern en extra kedja: servercertifikat → Intermediate CA G3 → Cross-signed Intermediate G2 → Rot CA G2. En klient med G3-roten i sin trust store stannar vid Intermediate G3 och ignorerar resten. En klient som bara har G2-roten följer den fullständiga kedjan ner till Rot CA G2.

Det extra cross-signed intermediate-certifikatet ger inte bara fördelar. Det ökar antalet bytes som skickas i varje TLS-handskakning, vilket lägger till millisekunder för de som räknar dem. Och på servrar som inte hanterar det korrekt, som Windows, kan det ge problem med kedjevalet eftersom certificate store försöker bygga den kortaste kedjan själv.

Föråldrade intermediates ger fel

Många administratörer är vana vid att intermediates håller i åratal och återanvänder kedjefiler från tidigare installationer. Det fungerar inte längre. CA-aktörerna byter intermediates oftare, och om servern skickar en föråldrad kedja misslyckas TLS-anslutningen. Chrome hämtar själv saknade intermediates 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å. Säkerheten (revocation check) hoppas över för att den kan "fördröja" sidvisningen. Firefox, äldre mobilwebbläsare och många API-klienter hämtar inte saknade intermediates. De 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 intermediate på 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 inte var distribuerad i alla trust stores ännu, 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 kommer att uppleva ett större skifte i vilken rotkedja deras certifikat använder.

Lösningen är enkel: hämta alltid den aktuella kedjan från CA-aktörens dokumentation vid varje installation och omutfärdande. Återanvänd inte gamla kedjefiler.

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 designa 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. Det bör vara enkelt att ändra nyckeltyp och storlek i din konfiguration. RSA 2048 är den svagaste nyckeln som fortfarande används för SSL och är redan begränsad för S/MIME och Code Signing, 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 key exchange (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 efemära sessionsnycklar via cipher suites 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 cipher suites utan PFS (t.ex. TLS_RSA_WITH_AES_256_CBC_SHA), där certifikatets privata nyckel används direkt för key exchange. Med sådana ciphers aktiverade är all insamlad trafik i fara den dag nyckeln kan knäckas.

Den verkliga oron 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 helt enkelt utge sig för att vara 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. Själva beräkningen per nyckel tar förmodligen timmar till dagar, så den absoluta tiden per nyckel är inte den avgörande faktorn. Det är den totala övergångsperioden där starkare nycklar ännu inte är sårbara.

Det är därför minst lika viktigt att säkerställa att servern endast erbjuder moderna cipher suites. Inaktivera alla ciphers utan PFS, alla CBC-mode ciphers 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 uteslutande PFS-baserade cipher suites och är det säkraste valet.

5. Inga CA-specifika beroenden i koden. Hårdkodade intermediate-certifikat, pinning till specifika utfärdare (HPKP) eller CA-specifika API-integrationer gör dig sårbar.
6. CAA-records som tillåter flera CA-aktörer. Om din DNS endast tillåter en CA via CAA-records kan du inte byta snabbt. Lägg till alla de CA-aktörer du potentiellt vill använda. Se vår guide till CAA-records.

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 var tvungna att omutfärdas.
• StartCom/WoSign 2016: Båda CA-aktörerna togs bort från trust stores efter systematiskt missbruk.
• GlobalSign OCSP-avbrott 2016: GlobalSign skickade av misstag ut OCSP-svar som markerade allt som återkallat. 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.
• GlobalSign intermediate-fel 2020: Ett tekniskt fel i GlobalSigns intermediate-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. Frågan är inte om det händer, utan när. Det är logiskt att kunna byta CA, eller ännu hellre: redan ha en anslutning till 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 för närvarande det mest kompatibla rotcertifikatet. Å 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 är helt klart billigast 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 de billigaste alternativen med bred kompatibilitet.

Alla CA-aktörers rotcertifikat har fasta utgångsdatum, och de planerar redan för nästa generation. Våra rekommendationer kommer att ändras i takt med dessa förändringar de kommande åren, där vi redan nu kan se 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. Det är ingen slump. Vi ägs inte av eller är bundna till någon specifik CA. Vi rekommenderar den produkt som passar uppgiften bäst, oavsett varumärke.

Hosting-leverantö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 era CAA-records och se till att alla relevanta CA-aktörer är tillåtna.
4. Undvik att pinna certifikat till specifika CA-aktörer i kod eller konfiguration.
5. Håll ett öga på CA-nyheter. Följ Googles och Mozillas trust store-ändringar. Det är där problemen visar sig först.