Valg af certifikatudsteder: Hvorfor fleksibilitet er afgørende

Valg af CA er en sikkerhedsbeslutning

De fleste vælger certifikatudsteder (CA) ud fra pris eller vane, men det er en undervurdering af hvad valget kan betyde. Dit valg af CA påvirker hvor bredt dit certifikat anerkendes, hvor hurtigt du kan reagere hvis din CA mister browsernes tillid, og hvilke certifikattyper du har adgang til.

Hvilken CA du bruger betyder mindre end om du kan skifte CA hurtigt, hvis du bliver nødt til det. Sandsynligheden for, at en bestemt CA bliver tvunget til at stoppe på grund af politiske sanktioner, er lav. Sandsynligheden for, at en CA fejler, ændrer praksis, eller bliver tvunget til at migrere sin rod på en måde, der bryder kompatibiliteten med dele af din infrastruktur, er meget højere. Det er allerede sket flere gange mellem 2024 og 2026.

Entrust-sagen i 2024, hvor Google Chrome fjernede tilliden til Entrust, viste konsekvensen: tusindvis af virksomheder skulle finde en ny CA. De som allerede havde certifikater fra flere CA'er, klarede sig. Resten betalte prisen i overtid og nedetid.

Det nuværende CA-landskab

Der er kun en håndfuld relevante kommercielle CA'er på markedet:

• DigiCert (inkl. RapidSSL, GeoTrust, Thawte): Amerikansk CA med hovedsæde i Lehi, Utah. Verdens største kommercielle CA. Bredest distribuerede rodcertifikat. Overvejende vestlig kundebase i USA og Europa. Ejer varemærkerne fra det tidligere Symantec CA, som i dag udstedes fra DigiCerts infrastruktur.
• GlobalSign (inkl. AlphaSSL): Japansk moderselskab (GMO Internet Group) med drift i Storbritannien og Belgien. International CA med overvejende vestlig kundebase i USA og Europa, suppleret af Japan. AlphaSSL er deres discount-brand, for nylig skiftet til G3-rodcertifikatet. Kan kræve cross-signed intermediate for ældre enheder.
• Sectigo (tidl. Comodo): Amerikansk CA med hovedsæde i Roseland, New Jersey. Billigste af de store CA'er. Stor markedsandel i DV-segmentet. Overvejende vestlig kundebase, koncentreret omkring amerikanske domæner. Benytter ofte cross-signed intermediates. OV/EV-validering afhænger i høj grad af Dun & Bradstreet, hvilket gør processen næsten umulig i Norden, hvor D&B-dækningen er begrænset.
• Entrust: Amerikansk-canadisk CA (Entrust Corporation, hovedsæde i Minnesota og Ottawa). Stadig udbredt i de nordiske lande hos store organisationer og virksomheder, der har eksisterende OV/EV-certifikater i drift. Google og Mozilla stoppede med at stole på nye Entrust-certifikater fra 11. november 2024 (se distrust-afsnittet nedenfor), så eksisterende kunder kan stadig bruge deres certifikater til de udløber, men ny udstedelse skal komme fra en anden CA.
• Let's Encrypt (ISRG): Amerikansk nonprofit (Internet Security Research Group, San Francisco). Gratis DV-certifikater via ACME. Ingen OV eller EV. Største CA på Internettet målt i antal certifikater.
• Certum: Polsk CA (Asseco Data Systems). Egne brandede certifikater dækker overvejende det polske marked. Vores egen analyse af Certums offentlige Certificate Transparency-logs viser, at en stor del af udstedelsen under Certums rødder kommer fra white-brand intermediates drevet af tredjeparter, hvor kinesiske operatører står for en betydelig andel. En mærkbar del af OV/EV-certifikaterne udstedes til aktører i Iran og Nigeria, en anderledes trust-profil end de vestlige CA'er.
• Buypass: Norsk CA. Kundebase næsten udelukkende på det norske marked. Har lukket deres SSL-forretning. Alle eksisterende kunder skal migrere.
• Google Trust Services: Amerikansk, ejet af Google LLC. Udsteder udelukkende gratis DV-certifikater via ACME. Tilbyder hverken OV eller EV.

