eMudhras komprometterade CA-nycklar: vad företag bör kontrollera och åtgärda nu

Lördagen den 17 oktober 2026 rapporterade en säkerhetsforskare att åtta mellanliggande certifikatutfärdare som drivs av eMudhra, en indisk certifikatutfärdare, hade privata nycklar som vem som helst kunde räkna fram ur de offentliga certifikaten. Samtliga nycklar var tal mindre än 256. En av dem var talet 4. Sex av de åtta kunde utfärda TLS-certifikat som Apple, Google, Microsoft och Mozilla litar på; de andra två kunde signera programvara för Windows.

Chrome blockerade de sex TLS-nycklarna en timme och fyrtio minuter efter rapporten, och Firefox samma kväll. För den som surfar på webben var faran över på lördagskvällen.

För allt annat var den inte över. Servrar, containrar, Java-applikationer, Python-skript, betalintegrationer och uppkopplade enheter kontrollerar certifikat mot sin egen kopia av listan över betrodda certifikatutfärdare, och de flesta av de kopiorna ändras bara när någon installerar en uppdatering. Fram till dess godtas ett certifikat för vilken domän som helst som äkta, om det är signerat med en av de här nycklarna, och nycklarna har varit offentliga sedan den 20 oktober.

Samma vecka började GoDaddy återkalla 404 607 certifikat, eftersom policyinformationen i dem inte stämde med företagets egna publicerade dokument. Kunderna fick själva ladda ner och installera ersättningscertifikaten.

Den här guiden är till för dem som måste svara på frågan ”berörs vi?”: IT- och driftansvariga, CTO:er och grundare vars verksamhet bygger på en webbplats, ett API eller en uppkopplad produkt. Den går igenom vad som hände, utifrån de incidentrapporter som Mozilla, Google, eMudhra, GoDaddy och programvaruleverantörerna har publicerat; vad du ska kontrollera i dag; vad du ska uppdatera den här veckan; och vad du bör ha på plats så att nästa incident av det här slaget blir rutin. Allt här avser läget den 22 oktober 2026, och incidenten är fortfarande öppen.

Vad som hände

eMudhra skapade de åtta mellanliggande certifikaten vid en nyckelceremoni den 30 april 2025. Företagets redogörelse, publicerad i Mozillas incidentärende den 19 oktober: ett test av ett steg med inkapsling och uppackning av nycklar (key wrap och unwrap), godkänt som en avvikelse från den vanliga proceduren, hade ett fel som skapade en andra, svag uppsättning nycklar i hårdvarusäkerhetsmodulen (HSM) bredvid de avsedda. Etiketterna liknade varandra, de svaga nycklarna användes av misstag för att skapa certifikatbegärandena, och eMudhras rotcertifikat signerade dem. Samma begäranden gick till Sectigo, som korssignerade alla åtta från sitt rotcertifikat AAA Certificate Services den 14 maj 2025. eMudhra säger att företaget ”ännu inte har bekräftat den exakta grundorsaken”.

Mozilla beskrev resultatet: ”Privata P384-nycklar är slumpmässigt valda heltal mellan 1 och gruppens ordning. De 8 berörda nycklarna använde alla heltal mindre än 256.” Mozilla fick rapporten kl. 20:06 UTC och tog själv fram nycklarna kl. 21:48, ”utan någon kännedom om vilken metod den ursprungliga rapportören använde”. Forskaren säger att han hittade dem med paranoid_crypto, Googles bibliotek med öppen källkod, ”direkt ur lådan”. De svaga nycklarna hade ingått i offentligt betrodda kedjor i nästan 18 månader.

De åtta certifikaten:

Varje nyckel finns i två certifikat. Det ena utfärdades av eMudhras emSign Root TLS CA - G3 eller emSign Root CS CA - G3, som i sin tur leder upp till emSign ECC Root CA - G3; det andra är Sectigos korscertifikat från AAA Certificate Services. Den andra vägen är viktig, eftersom vissa trust stores som aldrig har innehållit något rotcertifikat från eMudhra fortfarande litar på det gamla rotcertifikatet från Sectigo.

Har någon blivit attackerad?

