Kompromitteringen af eMudhras CA-nøgler: hvad virksomheder bør tjekke og rette nu

Lørdag den 17. oktober 2026 rapporterede en sikkerhedsforsker, at otte mellemcertifikater (intermediate CA'er), som den indiske certifikatudsteder eMudhra driver, havde private nøgler, som enhver kunne regne ud fra de offentlige certifikater. Hver eneste af nøglerne var et tal mindre end 256. En af dem var tallet 4. Seks af de otte kunne udstede TLS-certifikater, som Apple, Google, Microsoft og Mozilla har tillid til; de to andre kunne signere Windows-software.

Chrome blokerede de seks TLS-nøgler en time og fyrre minutter efter rapporten, og Firefox gjorde det samme aften. For folk, der surfer på nettet, var faren ovre lørdag aften.

For alt andet var den ikke ovre. Servere, containere, Java-applikationer, Python-scripts, betalingsintegrationer og forbundne enheder tjekker certifikater mod deres egen kopi af listen over betroede certifikatudstedere, og de fleste af de kopier ændres kun, når nogen installerer en opdatering. Indtil da går et certifikat for et hvilket som helst domæne, der er signeret med en af disse nøgler, igennem som ægte, og nøglerne har været offentlige siden 20. oktober.

Samme uge begyndte GoDaddy at tilbagekalde 404.607 certifikater, fordi oplysningerne om certifikatpolitik i dem ikke stemte overens med selskabets egne offentliggjorte dokumenter. Kunderne måtte selv downloade og installere erstatningerne.

Denne guide er til dem, der skal svare på »er vi berørt?«: it- og driftsansvarlige, CTO'er og stiftere, hvis forretning kører på et website, et API eller et forbundet produkt. Den gennemgår, hvad der skete, ud fra de hændelsesrapporter, som Mozilla, Google, eMudhra, GoDaddy og softwareleverandørerne har offentliggjort; hvad du skal tjekke i dag; hvad du skal opdatere i denne uge; og hvad du skal have på plads, så den næste hændelse af denne slags bliver rutine. Alt her gælder pr. 22. oktober 2026, og hændelsen er stadig åben.

Hvad der skete

eMudhra oprettede de otte mellemcertifikater ved en nøgleceremoni den 30. april 2025. Selskabets redegørelse, lagt i Mozillas fejlrapport om hændelsen den 19. oktober: en test af et trin, hvor nøgler pakkes ind og ud (key wrap og unwrap), godkendt som en afvigelse fra selskabets sædvanlige procedure, havde en fejl, der skabte et ekstra, svagt sæt nøgler i hardwaresikkerhedsmodulet ved siden af de tilsigtede. Nøglernes etiketter lignede hinanden, de svage nøgler blev ved en fejl brugt til at lave certifikatanmodningerne, og eMudhras rodcertifikat signerede dem. De samme anmodninger gik til Sectigo, som krydssignerede alle otte fra sit rodcertifikat AAA Certificate Services den 14. maj 2025. eMudhra siger, at selskabet »endnu ikke har bekræftet den præcise grundlæggende årsag«.

Mozilla beskrev resultatet: »Private P384-nøgler er tilfældigt valgte heltal mellem 1 og gruppens orden. De 8 berørte nøgler brugte alle heltal mindre end 256.« Mozilla modtog rapporten kl. 20:06 UTC og fandt selv frem til nøglerne kl. 21:48, »uden noget kendskab til den metode, den oprindelige indberetter brugte«. Forskeren siger, at han fandt dem med Googles open source-bibliotek paranoid_crypto, »uden nogen tilpasning«. De svage nøgler havde været en del af offentligt betroede kæder i næsten 18 måneder.

De otte certifikater:

Hver nøgle findes i to certifikater. Det ene blev udstedt af eMudhras emSign Root TLS CA - G3 eller emSign Root CS CA - G3, som kæder op til emSign ECC Root CA - G3; det andet er Sectigos krydscertifikat fra AAA Certificate Services. Den anden vej betyder noget, fordi nogle certifikatlagre (trust stores), der aldrig har indeholdt et rodcertifikat fra eMudhra, stadig har tillid til det gamle rodcertifikat fra Sectigo.

Er nogen blevet angrebet?

Ingen har rapporteret misbrug, og for browsere er der god grund til at tro, at der ikke har været noget. Chrome accepterer, ligesom andre klienter, der håndhæver Certificate Transparency (CT), kun et certifikat, hvis det er registreret i de offentlige CT-logs. Google: der var ikke logget nogen TLS-certifikater, der kæder op til disse seks mellemcertifikater, før blokeringen, så »ingen falske certifikater udstedt af disse certifikatudstedere kunne være blevet brugt mod klienter, der håndhæver CT«.

Uden for browseren ser billedet anderledes ud. Mozillas hændelsesside: »mange klienter uden for browser-økosystemet håndhæver ikke Certificate Transparency. Vi ved ikke, om angribere har udnyttet den fejlbehæftede nøglegenerering til at gå efter disse klienter.« Det vindue åbnede i foråret 2025 og lukker for hver klient først, når den bliver opdateret. eMudhra siger, at selskabet ikke er bekendt med beviser for, at nogen fandt frem til nøglerne før offentliggørelsen, og Cloudflare siger, at selskabets gennemgang ikke har fundet aktiv udnyttelse på dets tjenester.

Nu da nøglerne er offentlige, kræver det ingen ekspertise at forfalske et certifikat. Mozillas hændelsesside oplister testservere, der præsenterer certifikater udstedt med de kompromitterede nøgler, så alle kan teste deres klienter mod dem (kommandoerne står nedenfor).

Hvad et forfalsket certifikat gør muligt: den, der kan opsnappe trafikken mellem din software og en tjeneste, den kalder (på et delt netværk, via en kompromitteret router eller et forgiftet DNS-svar), kan udgive sig for at være den tjeneste, læse alt, hvad din software sender, også API-nøgler og personoplysninger, og ændre det, den modtager. Software signeret med en af de to kodesigneringsnøgler ville være gået igennem Windows' signaturkontrol, indtil Microsofts blokering nåede maskinen.

Hvem er berørt

Der er tre separate problemer, og én virksomhed kan have dem alle.

1. Software, der stadig har tillid til de kompromitterede nøgler

Det problem har næsten alle virksomheder: ethvert program, der foretager HTTPS-kald, hvis certifikatlager stadig indeholder emSign ECC Root CA - G3 eller AAA Certificate Services, og som ikke har fået en blokering af de otte nøgler. Typiske steder:

• Linux-servere og container-images bygget før 20. eller 21. oktober. En upatchet Debian 12 har for eksempel tillid til begge kæder.
• Runtimes til programmeringssprog, der leveres med deres egen liste: Node.js, Pythons certifi, Javas cacerts, PHP's Composer-bundle, Rusts webpki-roots.
• Kommandolinjeværktøjer på macOS. Mozillas hændelsesside siger, at de indbyggede curl, git, python3, perl, ruby og openssl tjekker certifikater mod /etc/ssl/cert.pem uden at kontrollere, om de er tilbagekaldt, og at Apple ikke har opdateret den fil.
• Windows-maskiner, der ikke modtager Microsofts automatiske opdateringer af listen over spærrede certifikater, typisk fordi gruppepolitik slår dem fra, eller fordi netværket er offline.
• Appliances, enheder og tredjepartssoftware, der har deres egen CA-fil med, som load balancere, VPN-gateways, SDK'er og indlejrede controllere.

Hver runtime skal tjekkes for sig. I en test, vi kørte den 22. oktober, accepterede en upatchet Debian 12-maskine med Node.js 24.18 den kæde, der ender ved eMudhras rodcertifikat, og afviste den, der ender ved Sectigos, mens Python på samme maskine accepterede begge.

2. Virksomheder, hvis egne certifikater kæder op til det fjernede rodcertifikat

Mozilla og Linux-distributionerne har fjernet emSign ECC Root CA - G3, og Chrome følger efter den 27. oktober. Gyldige certifikater under det rodcertifikat holder op med at virke i hver klient, efterhånden som den bliver opdateret. Googles anvisning: websiteoperatører med sådanne certifikater »skal straks anskaffe og installere et nyt TLS-certifikat fra et andet PKI-hierarki, der er med i Chrome Root Store«.

Chrome talte omkring 30.800 uudløbne certifikater under rodcertifikatet i CT den 21. oktober. 30.791 af dem kom fra to mellemcertifikater hos InCommon, den certifikattjeneste, som Internet2 driver for amerikanske universiteter og forskningsinstitutioner, og som udsteder ECC-certifikater via CERTInext, eMudhras platform. 18 kom fra eMudhras egne mellemcertifikater. eMudhra siger, at omkring 30.000 certifikater skal migreres, omkring 97 % af dem udstedt via ACME, og at selskabet udsteder erstatninger fra et andet hierarki.

Ligger dit website bag Cloudflare i tilstanden Full (strict), og præsenterer origin-serveren et certifikat under dette rodcertifikat, siger Cloudflare, at fjernelsen af tilliden »ville forårsage fejl«, og opfordrer kunderne: »Gennemgå dine brugerdefinerede origin-certifikater og serverkonfigurationer.«

RSA-certifikater fra eMudhras andet rodcertifikat, emSign Root CA - G1, er indtil videre ikke berørt. Mozilla siger, at man ikke fjerner det rodcertifikat »på nuværende tidspunkt«; Chrome er »i gang med at undersøge nøje, om eMudhras øvrige CA-certifikater fortsat skal være med«. Er du afhængig af certifikater fra eMudhra eller CERTInext af nogen art, så sørg for at have en anden certifikatudsteder klar nu.

3. GoDaddys kunder

GoDaddys sag har intet med eMudhra at gøre, men den ramte i samme uge og langt flere websites. Den 15. oktober rapporterede GoDaddy til Mozilla, at certifikater fra selskabets GoDaddy- og Starfield-hierarkier indeholdt oplysninger om certifikatpolitik (policy-OID'er og CPS-links), der ikke stemte overens med profilerne i selskabets egen CP/CPS, det dokument, hvor en certifikatudsteder beskriver, hvad den udsteder. Det er ikke en sikkerhedsfejl i certifikaterne. Efter Baseline Requirements, de regler, som alle offentlige certifikatudstedere følger, er det alligevel en grund til at tilbagekalde dem inden for fem dage.

404.607 certifikater var berørt, heraf 396.055 domænevaliderede. GoDaddy tilbagekaldte 170.566 inden fristen den 18. oktober kl. 23:45 UTC og 227.422 inden næste morgen; selskabets kundemeddelelse siger, at resten blev tilbagekaldt den 21. oktober. GoDaddy genudsteder certifikaterne, men det er op til kunden at installere dem: »besøgende på dit website kan se sikkerhedsadvarsler, og dit website kan blive utilgængeligt, indtil et nyt certifikat er installeret«.

Hvad du skal tjekke i dag

1. Hvad sender dine egne servere? For hvert offentligt værtsnavn skal du liste udstederne i den kæde, serveren præsenterer:

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

En linje, der nævner eMudhra, emSign, en af udstederne EM ... G3B eller G3C eller InCommon Intermediate CA - DVG3C, OVG3C eller EVG3C, betyder, at certifikatet skal udskiftes før 27. oktober. AAA Certificate Services alene er normalt, da mange almindelige Sectigo-kæder stadig indeholder det. For mail- og katalogtjenester tilføjer du -starttls smtp (eller imap, ldap) og den rigtige port. Tag interne værter, load balancere og origin-servere bag et CDN med.

2. Hvad er der udstedt til dine domæner? CT viser hvert certifikat, en offentlig certifikatudsteder har udstedt til dine navne, også dem, ingen i virksomheden kan huske at have bestilt:

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

Outputtet viser også, hvilke certifikatudstedere din virksomhed faktisk bruger, og det er starten på den oversigt, der beskrives længere nede.

3. Har dine klienter tillid til de kompromitterede nøgler? Mozillas testservere præsenterer certifikater udstedt under de kompromitterede nøgler, så en certifikatfejl er det gode resultat. Test begge familier: den første vært kæder op til eMudhras rodcertifikat, den anden til Sectigos, og et certifikatlager kan dumpe den ene test og bestå den anden.

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 svarer kun for curl. Kør den samme forespørgsel gennem hver applikations egen TLS-stak, i det miljø, hvor applikationen kører:

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 to Python-linjer er ikke overflødige: urllib bruger operativsystemets certifikatlager, requests bruger certifi. Gentag hver linje med værten dv-g3b-aaa-emudhra. For Java: foretag et vilkårligt HTTPS-kald til testserverne fra den pågældende JVM, og vis, om dens certifikatlager indeholder et af de to rodcertifikater (Java 9 eller nyere; på Java 8 bruger 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)'

Et rodcertifikat i et certifikatlager beviser ikke i sig selv, at du er eksponeret, for Go, Node.js, Deno og Rusts rustls-webpki blokerer nu de otte nøgler, uanset hvad der ligger i lageret. Testserverne afgør det.

4. Windows-maskinparken. Microsoft har ikke offentliggjort noget om hændelsen, men listen over spærrede certifikater, som Windows henter automatisk, har blokeret alle otte nøgler siden 20. oktober. Undtagelserne er maskiner, hvor gruppepolitik slår automatiske opdateringer af rodcertifikater fra, og netværk uden adgang til Windows Update; de skal have listen leveret på en anden måde. certutil -verifyCTL Disallowed viser den kopi, en maskine har i sin cache. Mozillas hændelsesside tilbyder et script til enkelte maskiner og siger, at det »ikke anbefales til virksomhedsadministrerede enheder«.

5. GoDaddy-certifikater. Tjek, hvilket certifikat hver server faktisk præsenterer:

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

Er udstederen GoDaddy eller Starfield, så sammenlign serienummeret med certifikaterne på din GoDaddy-konto. Hvor GoDaddy viser »Install your new certificate« (installér dit nye certifikat), har serveren stadig det tilbagekaldte.

Én regel gælder hele vejen: få ikke en fejl til at forsvinde ved at slå certifikatverifikationen fra. Cloudflares ord: »Det er vigtigt ikke at løse disse fejl ved at slå verifikationen fra.« En klient, der ikke verificerer, har tillid til alle forfalskede certifikater, ikke kun disse.

Hvad du skal opdatere i denne uge

Der findes to slags rettelser. At fjerne de to rodcertifikater lukker alle veje for en klient, der bruger det certifikatlager, men det ødelægger også de gyldige certifikater under dem. At blokere de otte nøgler ud fra hashen af deres offentlige nøgle, som Go, Node.js, Deno, Electron, rustls-webpki, Composer og Windows gør, lukker hullet og ødelægger intet andet. Hvor din platform tilbyder den anden løsning, så foretræk den.

»Endnu ingen« og »endnu ikke« betyder, at intet var offentliggjort pr. 22. oktober. Tjek igen, før du planlægger ud fra det.

Fire ting fanger teams på det forkerte ben:

• Container-images beholder den gamle liste. Et image, der er bygget før 20. eller 21. oktober, har tillid til nøglerne, indtil det genopbygges på et opdateret baseimage, og at hente det samme tag hjælper først, når baseimaget er genopbygget. Genopbyg, udrul igen, og spørg de leverandører, hvis images du kører.
• Processer beholder det, de har indlæst. Et program læser sit certifikatlager, når det starter, så genstart langtkørende tjenester efter opdateringen. Node.js tilføjer, at TLS-sessioner, der genoptages fra før opgraderingen, ikke bliver tjekket igen.
• Applikationer har deres egne CA-filer med. SDK'er og applikationer leveres ofte med deres egen cacert.pem eller ca-bundle.crt. Søg efter dem i repositories og images, for eksempel med find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, og regn med at finde mere end én: pip har for eksempel sin egen kopi af certifi med.
• Enheder venter på deres leverandør. Spørg hver leverandør skriftligt, hvilket certifikatlager produktet bruger, og hvornår opdateringen kommer. Indtil den gør, har enheden tillid til forfalskede certifikater for alle de tjenester, den kalder, så begræns, hvad den kan nå.

Fjerner du AAA Certificate Services manuelt, som Debian, Ubuntu ESM, Fedora og Red Hats midlertidige løsning gør, så test bagefter forbindelserne til tjenester med Sectigo-certifikater: nogle ældre servere sender stadig en kæde, der ender ved det rodcertifikat.

Hvad du skal have på plads før den næste

Det er sjældent, at en certifikatudsteder efterlader så svage nøgler. Det er massetilbagekaldelser ikke. Her er de store fra 2026, som er registreret i Mozillas bugtracker:

Ingen af de fem var en sikkerhedsfejl. I hvert tilfælde var et certifikat i modstrid med udstederens eget dokument, og Baseline Requirements (afsnit 4.9.1.1) kræver alligevel tilbagekaldelse inden for fem dage. Når en nøgle er kompromitteret, eller man ikke kan stole på domænevalideringen, er fristen 24 timer. Ingen kan forlænge den for dig. Da DigiCert i 2024 tilbagekaldte 83.267 certifikater, skrev Chrome Root Program, at programmet »ikke har bemyndigelse til at give undtagelser«; én kunde fik en retskendelse, der standsede tilbagekaldelsen af dens certifikater, og kendelsen blev ophævet fire dage senere.

Hvordan udskiftningerne gik, siger meget. I juli brugte HARICA ACME Renewal Information (ARI) til at bede kundernes ACME-klienter om at forny tidligt, og genudstedte selv andre certifikater; ved den største af sine to tilbagekaldelser var 87 % af de berørte navne udskiftet, da fristen udløb. GoDaddy, hvis kunder selv downloader og installerer hver erstatning, havde tilbagekaldt 42 % af sine berørte certifikater ved fristen.

Fornyelsescyklussen bliver under alle omstændigheder kortere:

• Efter CA/Browser Forums afstemning SC-081 har offentlige TLS-certifikater siden 15. marts 2026 været begrænset til 200 dage. Grænsen falder til 100 dage den 15. marts 2027 og til 47 dage den 15. marts 2029, hvor domænevalidering kun kan genbruges i 10 dage.
• Let's Encrypt skifter sin standard til certifikater med 64 dages gyldighed den 10. februar 2027 og til 45 dage et år senere.
• Offentlige TLS-certifikater mister anvendelsen til klientautentificering. Let's Encrypt holdt op med at udstede certifikater til det formål den 8. juli 2026, og Chrome Root Program kræver, at certifikater udstedt fra 15. marts 2027 kun er til serverautentificering. Bruger du offentlige certifikater som klientcertifikater til mutual TLS, hvilket er almindeligt i B2B-integrationer via API, skal de forbindelser have en privat certifikatudsteder.

Ved 100 dage, og siden ved 47, holder det op med at være realistisk at installere certifikater manuelt. En virksomhed, der automatiserer til den tidsplan, er også klar til den næste massetilbagekaldelse. Det kræver følgende:

1. Vid, hvad du har, i begge retninger. Én liste over alle certifikater, dine servere præsenterer, med værtsnavn, udsteder, udløbsdato, fornyelsesmetode og ejer. En anden liste over alle certifikatlagre, din software er afhængig af: operativsystemets pakke, hvert sprogs bundle, hver CA-fil inde i en applikation eller enhed. CT-søgningen ovenfor starter den første liste; en softwarekomponentliste (SBOM) eller en oversigt over afhængigheder starter den anden.
2. Automatisér udstedelse og installation. ACME overalt, hvor det kan køre, med ARI (RFC 9773), så en certifikatudsteder kan bede dine klienter om at forny tidligt. Hvor en enhed ikke kan køre ACME, så brug leverandørens automatisering, eller terminér TLS foran den på noget, der kan.
3. Hold en ekstra certifikatudsteder klar. En fungerende ACME-konto hos en anden udsteder, testet, og CAA-poster i DNS, der tillader begge. Når den ene udsteder mister tilliden eller tilbagekalder i stor stil, bliver et skift en konfigurationsændring.
4. Overvåg CT for dine domæner. Få en advarsel for hvert nyt certifikat til dine navne. Så hører du om uventet udstedelse samme dag, som den sker.
5. Behandl certifikatlagre som afhængigheder. Opdatér dem gennem den normale patchning, og genopbyg images efter en fast plan i stedet for kun, når koden ændres.
6. Skriv drejebogen til de to ure. 24 timer og fem dage: hvem beslutter, hvem har adgang til hvert system, hvilke systemer kræver manuelle trin, hvordan når man hver leverandør. Øv den én gang om året ved at skifte certifikatet på en tjeneste, der kan tåle en fejl. Offentlige certifikatudstedere har siden 2025 skullet have og teste deres egen plan for massetilbagekaldelse; deres kunder har brug for den anden halvdel.

Hvis du laver produkter, som andre kører

Indeholder dit produkt et certifikatlager (en enhed, en installeret applikation, et SDK), er dine kunder først beskyttet, når din opdatering når frem til dem. Udsend den, og fortæl kunderne, hvilke versioner der er rettet. Mozillas råd til dem, der driver et certifikatlager: blokér de otte mellemcertifikater, hvis din software kan det, ellers »overvej, om det er passende at fjerne tilliden til de rodcertifikater, der signerede disse mellemcertifikater«.

Cyber Resilience Act gælder her på to måder. Dens indberetningspligt, der har været i kraft siden 11. september 2026, omfatter aktivt udnyttede sårbarheder, og der er ikke rapporteret udnyttelse i denne sag. Dens væsentlige krav, som gælder fra 11. december 2027, omfatter, at sårbarheder kan afhjælpes gennem sikkerhedsopdateringer; et produkt, hvis certifikatlager ikke kan opdateres, ville ikke opfylde dem. Kunder, der er omfattet af NIS2, vil spørge deres leverandører, hvor hurtigt de håndterede dette, og det hjælper at have svaret på skrift.

Hvad der stadig er åbent

• eMudhras resterende rodcertifikat. Chrome stillede eMudhra tolv spørgsmål den 21. oktober og har ikke meddelt nogen beslutning om emSign Root CA - G1. Mozilla fjerner det ikke »på nuværende tidspunkt«.
• eMudhras migreringsvej. Selskabet fortalte Mozilla, at det ville flytte kunderne til sit G1-hierarki (RSA); dets statusside taler om »et alternativt, uafhængigt drevet, offentligt betroet CA-hierarki«. Chrome har spurgt, hvilket det er.
• Microsoft og Apple. Ingen af dem har offentliggjort en udtalelse eller fjernet nogen af de to rodcertifikater fra sit certifikatlager.
• Ventende rettelser. Red Hat, Amazon Linux, Temurin og Corretto havde ikke udsendt noget pr. 22. oktober; Buns rettelse var merget, men ikke udgivet.
• Den grundlæggende årsag. eMudhra har ikke bekræftet den og har sagt, at selskabet vil efterprøve alle de nøgleceremonier, det har gennemført.
• Sectigo. I en separat sag, der har været åben siden 5. september, har Sectigo afvist at tilbagekalde certifikater, hvis extended key usage ikke stemte overens med en sætning i selskabets CPS, med det argument, at sætningen var tvetydig. Den 18. oktober talte selskabet omkring 72 millioner af dem, der stadig var aktive. Nogle deltagere i den offentlige debat har krævet, at tilliden til Sectigo fjernes; intet rodcertifikatprogram har meddelt en beslutning. Virksomheder med Sectigo-certifikater bør følge sagen.

Hvor du kan få hjælp

Et certifikatproblem melder sig sjældent som et certifikatproblem. Det viser sig som en betalingsside, der holder op med at indlæse, en integration, der holder op med at synkronisere, eller en enhed, der holder op med at rapportere, som regel i en weekend. Vi hjælper virksomheder igennem uger som denne uden nedetid og sætter tingene op, så den næste bliver rutine:

• Et tjek af eksponeringen. Vi finder, hvor dine systemer opretter eller modtager TLS-forbindelser, hvilket certifikatlager hvert af dem bruger, og hvilke certifikater dine servere præsenterer, inklusive containere, Java-tjenester, integrationer med banker, betalings- og logistikudbydere samt enheder.
• Rettelserne. Opdateringer, genopbyggede images, blokerede nøgler eller udskiftede certifikater, gennemført via din ændringsproces og bekræftet mod Mozillas testservere.
• Automatisering til 2027. ACME med ARI på tværs af servere, load balancere og appliances, en ekstra certifikatudsteder, CAA-poster, CT-overvågning og en drejebog, klar til certifikater med 100 dages gyldighed fra 15. marts 2027.
• De systemer, ingen har lyst til at røre ved. Gamle Java-applikationer, appliances og indlejrede klienter med deres egne certifikatlagre er netop det, vores service til vedligeholdelse af ældre systemer og kode er til.

Er du ikke sikker på, om du er berørt, så skriv til office@c9group.dev med de domæner og platforme, du kører, eller book et opkald. Vi fortæller dig, hvad du skal tjekke først.