Oplysninger om CA'ernes profil og markedsposition pr. marts 2026.

Hvad der er sket i CA-verdenen siden 2022

De seneste år har givet flere konkrete eksempler på hvorfor CA-valg er en risikovurdering, ikke kun et indkøb:

• TrustCor (2022): Mozilla, Microsoft og Google fjernede TrustCor fra deres trust-stores efter rapporter koblede selskabet til Packet Forensics, en amerikansk efterretningsleverandør, der har leveret overvågningsteknologi.
• Entrust (2024 → 2025): Google og Mozilla annoncerede i juni 2024, at de stopper med at stole på nye Entrust-certifikater fra 11. november 2024 efter "et mønster af problematisk adfærd" og gentagne brud på CA/Browser Forums Baseline Requirements. Apple fulgte efter og udvidede senere distrust til andre certifikattyper. Det er vigtigt at bemærke, at distrusten kun gælder ny udstedelse: eksisterende Entrust-certifikater fortsætter med at virke til de udløber, og mange store organisationer i Norden har stadig Entrust-certifikater i aktiv drift. Når disse certifikater skal fornys, kan det dog ikke længere ske hos Entrust til offentlig brug.
• Chunghwa Telecom og Netlock (2025): Google annoncerede, at de stopper med at stole på Chunghwa Telecom (Taiwan) og Netlock (Ungarn) fra 1. august 2025 på grund af gentagne compliance-fejl og manglende fremdrift i deres forbedringsplaner.
• Buypass (oktober 2025): Den norske CA stoppede med at udstede SSL-certifikater. Kunder skulle finde en ny CA under tidspres.
• ZeroSSL (gratis CA): Brugere rapporterer højere fejlrater og produktet understøtter ikke wildcard-certifikater. Et eksempel på, at gratis ikke automatisk betyder driftsikkert.

Mønstret er klart: i de fleste tilfælde er det ikke geopolitik, der bringer en CA i problemer, men en kombination af fejludstedelser, manglende compliance og forretningsbeslutninger.

Rodcertifikaternes livscyklus

Alle offentlige SSL-certifikater kæder op til et rodcertifikat, der er forudinstalleret i operativsystemer og browsere. Rodcertifikatets alder og distribution afgør, hvor bredt dit certifikat anerkendes.

Rodcertifikater har en begrænset levetid. Mozilla har formaliseret dette i deres Root CA Lifecycle-policy, som sætter grænser for hvor længe nøglemateriale i en rod-CA må bruges. Det er kryptografisk hygiejne: jo længere en nøgle er i brug, jo større er den akkumulerede risiko. Se også Mozillas oversigt over alle CA'ers rodcertifikat-livscykler.

Mozilla, Apple, Google og Microsoft vedligeholder hver deres trust store med individuelle krav til optagelse og udfasning. Når en rod udløber eller fjernes, stopper alle certifikater i den kæde med at virke.

Den tvungne migration fra gamle rødder

Alle store CA'er er midt i en tvungen migration væk fra deres ældre, bredt distribuerede rodcertifikater. Mozillas Root CA Lifecycle-policy kræver at nøglemateriale i et rodcertifikat ikke må være ældre end 15 år fra den dato nøglen blev oprettet (ikke fra certifikatets udstedelsesdato) for TLS, og 18 år for S/MIME. Datoen bestemmes ud fra den auditerede key ceremony-rapport, eller for ældre rødder (før juli 2012) ud fra certifikatets "Valid From"-dato. Når grænsen nås, fjerner Mozilla roden fra deres trust store, og certifikater udstedt fra den rod stopper med at virke i Firefox.

CA'erne kan ikke forny deres gamle rødder eller forlænge levetiden. De skal oprette helt nye nøglepar, gennemgå en auditeret key ceremony, og søge om optagelse i alle fire store trust stores (Mozilla, Apple, Google, Microsoft) forfra. Mozilla anbefaler at CA'er søger optagelse af deres næste rod mindst 2 år før den gamle rod distrustes. Det tager tid at blive distribueret til alle enheder via OS- og browseropdateringer. Der er indikationer på at Google Chrome på sigt ønsker hyppigere rotation end 15 år, muligvis ned til 5 år, men det er endnu ikke et formelt krav.