Ingen har rapporterat missbruk, och för webbläsare finns det goda skäl att tro att inget har förekommit. Chrome accepterar, liksom andra klienter som kräver Certificate Transparency (CT), bara certifikat som har registrerats i de offentliga CT-loggarna. Google: inga TLS-certifikat med kedja till de här sex mellanliggande certifikaten loggades före blockeringen, så ”inga falska certifikat som utfärdats av dessa certifikatutfärdare kunde ha använts mot klienter som kräver CT”.

Utanför webbläsaren ser bilden annorlunda ut. Mozillas incidentsida: ”många klienter utanför webbläsarnas ekosystem kräver inte Certificate Transparency. Vi vet inte om angripare utnyttjade den bristfälliga nyckelgenereringen för att angripa dessa klienter.” Det fönstret öppnades våren 2025 och stängs för varje klient först när den uppdateras. eMudhra säger att företaget inte känner till några belägg för att nycklarna hade tagits fram före offentliggörandet, och Cloudflare säger att dess genomgång inte hittade något aktivt utnyttjande på företagets tjänster.

Nu när nycklarna är offentliga krävs ingen skicklighet för att förfalska ett certifikat. Mozillas incidentsida listar testservrar som visar upp certifikat utfärdade med de komprometterade nycklarna, så att vem som helst kan testa sina klienter mot dem (kommandona finns nedan).

Vad ett förfalskat certifikat möjliggör: den som kan fånga upp trafiken mellan din programvara och en tjänst som den anropar (på ett delat nätverk, via en komprometterad router eller ett förgiftat DNS-svar) kan utge sig för att vara den tjänsten, läsa det som din programvara skickar, inklusive API-nycklar och personuppgifter, och ändra det den tar emot. Programvara som signerats med någon av de två nycklarna för kodsignering skulle ha godkänts av Windows signaturkontroll tills Microsofts blockering nådde datorn.

Vilka som berörs

Det finns tre separata problem, och ett och samma företag kan ha alla tre.

1. Programvara som fortfarande litar på de komprometterade nycklarna

Det här problemet har nästan alla företag: varje program som gör HTTPS-anrop, vars trust store fortfarande innehåller emSign ECC Root CA - G3 eller AAA Certificate Services och som inte har fått någon blockering av de åtta nycklarna. Typiska ställen:

• Linuxservrar och containerimages som byggts före den 20 eller 21 oktober. En opatchad Debian 12 litar till exempel på båda kedjorna.
• Körmiljöer för programspråk som levererar en egen lista: Node.js, Pythons certifi, Javas cacerts, CA-paketet i Composer för PHP, Rusts webpki-roots.
• Kommandoradsverktyg i macOS. Mozillas incidentsida säger att de inbyggda curl, git, python3, perl, ruby och openssl kontrollerar certifikat mot /etc/ssl/cert.pem utan att kontrollera återkallelser, och att Apple inte har uppdaterat den filen.
• Windowsdatorer som inte får Microsofts automatiska uppdateringar av listan över otillåtna certifikat, oftast för att en grupprincip stänger av dem eller för att nätverket är offline.
• Appliances, enheter och programvara från tredje part som har en egen CA-fil inbyggd, till exempel lastbalanserare, VPN-gateways, SDK:er och inbyggda styrenheter.

Varje körmiljö måste kontrolleras för sig. I ett test som vi gjorde den 22 oktober accepterade en opatchad Debian 12-maskin med Node.js 24.18 kedjan som slutar i eMudhras rotcertifikat och avvisade den som slutar i Sectigos, medan Python på samma maskin accepterade båda.

2. Företag vars egna certifikat ligger under det borttagna rotcertifikatet

Mozilla och Linuxdistributionerna har tagit bort emSign ECC Root CA - G3, och Chrome följer efter den 27 oktober. Giltiga certifikat under det rotcertifikatet slutar fungera i varje klient i takt med att klienten uppdateras. Googles instruktion: den som driver en webbplats med ett sådant certifikat ”måste omedelbart skaffa och installera ett nytt TLS-certifikat från en annan PKI-hierarki som ingår i Chrome Root Store”.