Med rødder der er over 20 år gamle, er flere allerede fjernet og flere er på vej ud. Rødder fra før 2006 er allerede distrusted af Mozilla (april 2025), og de næste i køen er rødder fra 2008-2012. De gamle rødder, som er forudinstalleret i praktisk talt alle enheder, forsvinder dermed gradvist og erstattes af nyere rødder med kortere historik og lavere kompatibilitet med ældre systemer. Cross-signing bruges som bro i overgangsperioden, men tilføjer kompleksitet til certifikatkæden. Se Mozillas fulde distrust-tidsplan for alle CA'er.

Fra nu og frem til midt 2029 skal flere CA'er dræbe deres darlings: de gamle, bredt distribuerede rødder som har givet næsten universel kompatibilitet i årevis. Hver gang en rod lukkes, mister kunder med ældre enheder kompatibilitet, og CA'en skal bevise at deres nye rod er lige så pålidelig. Det er en urolig periode for branchen.

Kryptografisk udløb vs browser distrust

Når en rod "dør", er det vigtigt at skelne mellem to datoer: certifikatets udløbsdato (hardkodet i certifikatet, typisk 20-30 år frem) og browser distrust-datoen (den dag browserne fjerner roden fra deres trust store via en softwareopdatering). I dag overlever rødder sjældent til deres faktiske udløbsdato. Browserne dræber dem først.

Kilder: 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

Om datoer i kolonnen "Udfaser": Hvor en CA har offentliggjort en konkret distrust- eller migrations-dato, er den vist. Hvor der ikke er en offentliggjort dato, viser tabellen en estimeret slutdato baseret på Mozillas 15-årige Root CA Lifecycle-grænse fra nøglematerialets oprettelse (markeret med "~"). Den faktiske dato kan være tidligere, hvis CA'en frivilligt udfaser roden, eller hvis Chrome Root Program strammer kravet til kortere rotation.

Alle CA'ers næste generation af rodcertifikater følger samme mønster: dedikerede rødder med ét formål. Hvor de gamle rødder var multi-purpose (TLS, Code Signing, S/MIME, Client Auth fra samme rod), har de nye rødder kun TLS Server Authentication. Det betyder at EKU Client Authentication forsvinder fra alle nye certifikater.

Hvilken generation en CA er på, er i høj grad et spørgsmål om timing af hvornår nøglematerialet blev oprettet. DigiCerts G2-rod blev oprettet i juli 2013, flere år før konkurrenternes nuværende TLS-rødder: GlobalSigns nye R46/E46-rødder er fra ca. 2019, Sectigos R46/E46 fra 2021, og Let's Encrypts kommende Gen Y-rødder er fra 2025 (med cross-signing tilbage til X1 2015 RSA og X2 2020 ECC). Certifikater udstedt fra DigiCerts G2-rod har derfor fortsat den bredeste enhedskompatibilitet helt frem mod cirka 1. januar 2029, hvor sidste praktiske udstedelse forventes. Det er ikke en teknisk fortjeneste; det er tilfældig timing. AlphaSSL (GlobalSign) er allerede skiftet til de nye rødder, hvilket krævede et cross-signed intermediate for at virke i visse klienter. Sectigo har næsten altid brugt cross-signing (bl.a. til deres tidligere AddTrust CA), så overgangen er mindre synlig.

Intermediates, cross-signing og nye krav

Mellem rodcertifikatet og dit servercertifikat ligger et eller flere intermediate-certifikater. Alle CA'er skifter intermediates løbende, og de skal gøre det oftere fremover.

CA/Browser Forum har indført krav om, at intermediates skal være dedikerede til ét formål. En intermediate der udsteder DV-certifikater, må ikke også udstede OV-certifikater. De nye dedikerede TLS-rødder (som GlobalSigns R46/E46) er også begrænset til udelukkende Server Authentication. EKU Client Authentication og andre formål fjernes, så certifikater udstedt fra disse rødder kun kan bruges til TLS-serverautentificering. Se vores artikel om EKU Client Authentication for detaljer om denne ændring.

Når en CA skifter rodcertifikat, udsteder de typisk cross-signed intermediates som ekstra kædecertifikater. Serveren sender dem med i TLS-handshake, så ældre klienter kan bygge en kæde til det gamle rodcertifikat, mens nyere klienter bruger det nye. På Windows er det næsten umuligt at tvinge kæden den rigtige vej via certificate store, fordi det kræver at det gamle rodcertifikat deaktiveres først. Den korrekte fremgangsmåde på Windows Server er at installere det cross-signed intermediate, sikre at det ønskede gamle rodcertifikat er til stede, og deaktivere (ikke slette) det nye rodcertifikat for de tjenester, hvor du vil tvinge kæden ned til det gamle. Det er en manuel proces. Se vores Windows-guide Tving kæden ned til den gamle rod for trin-for-trin opskriften med worked examples for både Sectigo PositiveSSL og GlobalSign/AlphaSSL. Vær især opmærksom på at sletning af det nye rodcertifikat ikke fungerer i praksis: Windows geninstallerer manglende rodcertifikater automatisk via Microsofts root-program. Brug deaktivering i stedet, som beskrevet ovenfor. Hvis du står med en konkret sag, så kontakt vores support. Vores egne guides til intermediate-installation og certifikatkæde-fejlsøgning dækker de tilstødende emner.

Den moderne kæde er kort: servercertifikat → Intermediate CA G3 → Rod CA G3.

Med cross-signing sender serveren en ekstra kæde: servercertifikat → Intermediate CA G3 → Cross-signed Intermediate G2 → Rod CA G2. En klient med G3-roden i sin trust store stopper ved Intermediate G3 og ignorerer resten. En klient der kun har G2-roden, følger den fulde kæde ned til Rod CA G2.

Det ekstra cross-signed intermediate giver ikke kun fordele. Det øger antallet af bytes der sendes i hver TLS-handshake, hvilket tilføjer millisekunder for dem der tæller dem. Og på servere der ikke håndterer det korrekt, som Windows, kan det give problemer med kædevalg fordi certificate store forsøger at bygge den korteste kæde selv.

Forældede intermediates giver fejl

Mange administratorer er vant til at intermediates holder i årevis og genbruger kædefiler fra tidligere installationer. Det fungerer ikke længere. CA'erne skifter intermediates oftere, og hvis serveren sender en forældet kæde, fejler TLS-forbindelsen. Chrome henter selv manglende intermediates via AIA (Authority Information Access), så Chrome-brugere mærker det sjældent. Det er lidt paradoksalt: Google argumenterer for at CRL- og OCSP-opslag er for langsomme og privatlivskrænkende til at browseren bør lave dem, og ignorerer dem derfor helt. Men manglende kædecertifikater henter Chrome gerne selv, fordi det er den del brugerne klager over. Sikkerheden (revocation check) springes over, fordi den kan "forsinke" visningen af siden. Firefox, ældre mobilbrowsere og mange API-klienter henter ikke manglende intermediates. De fejler.

Et velkendt eksempel: Sectigos gamle AddTrust External CA Rod udløb i maj 2020 og forårsagede udbredte problemer, fordi mange servere stadig sendte den forældede AddTrust-kæde i stedet for den nye USERTrust-rod.

Et nyere eksempel: i juni 2025 skiftede Sectigo intermediate på deres PositiveSSL-produkter fra den veletablerede USERTrust RSA-rod til den nye Sectigo Public Server Authentication Root R46 (nøgle fra 2021). Windows-servere byggede automatisk kæden til den nye rod, som ikke var distribueret i alle trust stores endnu, og IIS-installationer fejlede. Vi fik ændringen udskudt for vores kunder, men fra juni 2026 kan den ikke udskydes længere, og Sectigo-kunder vil opleve et større skift i hvilken rodkæde deres certifikater bruger.

Løsningen er enkel: hent altid den aktuelle kæde fra CA'ens dokumentation ved hver installation og genudstedelse. Genbrug ikke gamle kædefiler.