Den 21 oktober räknade Chrome i CT cirka 30 800 certifikat under rotcertifikatet som inte hade gått ut. Av dem kom 30 791 från två mellanliggande certifikat hos InCommon, den certifikattjänst som Internet2 driver för amerikanska universitet och forskningsinstitutioner och som utfärdar ECC-certifikat via CERTInext, eMudhras plattform. 18 kom från eMudhras egna mellanliggande certifikat. eMudhra säger att cirka 30 000 certifikat behöver migreras, varav cirka 97 % utfärdats via ACME, och att företaget utfärdar ersättningar från en annan hierarki.

Om din webbplats ligger bakom Cloudflare i läget Full (strict) och origin-servern visar upp ett certifikat under det här rotcertifikatet, säger Cloudflare att det indragna förtroendet ”skulle orsaka avbrott”, och ber kunderna: ”Gå igenom dina anpassade origin-certifikat och serverkonfigurationer”.

RSA-certifikat från eMudhras andra rotcertifikat, emSign Root CA - G1, berörs hittills inte. Mozilla säger att det inte tar bort det rotcertifikatet ”i nuläget”; Chrome ”undersöker noggrant den fortsatta inkluderingen av eMudhras återstående CA-certifikat”. Om du är beroende av certifikat från eMudhra eller CERTInext av något slag, ordna en andra certifikatutfärdare redan nu.

3. GoDaddys kunder

GoDaddys fall har ingenting med eMudhra att göra, men det slog till samma vecka och mot många fler webbplatser. Den 15 oktober rapporterade GoDaddy till Mozilla att certifikat från dess hierarkier GoDaddy och Starfield innehöll certifikatpolicyinformation (policy-OID:er och länkar till CPS) som inte stämde med profilerna i dess egen CP/CPS, det dokument där en certifikatutfärdare anger vad den utfärdar. Det är inte en säkerhetsbrist i certifikaten. Enligt Baseline Requirements, de regler som varje offentlig certifikatutfärdare följer, är det ändå ett skäl att återkalla dem inom fem dagar.

Sammanlagt berördes 404 607 certifikat, varav 396 055 domänvaliderade. GoDaddy återkallade 170 566 före tidsfristen den 18 oktober kl. 23:45 UTC och hade återkallat 227 422 till nästa morgon; enligt företagets kundmeddelande återkallades resten den 21 oktober. GoDaddy utfärdar certifikaten på nytt, men det är kunden som måste installera dem: ”besökare på din webbplats kan se säkerhetsvarningar, och din webbplats kan bli otillgänglig tills ett nytt certifikat har installerats.”

Vad du ska kontrollera i dag

1. Vad skickar dina egna servrar? För varje publikt värdnamn listar du utfärdarna i den kedja som servern visar upp:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

En rad som nämner eMudhra, emSign, någon av certifikatutfärdarna EM ... G3B eller G3C, eller InCommon Intermediate CA - DVG3C, OVG3C eller EVG3C betyder att certifikatet måste bytas ut före den 27 oktober. AAA Certificate Services ensamt är normalt, eftersom många vanliga Sectigo-kedjor fortfarande innehåller det. För e-post- och katalogtjänster lägger du till -starttls smtp (eller imap, ldap) och rätt port. Ta med interna värdar, lastbalanserare och origin-servrar bakom ett CDN.

2. Vad har utfärdats för dina domäner? CT listar varje certifikat som en offentlig certifikatutfärdare har utfärdat för dina namn, även sådana som ingen på företaget minns att någon har beställt:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

Utdata visar också vilka certifikatutfärdare ditt företag faktiskt använder, och det är början på den inventering som beskrivs längre ned.

3. Litar dina klienter på de komprometterade nycklarna? Mozillas testservrar visar upp certifikat som utfärdats under de komprometterade nycklarna, så ett certifikatfel är det önskade resultatet. Testa båda familjerna: den första värden leder till eMudhras rotcertifikat, den andra till Sectigos, och en trust store kan underkänna den ena och godkänna den andra.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl svarar bara för curl. Kör samma förfrågan genom varje applikations egen TLS-stack, i den miljö där applikationen körs:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