Hvad er CA-fleksibilitet?

CA-fleksibilitet betyder, at din infrastruktur ikke er afhængig af en enkelt certifikatudsteder. Hvis din CA mister browsertillid, bliver købt af en konkurrent, ændrer prismodel eller simpelthen ikke kan levere hurtigt nok, kan du skifte uden at lægge dine processer om.

Praktisk kræver det:

1. Adgang til mere end én CA. Hav aftaler med mindst to CA'er, så du kan skifte uden at starte en indkøbsproces under tidspres.
2. Mulighed for hurtigt at skifte alle certifikater. Med ACME-automatisering og ARI (ACME Renewal Information) kan din klient selv opdage hvornår et certifikat bør fornyes før tid, f.eks. ved et CA-skift eller en tilbagekaldelse. Uden automatisering er et CA-skift et manuelt projekt der tager uger.
3. Fleksible nøglestørrelser. Det bør være let at ændre nøgletype og -størrelse i din konfiguration. RSA 2048 er den svageste nøgle der stadig bruges til SSL og er allerede begrænset for S/MIME og Code Signing, hvor certifikater skal holde i flere år.

ECDSA-nøgler er markant hurtigere i TLS-handshake end RSA. Det er især relevant for servere med mange samtidige forbindelser. Minimum bør være RSA 3072 eller ECDSA P-256.

Quantum computing og certifikatnøgler

På en korrekt konfigureret server bruges certifikatets nøgle kun til autentificering under TLS-handshake. Når serveren bruger ECDHE eller DHE key exchange (hvilket alle moderne TLS 1.2- og TLS 1.3-konfigurationer gør), genereres en unik sessionsnøgle for hver forbindelse via Perfect Forward Secrecy (PFS). Den faktiske datakryptering håndteres af disse ephemeral sessionsnøgler via cipher suites som AES-256-GCM, ikke af certifikatets nøgle.

Det betyder at "save now, decrypt later"-scenariet, hvor en angriber opsamler krypteret trafik i dag og dekrypterer den med en fremtidig quantum computer, ikke påvirkes af certifikatets nøglestørrelse. Sessionsnøglerne er unikke per forbindelse og eksisterer ikke efter sessionen slutter. Det forudsætter dog at serveren ikke tillader ældre cipher suites uden PFS (f.eks. TLS_RSA_WITH_AES_256_CBC_SHA), hvor certifikatets private nøgle bruges direkte til key exchange. Med sådanne ciphers aktiveret er al opsamlet trafik i fare den dag nøglen kan brydes.

Den reelle bekymring med quantum computing er real-time angreb: når de første stater får kapacitet til at bryde certifikatnøgler, kan de potentielt udføre usynlige man-in-the-middle angreb mod følsomme systemer ved at generere falske certifikater eller blot udgive sig for et ægte certifikat i realtid. For sådanne systemer kan det give mening at bruge nøgler der tager længere tid at bryde. Når de første quantum computere kan bryde RSA 2048, vil der sandsynligvis gå 1-3 år før RSA 4096 også kan brydes. Selve beregningen per nøgle tager formentlig timer til dage, så den absolutte tid per nøgle er ikke den afgørende faktor. Det er den samlede overgangsperiode hvor stærkere nøgler endnu ikke er sårbare.

Det er derfor mindst lige så vigtigt at sikre at serveren kun tilbyder moderne cipher suites. Deaktiver alle protokoller fra TLS 1.1 og lavere, samt ciphers uden PFS, fx alle CBC-mode ciphers. Brug IIS Crypto på Windows eller Mozilla SSL Configuration Generator til at konfigurere dette korrekt. TLS 1.3 understøtter udelukkende PFS-baserede cipher suites og er det sikreste valg.

5. Ingen CA-specifikke afhængigheder i koden. Hardkodede intermediate-certifikater, pinning til specifikke udstedere (HPKP) eller CA-specifikke API-integrationer gør dig sårbar.
6. CAA records der tillader flere CA'er. Hvis din DNS kun tillader én CA via CAA records, kan du ikke skifte hurtigt. Tilføj alle de CA'er, du potentielt vil bruge. Se vores guide til CAA records.