De två Python-raderna är inte överflödiga: urllib använder operativsystemets trust store, requests använder certifi. Upprepa varje rad med värden dv-g3b-aaa-emudhra. För Java gör du ett valfritt HTTPS-anrop till testservrarna från den JVM det gäller, och listar om dess trust store innehåller något av de två rotcertifikaten (Java 9 eller senare; på Java 8 använder du -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Att ett rotcertifikat finns i en trust store bevisar inte i sig att du är exponerad, eftersom Go, Node.js, Deno och Rusts rustls-webpki nu blockerar de åtta nycklarna oavsett vad som står i den. Testservrarna avgör saken.

4. Windowsparken. Microsoft har inte publicerat något om incidenten, men listan över otillåtna certifikat som Windows laddar ner automatiskt har blockerat alla åtta nycklar sedan den 20 oktober. Undantagen är datorer där en grupprincip stänger av automatiska uppdateringar av rotcertifikat och nätverk utan väg till Windows Update; där måste listan levereras på annat sätt. certutil -verifyCTL Disallowed visar den kopia som en dator har cachat. Mozillas incidentsida erbjuder ett skript för enskilda datorer och säger att det ”inte rekommenderas för företagshanterade enheter”.

5. GoDaddy-certifikat. Kontrollera vilket certifikat varje server faktiskt visar upp:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Om utfärdaren är GoDaddy eller Starfield jämför du serienumret med certifikaten i ditt GoDaddy-konto. Där GoDaddy visar ”Install your new certificate” (installera ditt nya certifikat) har servern fortfarande det återkallade.

En regel gäller hela tiden: trolla inte bort ett fel genom att stänga av certifikatverifieringen. Med Cloudflares ord: ”Det är viktigt att inte lösa de här felen genom att stänga av verifieringen.” En klient som inte verifierar litar på varje förfalskat certifikat, inte bara på de här.

Vad du ska uppdatera den här veckan

Det finns två sorters rättelser. Att ta bort de två rotcertifikaten ur en trust store stänger varje väg för de klienter som använder den, men det får också de giltiga certifikaten under dem att sluta fungera. Att blockera de åtta nycklarna utifrån hashen av deras publika nyckel, som Go, Node.js, Deno, Electron, rustls-webpki, Composer och Windows gör, täpper till hålet utan att något annat går sönder. Där din plattform erbjuder det andra alternativet är det att föredra.

”Ännu inte” betyder att ingenting hade publicerats fram till den 22 oktober. Kontrollera igen innan du planerar utifrån det.

Fyra saker ställer ofta till det för team:

• Containerimages behåller den gamla listan. En image som byggts före den 20 eller 21 oktober litar på nycklarna tills den byggs om på en uppdaterad basimage, och att hämta samma tagg hjälper först när basimagen har byggts om. Bygg om, driftsätt på nytt och fråga leverantörerna vars images du kör.
• Processer behåller det de har läst in. Ett program läser sin trust store när det startar, så starta om långlivade tjänster efter uppdateringen. Node.js tillägger att TLS-sessioner som återupptas från tiden före uppgraderingen inte kontrolleras igen.
• Applikationer har med sig egna CA-filer. SDK:er och applikationer levereras ofta med en egen cacert.pem eller ca-bundle.crt. Sök efter dem i kodförråd och images, till exempel med find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, och räkna med fler än en: pip har till exempel en egen kopia av certifi.
• Enheter väntar på sin leverantör. Fråga varje leverantör skriftligt vilken trust store produkten använder och när uppdateringen kommer. Till dess litar enheten på förfalskade certifikat för varje tjänst den anropar, så begränsa vad den kan nå.

Om du tar bort AAA Certificate Services för hand, som Debian, Ubuntu ESM, Fedora och Red Hats tillfälliga lösning gör, testa efteråt anslutningarna till tjänster med Sectigo-certifikat: en del äldre servrar skickar fortfarande en kedja som slutar i det rotcertifikatet.

Vad du bör ha på plats före nästa incident

Att en certifikatutfärdare lämnar så här svaga nycklar är sällsynt. Massåterkallelser är det inte. Det här är de stora under 2026 som finns registrerade i Mozillas buggspårare:

Inget av de fem fallen var ett säkerhetsfel. I vart och ett stämde ett certifikat inte med certifikatutfärdarens eget dokument, och Baseline Requirements (avsnitt 4.9.1.1) kräver ändå återkallelse inom fem dagar. När en nyckel har komprometterats, eller när domänvalideringen inte går att lita på, är tidsfristen 24 timmar. Ingen kan förlänga den åt dig. När DigiCert 2024 återkallade 83 267 certifikat skrev Chrome Root Program att programmet ”inte har befogenhet att bevilja undantag”; en kund fick ett domstolsbeslut som stoppade återkallelsen av dess certifikat, och beslutet upphävdes fyra dagar senare.

Hur ersättningarna gick till säger mycket. I juli använde HARICA ACME Renewal Information (ARI) för att säga åt kundernas ACME-klienter att förnya i förtid, och utfärdade andra certifikat på nytt själv; i den större av sina två återkallelser hade 87 % av de berörda namnen ersatts när tidsfristen gick ut. GoDaddy, vars kunder själva laddar ner och installerar varje ersättning, hade återkallat 42 % av sina berörda certifikat vid sin tidsfrist.

Förnyelsecykeln krymper i vilket fall:

• Enligt omröstningen SC-081 i CA/Browser Forum har offentliga TLS-certifikat varit begränsade till 200 dagar sedan den 15 mars 2026. Gränsen sjunker till 100 dagar den 15 mars 2027 och till 47 dagar den 15 mars 2029, då domänvalidering bara får återanvändas i 10 dagar.
• Let's Encrypt ändrar sin standard till certifikat på 64 dagar den 10 februari 2027, och till 45 dagar ett år senare.
• Offentliga TLS-certifikat förlorar klientautentiseringen. Let's Encrypt slutade utfärda certifikat för klientautentisering den 8 juli 2026, och Chrome Root Program kräver att certifikat som utfärdas från och med den 15 mars 2027 bara gäller serverautentisering. Om du använder offentliga certifikat som klientcertifikat för ömsesidig TLS (mutual TLS), vilket är vanligt i API-integrationer mellan företag, behöver de anslutningarna en privat certifikatutfärdare.

Vid 100 dagar, och sedan vid 47, slutar manuell installation av certifikat att vara ett realistiskt alternativ. Ett företag som automatiserar för det schemat är också redo för nästa massåterkallelse. Det här krävs:

1. Vet vad du har, åt båda hållen. En lista över varje certifikat som dina servrar visar upp, med värdnamn, utfärdare, utgångsdatum, förnyelsemetod och ägare. En andra lista över varje trust store som din programvara förlitar sig på: operativsystemets paket, varje programspråks CA-paket, varje CA-fil inuti en applikation eller enhet. CT-sökningen ovan är början på den första listan; en programvaruförteckning (SBOM) eller en beroendeinventering är början på den andra.
2. Automatisera utfärdande och installation. ACME överallt där det kan köras, med ARI (RFC 9773) så att en certifikatutfärdare kan säga åt dina klienter att förnya i förtid. Där en enhet inte kan köra ACME använder du leverantörens automatisering, eller terminerar TLS framför den på något som kan.
3. Ha en andra certifikatutfärdare redo. Ett fungerande ACME-konto hos en andra utfärdare, testat, och CAA-poster i DNS som tillåter båda. När förtroendet för en utfärdare dras in, eller när den återkallar i stor skala, blir bytet en konfigurationsändring.
4. Bevaka CT för dina domäner. Få ett larm för varje nytt certifikat för dina namn. Då får du veta om oväntad utfärdning samma dag som den sker.
5. Behandla trust stores som beroenden. Uppdatera dem genom den vanliga patchningen, och bygg om images enligt ett schema i stället för bara när koden ändras.
6. Skriv körboken utifrån de två klockorna. 24 timmar och fem dagar: vem som beslutar, vem som har åtkomst till varje system, vilka system som kräver manuella steg, hur du når varje leverantör. Öva den en gång om året genom att byta certifikat på en tjänst som tål ett misstag. Offentliga certifikatutfärdare har sedan 2025 varit skyldiga att ha och testa en egen plan för massåterkallelse; deras kunder behöver den andra halvan.

Om du tillverkar produkter som andra driver

Om din produkt innehåller en trust store (en enhet, en installerad applikation, ett SDK) är dina kunder skyddade först när din uppdatering når dem. Leverera den, och tala om för kunderna vilka versioner som är rättade. Mozillas råd till dem som förvaltar trust stores: blockera de åtta mellanliggande certifikaten om din programvara kan, och annars ”överväga om det är lämpligt att ta bort förtroendet för de rotcertifikat som signerade dessa mellanliggande certifikat”.

Cyberresiliensförordningen (CRA) är tillämplig här på två sätt. Dess rapporteringsskyldighet, som gäller sedan den 11 september 2026, omfattar aktivt utnyttjade sårbarheter, och inget utnyttjande har rapporterats i det här fallet. Dess väsentliga krav, som gäller från den 11 december 2027, innefattar att sårbarheter ska kunna åtgärdas genom säkerhetsuppdateringar; en produkt vars lista över betrodda certifikat inte går att uppdatera skulle inte uppfylla dem. Kunder som omfattas av NIS2 kommer att fråga sina leverantörer hur snabbt de hanterade det här, och det hjälper att ha svaret nedskrivet.

Vad som fortfarande är öppet

• eMudhras återstående rotcertifikat. Chrome ställde tolv frågor till eMudhra den 21 oktober och har inte meddelat något beslut om emSign Root CA - G1. Mozilla tar inte bort det ”i nuläget”.
• eMudhras migreringsväg. Företaget sa till Mozilla att det skulle flytta kunderna till sin G1-hierarki (RSA); dess statussida talar om ”en alternativ, oberoende driven, offentligt betrodd CA-hierarki”. Chrome har frågat vilken.
• Microsoft och Apple. Ingen av dem har publicerat ett uttalande eller tagit bort något av rotcertifikaten ur sin trust store.
• Väntande rättelser. Red Hat, Amazon Linux, Temurin och Corretto hade inte levererat något den 22 oktober; Buns rättelse var sammanslagen men inte släppt.
• Grundorsaken. eMudhra har inte bekräftat den, och har sagt att företaget kommer att verifiera om varje nyckelceremoni det har genomfört.
• Sectigo. I ett separat ärende, öppet sedan den 5 september, har Sectigo avböjt att återkalla certifikat vars utökade nyckelanvändning (extended key usage) inte stämde med en mening i företagets CPS, med argumentet att meningen var tvetydig. Den 18 oktober uppgav Sectigo att cirka 72 miljoner av dem fortfarande var aktiva. Några deltagare i den offentliga diskussionen har krävt att förtroendet för Sectigo dras in; inget rotprogram har meddelat något beslut. Företag med Sectigo-certifikat bör följa ärendet.

Var du får hjälp

Ett certifikatproblem ger sig sällan till känna som ett certifikatproblem. Det visar sig som en kassa som slutar laddas, en integration som slutar synkronisera eller en enhet som slutar rapportera, oftast en helg. Vi hjälper företag att ta sig igenom veckor som den här utan driftavbrott, och att sätta upp saker så att nästa gång blir rutin:

• En exponeringskontroll. Vi tar reda på var dina system öppnar eller tar emot TLS-anslutningar, vilken trust store vart och ett använder och vilka certifikat dina servrar visar upp, inklusive containrar, Java-tjänster, integrationer med banker, betal- och logistikleverantörer samt enheter.
• Rättelserna. Uppdateringar, ombyggda images, blockerade nycklar eller utbytta certifikat, genomförda via din ändringsprocess och bekräftade mot Mozillas testservrar.
• Automatisering för 2027. ACME med ARI på servrar, lastbalanserare och appliances, en andra certifikatutfärdare, CAA-poster, CT-bevakning och en körbok, redo för certifikat på 100 dagar från den 15 mars 2027.
• Systemen som ingen vill röra. Gamla Java-applikationer, appliances och inbyggda klienter med egna trust stores är det som vår tjänst för underhåll av äldre system och kod är till för.

Om du inte är säker på om du berörs, skriv till office@c9group.dev med de domäner och plattformar du kör, eller boka ett samtal. Vi berättar vad du ska kontrollera först.