Hvorfor én CA ikke er nok

Ud over Entrust-sagen har vi set flere eksempler på, at CA'er pludselig ikke kan levere:

• Symantec 2017: Google fjernede tilliden til alle Symantec-certifikater (inkl. GeoTrust, Thawte, RapidSSL). DigiCert overtog forretningen, men alle eksisterende certifikater skulle genudstedes.
• StartCom/WoSign 2016: Begge CA'er fjernet fra trust stores efter systematisk misbrug.
• GlobalSign OCSP-nedbrud 2016: GlobalSign udsendte ved en fejl OCSP-svar, der markerede alt som tilbagekaldt. Svarene blev cachet af browsere og CDN'er, og mange sites med GlobalSign-certifikater var utilgængelige i flere dage. Kunder der havde en alternativ CA, kunne skifte. Resten ventede.
• GlobalSign intermediate-fejl 2020: En teknisk fejl i GlobalSigns intermediate CA'er førte til tilbagekaldelse af tusindvis af certifikater.
• Buypass 2025: Den norske CA stoppede med at udstede SSL-certifikater. Kunder, der kun brugte Buypass, skulle finde en ny CA under tidspres.

Ingen CA er immun over for problemer. Spørgsmålet er ikke om det sker, men hvornår. Det giver mening at kunne skifte CA, eller bedre endnu: allerede have forbindelse til mere end én.

CA'ernes styrker og svagheder

De tre store CA'er har forskellige fokusområder:

• DigiCert har fokuseret på tekniske løsninger og platformsintegrationer. De har aktuelt det mest kompatible rodcertifikat. Til gengæld stiger prisen hvert år, og support og account management foregår på engelsk fra Sydafrika eller Utah, USA, ikke lokaliseret til europæiske sprog og tidszoner.
• GlobalSign har holdt fokus på OV/EV-løsninger med nem validering, især i Europa og Skandinavien. Vi udfører OV-validering på vegne af GlobalSign på dansk og svensk, typisk inden for en time.
• Sectigo er klart billigst på DV-certifikater. OV/EV-validering af skandinaviske virksomheder er en helt anden historie: det kræver altid direkte kontakt til Sectigos support og helst verifikation via Dun & Bradstreet. Vi har derfor valgt at fjerne Sectigo OV/EV-produkter fra vores sortiment af den grund.

Indtil GlobalSign ændrede rodcertifikat på AlphaSSL, anbefalede vi AlphaSSL for kombinationen af pris og kompatibilitet. Med skiftet til G3 og de kompatibilitetsproblemer det medførte, er RapidSSL og Thawte 123 nu de billigste alternativer med bred kompatibilitet.

Alle CA'ernes rodcertifikater har faste udløbsdatoer, og de planlægger allerede næste generation. Vores anbefalinger vil skifte i takt med disse ændringer de næste år, hvor vi allerede nu kan se der bliver udskiftning af flere rodcertifikater.

Selv-hostet ACME kan også låse dig fast

Mange organisationer der har sat ACME op selv tror, de har vundet agilitet. I praksis har de ofte byttet én slags låsning ud med en anden. ACME-klienten på hver server (certbot, win-acme, acme.sh) er konfigureret mod én CA, typisk Let's Encrypt, med sin egen account-key, sine egne hooks og sine egne DNS API-credentials. Hvis Let's Encrypt en dag distrustes eller ændrer praksis, skal hver server omkonfigureres. Mange af de scripts er udokumenterede og passes kun, når de fejler.

Centraliseret certifikatstyring afkobler udskiftningsmekanikken fra CA-valget. Du beslutter på ét sted hvilken CA der bruges, og når du skifter, sker det automatisk på alle endpoints i stedet for som et manuelt projekt på 50 servere.

Hvad CT-logs kan afsløre om en CA

Certificate Transparency-logs er offentlige. De viser ikke kun det enkelte certifikat, men også hvilken CA der har udstedt det og hvilken intermediate, det er signeret af. Det giver dig mulighed for at undersøge en CA's praksis før du gør forretning med den.

Vi overvejede selv at tilføje Certum (Asseco Data Systems, Polen) som certifikatleverandør, fordi de er en EU-baseret CA og ville udvide den jurisdiktionsmæssige spredning i vores portefølje. Vi gennemgik derfor deres Certificate Transparency-logs. Vi kan ikke udtale os om absolutte tal med sikkerhed, da CT-log-udtræk kan være ufuldstændige, men der tegnede sig et tydeligt mønster: en betydelig del af Certums OV/EV-udstedelse gik til virksomheder uden for EU, primært i Kina, Iran og Nigeria. Polen var fortsat det største enkeltmarked, men ikke dominerende. Ser man derudover på alle certifikater nogensinde udstedt under Certums rødder, kommer en stor andel fra white-brand intermediates drevet af kinesiske operatører (blandt andre TrustAsia, WoSign, WoTrus og XinNet). Det er ikke nødvendigvis ulovligt, men det er en anderledes risikoprofil end de vestlige CA'er, og vi vurderede, at det ikke var en profil, vi ville byde vores kunder. Vi gik ikke videre med Certum.

En CA's offentlige udstedelseshistorik er en datakilde du selv kan tjekke, og bør tjekke, hvis du er i tvivl. Det handler ikke om at hænge én CA ud, men om at gøre den due diligence enhver kunde har adgang til. Værktøjer som crt.sh giver dig adgang til CT-logs uden særlige værktøjer.

Geopolitisk risiko: virkelig, men sjælden

Efter sanktionerne mod Rusland i 2022 mistede flere russiske finans- og forsvarsselskaber adgang til certifikater fra US-baserede CA'er. Ifølge medieomtale skulle Den Internationale Straffedomstols chefanklager, Karim Khan, have mistet adgang til sin Microsoft-mail efter sanktioner fra Trump-administrationen. Microsoft har afvist denne fremstilling, så historien står ikke entydig.

Sanktioner og adgangstab er reelle scenarier, men de rammer få organisationer. For langt de fleste kunder er den realistiske risiko en helt anden: en CA der laver en fejl (Entrust, Chunghwa, Netlock), en CA der ændrer forretning (Buypass), eller en rod-migration der bryder kompatibilitet (Let's Encrypt Gen Y på Ubuntu 24.04 LTS, GlobalSign R5/R6 i juli 2026). Det er det, du skal være parat til at håndtere, og en CA's nationalitet løser det ikke alene. Agilitet gør.

FairSSLs tilgang

Vi sælger certifikater fra tre uafhængige CA'er: DigiCert, GlobalSign og Sectigo. Det er et bevidst valg: vi er ikke ejet af eller bundet til nogen CA. Vi anbefaler det produkt, der passer til opgaven, uanset brand.

Vi er ærlige om jurisdiktionen i den portefølje vi tilbyder: DigiCert og Sectigo er amerikanske, mens GlobalSign har japansk moderselskab (GMO Internet Group) med drift i Storbritannien og Belgien. Det er ikke "EU-suverænitet", men det er reel jurisdiktionsmæssig spredning på tværs af tre uafhængige aktører. For kunder, der specifikt prioriterer en non-US-baseret CA, er GlobalSign vejen i vores portefølje.

Hosting-udbydere og IT-konsulenter der videresælger certifikater bør have aftaler med mindst to CA'er. Det reducerer eksponeringen ved CA-problemer og giver kunderne en reel backup-plan. Hvor det giver mening kan vi også levere CA-bundlede CLM-løsninger (DigiCert TLM, Sectigo SCM, GlobalSign Atlas) eller vores egen multi-CA-løsning sslbrain, alt afhængigt af, hvad der passer til kundens situation.

Anbefalinger

1. Brug mindst to CA'er i produktion.
2. Automatisér udstedelse og installation med ACME, så et CA-skift er trivielt.
3. Kontrollér jeres CAA records og sørg for, at alle relevante CA'er er tilladt.
4. Undgå at pinne certifikater til specifikke CA'er i kode eller konfiguration.
5. Hold øje med CA-nyheder. Følg Googles og Mozillas trust store-ændringer. Det er der, problemerne viser sig først.