Kompromitterte CA-nøkler hos eMudhra: hva selskaper bør sjekke og rette nå

Lørdag 17. oktober 2026 meldte en sikkerhetsforsker at åtte mellomsertifikater (intermediate CA-er) hos den indiske sertifikatutstederen eMudhra hadde private nøkler som hvem som helst kunne regne ut fra de offentlige sertifikatene. Hver eneste nøkkel var et tall mindre enn 256. Én av dem var tallet 4. Seks av de åtte kunne utstede TLS-sertifikater som Apple, Google, Microsoft og Mozilla stoler på; de to andre kunne signere programvare for Windows.

Chrome blokkerte de seks TLS-nøklene én time og førti minutter etter meldingen, og Firefox samme kveld. For dem som surfer på nettet, var faren over lørdag kveld.

For alt annet var den ikke over. Servere, containere, Java-applikasjoner, Python-skript, betalingsintegrasjoner og tilkoblede enheter kontrollerer sertifikater mot sin egen kopi av listen over klarerte sertifikatutstedere, og de fleste av disse kopiene endres bare når noen installerer en oppdatering. Inntil da blir et sertifikat for et hvilket som helst domene, signert med en av disse nøklene, godtatt som ekte, og nøklene har vært offentlige siden 20. oktober.

Samme uke begynte GoDaddy å tilbakekalle 404 607 sertifikater fordi policyinformasjonen i dem ikke stemte med selskapets egne publiserte dokumenter. Kundene måtte selv laste ned og installere erstatningene.

Denne guiden er for dem som må svare på «er vi berørt?»: IT- og driftsledere, CTO-er og gründere med en virksomhet som bygger på et nettsted, et API eller et tilkoblet produkt. Den tar for seg hva som skjedde, hentet fra hendelsesrapportene som Mozilla, Google, eMudhra, GoDaddy og programvareleverandørene har publisert; hva du bør sjekke i dag; hva du bør oppdatere denne uken; og hva du bør få på plass slik at neste hendelse av denne typen blir rutine. Alt her gjelder per 22. oktober 2026, og saken er fortsatt åpen.

Hva som skjedde

eMudhra opprettet de åtte mellomsertifikatene ved en nøkkelseremoni 30. april 2025. Selskapets redegjørelse, lagt ut i Mozillas hendelsessak 19. oktober: en test av et trinn for innpakking og utpakking av nøkler (key wrap og unwrap), godkjent som et avvik fra den vanlige prosedyren, hadde en feil som opprettet et ekstra, svakt nøkkelsett i maskinvaresikkerhetsmodulen ved siden av de tiltenkte nøklene. Nøkkeletikettene lignet hverandre, de svake nøklene ble ved en feil brukt til å lage sertifikatforespørslene, og eMudhras rotsertifikat signerte dem. De samme forespørslene gikk til Sectigo, som kryss-signerte alle åtte fra rotsertifikatet sitt AAA Certificate Services 14. mai 2025. eMudhra sier at selskapet «ennå ikke har bekreftet den eksakte rotårsaken».

Mozilla beskrev resultatet: «Private P384-nøkler er tilfeldig valgte heltall mellom 1 og gruppeordenen. De 8 berørte nøklene brukte alle heltall mindre enn 256.» Mozilla mottok meldingen kl. 20:06 UTC og fant nøklene selv kl. 21:48, «uten noen kjennskap til metoden den opprinnelige melderen brukte». Forskeren sier at han fant dem med Googles bibliotek med åpen kildekode, paranoid_crypto, «rett ut av boksen». De svake nøklene hadde vært del av offentlig klarerte sertifikatkjeder i nesten 18 måneder.

De åtte sertifikatene:

Hver nøkkel finnes i to sertifikater. Det ene ble utstedt av eMudhras emSign Root TLS CA - G3 eller emSign Root CS CA - G3, som selv ligger under emSign ECC Root CA - G3; det andre er Sectigos kryss-sertifikat fra AAA Certificate Services. Den andre veien betyr noe, fordi noen tillitslagre (trust stores) som aldri har inneholdt et rotsertifikat fra eMudhra, fortsatt stoler på dette gamle rotsertifikatet fra Sectigo.

Ble noen angrepet?

Ingen har meldt om misbruk, og for nettlesere er det god grunn til å tro at det ikke har skjedd. Chrome godtar, i likhet med andre klienter som håndhever Certificate Transparency (CT), et sertifikat bare hvis det er registrert i de offentlige CT-loggene. Google: ingen TLS-sertifikater under disse seks mellomsertifikatene var logget før blokkeringen, så «ingen falske sertifikater utstedt av disse sertifikatutstederne kunne ha blitt brukt mot klienter som håndhever CT».

Utenfor nettleseren ser bildet annerledes ut. Mozillas hendelsesside: «mange klienter utenfor nettleserøkosystemet håndhever ikke Certificate Transparency. Vi vet ikke om angripere utnyttet den feilaktige nøkkelgenereringen til å angripe disse klientene.» Det vinduet åpnet seg våren 2025 og lukkes for hver klient først når den blir oppdatert. eMudhra sier at selskapet ikke kjenner til bevis for at nøklene ble funnet før offentliggjøringen, og Cloudflare sier at selskapets gjennomgang ikke fant aktiv utnyttelse på egne tjenester.

Nå som nøklene er offentlige, krever det ingen ferdigheter å forfalske et sertifikat. Mozillas hendelsesside lister opp testservere som presenterer sertifikater utstedt med de kompromitterte nøklene, slik at hvem som helst kan teste klientene sine mot dem (kommandoene står nedenfor).

Hva et forfalsket sertifikat gjør mulig: den som kan fange opp trafikken mellom programvaren din og en tjeneste den kaller (på et delt nettverk, gjennom en kompromittert ruter eller et forgiftet DNS-svar), kan utgi seg for å være den tjenesten, lese det programvaren din sender, også API-nøkler og personopplysninger, og endre det den mottar. Programvare signert med en av de to kodesigneringsnøklene ville ha bestått Windows' signaturkontroll helt til Microsofts blokkering nådde maskinen.

Hvem som er berørt

Det dreier seg om tre separate problemer, og ett selskap kan ha alle tre.

1. Programvare som fortsatt stoler på de kompromitterte nøklene

Dette har nesten alle selskaper: ethvert program som gjør HTTPS-kall, der tillitslageret fortsatt inneholder emSign ECC Root CA - G3 eller AAA Certificate Services, og som ikke har fått en blokkering av de åtte nøklene. Typiske steder:

• Linux-servere og container-images bygget før 20. eller 21. oktober. En upatchet Debian 12 stoler for eksempel på begge kjedene.
• Kjøremiljøer for programmeringsspråk som har med sin egen liste: Node.js, Pythons certifi, Javas cacerts, Composers CA-pakke for PHP, Rusts webpki-roots.
• Kommandolinjeverktøy på macOS. Mozillas hendelsesside sier at de innebygde verktøyene curl, git, python3, perl, ruby og openssl kontrollerer sertifikater mot /etc/ssl/cert.pem uten å sjekke tilbakekalling, og at Apple ikke har oppdatert den filen.
• Windows-maskiner som ikke får Microsofts automatiske oppdateringer av listen over ikke-tillatte sertifikater, som regel fordi gruppepolicy slår dem av eller nettverket er offline.
• Appliances, enheter og tredjepartsprogramvare som har med sin egen CA-fil, for eksempel lastbalanserere, VPN-gatewayer, SDK-er og innebygde kontrollere.

Hvert kjøremiljø må sjekkes for seg. I en test vi kjørte 22. oktober, godtok en upatchet Debian 12-maskin med Node.js 24.18 kjeden som ender i eMudhras rotsertifikat, og avviste den som ender i Sectigos, mens Python på samme maskin godtok begge.

2. Selskaper med egne sertifikater under det fjernede rotsertifikatet

Mozilla og Linux-distribusjonene har fjernet emSign ECC Root CA - G3, og Chrome følger etter 27. oktober. Gyldige sertifikater under dette rotsertifikatet slutter å virke i hver klient etter hvert som den oppdateres. Googles instruks: operatører av nettsteder med slike sertifikater «må umiddelbart skaffe og installere et nytt TLS-sertifikat fra et annet PKI-hierarki som er inkludert i Chrome Root Store».

Chrome telte 21. oktober om lag 30 800 ikke utløpte sertifikater under dette rotsertifikatet i CT. Av disse kom 30 791 fra to mellomsertifikater hos InCommon, sertifikattjenesten Internet2 driver for amerikanske universiteter og forskningsinstitusjoner, som utsteder ECC-sertifikater gjennom CERTInext, eMudhras plattform. eMudhras egne mellomsertifikater sto for 18. eMudhra sier at om lag 30 000 sertifikater må migreres, om lag 97 % av dem utstedt via ACME, og at selskapet utsteder erstatninger fra et annet hierarki.

Ligger nettstedet ditt bak Cloudflare i modusen Full (strict), og origin-serveren presenterer et sertifikat under dette rotsertifikatet, sier Cloudflare at fjerningen av tilliten «ville føre til brudd», og ber kundene: «Gå gjennom dine egendefinerte origin-sertifikater og serverkonfigurasjoner».

RSA-sertifikater fra eMudhras andre rotsertifikat, emSign Root CA - G1, er så langt ikke berørt. Mozilla opplyser at dette rotsertifikatet ikke fjernes «på nåværende tidspunkt»; Chrome «undersøker nøye om eMudhras gjenværende CA-sertifikater fortsatt skal være inkludert». Er du avhengig av sertifikater fra eMudhra eller CERTInext av noe slag, bør du ha en annen sertifikatutsteder klar nå.

3. GoDaddy-kunder

GoDaddy-saken har ingenting med eMudhra å gjøre, men den slo til samme uke og rammet mange flere nettsteder. 15. oktober meldte GoDaddy til Mozilla at sertifikater fra hierarkiene GoDaddy og Starfield inneholdt sertifikatpolicyinformasjon (policy-OID-er og CPS-lenker) som ikke stemte med profilene i selskapets egen CP/CPS, dokumentet der en sertifikatutsteder beskriver hva den utsteder. Det er ikke en sikkerhetsfeil i sertifikatene. Etter Baseline Requirements, reglene alle offentlige sertifikatutstedere følger, er det likevel grunn til å tilbakekalle dem innen fem dager.

404 607 sertifikater var berørt, 396 055 av dem domenevaliderte. GoDaddy tilbakekalte 170 566 innen fristen 18. oktober kl. 23:45 UTC, og 227 422 innen neste morgen; selskapets kundevarsel sier at resten ble tilbakekalt 21. oktober. GoDaddy utsteder sertifikatene på nytt, men det er opp til kunden å installere dem: «besøkende på nettstedet ditt kan få se sikkerhetsadvarsler, og nettstedet ditt kan bli utilgjengelig til et nytt sertifikat er installert.»

Hva du bør sjekke i dag

1. Hva sender dine egne servere? For hvert offentlig vertsnavn lister du opp utstederne i kjeden det presenterer:

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

En linje som nevner eMudhra, emSign, en av utstederne EM ... G3B eller G3C, eller InCommon Intermediate CA - DVG3C, OVG3C eller EVG3C, betyr at sertifikatet må byttes før 27. oktober. AAA Certificate Services alene er normalt, siden mange vanlige Sectigo-kjeder fortsatt tar det med. For e-post- og katalogtjenester legger du til -starttls smtp (eller imap, ldap) og riktig port. Ta med interne verter, lastbalanserere og origin-servere bak et CDN.

2. Hva er utstedt for domenene dine? CT viser alle sertifikater en offentlig sertifikatutsteder har utstedt for navnene dine, også dem ingen i selskapet husker å ha bestilt:

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

Resultatet viser også hvilke sertifikatutstedere selskapet ditt faktisk bruker, og det er starten på oversikten som beskrives lenger ned.

3. Stoler klientene dine på de kompromitterte nøklene? Mozillas testservere presenterer sertifikater utstedt under de kompromitterte nøklene, så en sertifikatfeil er det gode resultatet. Test begge familiene: den første verten ligger under eMudhras rotsertifikat, den andre under Sectigos, og et tillitslager kan avvise den ene og godta den andre.

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 bare for curl. Kjør den samme forespørselen gjennom hver applikasjons egen TLS-stakk, i miljøet der applikasjonen kjø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-linjene er ikke overflødige: urllib bruker operativsystemets tillitslager, requests bruker certifi. Gjenta hver linje med verten dv-g3b-aaa-emudhra. For Java gjør du et hvilket som helst HTTPS-kall til testserverne fra den aktuelle JVM-en, og sjekker om tillitslageret til JVM-en inneholder et av rotsertifikatene (Java 9 eller nyere; på Java 8 bruker 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 rotsertifikat i et tillitslager beviser ikke alene at du er eksponert, fordi Go, Node.js, Deno og Rusts rustls-webpki nå blokkerer de åtte nøklene uansett hva tillitslageret sier. Testserverne avgjør saken.

4. Windows-maskinparken. Microsoft har ikke publisert noe om hendelsen, men listen over ikke-tillatte sertifikater som Windows laster ned automatisk, har blokkert alle åtte nøklene siden 20. oktober. Unntakene er maskiner der gruppepolicy slår av automatiske oppdateringer av rotsertifikater, og nettverk uten forbindelse til Windows Update; der må listen leveres på en annen måte. certutil -verifyCTL Disallowed viser kopien en maskin har mellomlagret. Mozillas hendelsesside tilbyr et skript for enkeltmaskiner og sier at det «ikke anbefales for enheter som administreres av en virksomhet».

5. GoDaddy-sertifikater. Sjekk hvilket sertifikat hver server faktisk presenterer:

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

Er utstederen GoDaddy eller Starfield, sammenligner du serienummeret med sertifikatene i GoDaddy-kontoen din. Der GoDaddy viser «Install your new certificate» (installer det nye sertifikatet ditt), har serveren fortsatt det tilbakekalte.

Én regel gjelder hele veien: ikke få en feil til å forsvinne ved å slå av sertifikatverifisering. Med Cloudflares ord: «Det er viktig at disse feilene ikke løses ved å slå av verifisering.» En klient som ikke verifiserer, stoler på alle forfalskede sertifikater, ikke bare disse.

Hva du bør oppdatere denne uken

Det finnes to typer rettinger. Å fjerne de to rotsertifikatene lukker alle veier for en klient som bruker det tillitslageret, men det ødelegger også de gyldige sertifikatene under dem. Å blokkere de åtte nøklene etter hashverdien av den offentlige nøkkelen, slik Go, Node.js, Deno, Electron, rustls-webpki, Composer og Windows gjør, lukker hullet uten å ødelegge noe annet. Der plattformen din tilbyr det siste, bør du velge det.

Der det står «ennå», var ingenting publisert per 22. oktober. Sjekk på nytt før du legger planer ut fra det.

Fire ting tar team på senga:

• Container-images beholder den gamle listen. Et image bygget før 20. eller 21. oktober stoler på nøklene til det er bygget på nytt på et oppdatert base-image, og å hente den samme taggen på nytt hjelper først når base-imaget er bygget på nytt. Bygg på nytt, rull ut på nytt, og spør leverandørene av imagene du kjører.
• Prosesser beholder det de har lastet. Et program leser tillitslageret sitt når det starter, så start tjenester som kjører over lang tid, på nytt etter oppdateringen. Node.js legger til at TLS-sesjoner som gjenopptas fra før oppgraderingen, ikke kontrolleres på nytt.
• Applikasjoner har med egne CA-filer. SDK-er og applikasjoner har ofte med sin egen cacert.pem eller ca-bundle.crt. Søk etter dem i repositorier og images, med en kommando som find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, og regn med å finne mer enn én: pip har for eksempel med seg sin egen kopi av certifi.
• Enheter venter på leverandøren sin. Spør hver leverandør skriftlig hvilket tillitslager produktet bruker, og når oppdateringen kommer. Inntil den er ute, stoler enheten på forfalskede sertifikater for alle tjenester den kaller, så begrens hva den kan nå.

Fjerner du AAA Certificate Services for hånd, slik Debian, Ubuntu ESM, Fedora og Red Hats midlertidige løsning gjør, bør du etterpå teste forbindelser til tjenester med Sectigo-sertifikater: noen eldre servere sender fortsatt en kjede som ender i dette rotsertifikatet.

Hva du bør ha på plass før neste gang

At en sertifikatutsteder ender opp med så svake nøkler, er sjeldent. Massetilbakekallinger er det ikke. Dette er de store i 2026 som er registrert i Mozillas feilsporingssystem:

Ingen av disse fem var en sikkerhetssvikt. I hvert tilfelle var et sertifikat i strid med utstederens eget dokument, og Baseline Requirements (avsnitt 4.9.1.1) krever likevel tilbakekalling innen fem dager. Når en nøkkel er kompromittert, eller domenevalideringen ikke kan stoles på, er fristen 24 timer. Ingen kan forlenge den for deg. Ved DigiCerts tilbakekalling av 83 267 sertifikater i 2024 skrev Chrome Root Program at programmet «ikke har myndighet til å gi unntak»; én kunde fikk en rettskjennelse som stanset tilbakekallingen av sertifikatene sine, og kjennelsen ble opphevet fire dager senere.

Hvordan erstatningene gikk, sier mye. I juli brukte HARICA ACME Renewal Information (ARI) til å be kundenes ACME-klienter om å fornye tidlig, og utstedte andre sertifikater på nytt selv; i den største av de to tilbakekallingene var 87 % av de berørte navnene erstattet da fristen kom. GoDaddy, der kundene selv laster ned og installerer hver erstatning, hadde tilbakekalt 42 % av de berørte sertifikatene innen fristen.

Fornyelsessyklusen blir uansett kortere:

• Etter avstemningen SC-081 i CA/Browser Forum har offentlige TLS-sertifikater vært begrenset til 200 dager siden 15. mars 2026. Grensen faller til 100 dager 15. mars 2027 og til 47 dager 15. mars 2029, når domenevalidering bare kan gjenbrukes i 10 dager.
• Let's Encrypt går over til sertifikater på 64 dager som standard 10. februar 2027, og til 45 dager et år senere.
• Offentlige TLS-sertifikater mister klientautentisering. Let's Encrypt sluttet å utstede sertifikater med klientautentisering 8. juli 2026, og Chrome Root Program krever at sertifikater utstedt fra 15. mars 2027 bare skal brukes til serverautentisering. Bruker du offentlige sertifikater som klientsertifikater for mutual TLS, noe som er vanlig i API-integrasjoner mellom bedrifter, trenger de forbindelsene en privat sertifikatutsteder.

Med 100 dager, og deretter 47, er det ikke lenger realistisk å installere sertifikater for hånd. Et selskap som automatiserer for den tidsplanen, er også klart for neste massetilbakekalling. Dette er det som skal til:

1. Vit hva du har, i begge retninger. Én liste over alle sertifikater du serverer, med vertsnavn, utsteder, utløpsdato, fornyelsesmetode og eier. En annen liste over alle tillitslagre programvaren din er avhengig av: operativsystempakken, hver pakke som følger med et programmeringsspråk, hver CA-fil inne i en applikasjon eller enhet. CT-søket ovenfor starter den første listen; en programvarekomponentliste (SBOM) eller en oversikt over avhengigheter starter den andre.
2. Automatiser utstedelse og installasjon. ACME der det kan kjøre, med ARI (RFC 9773) slik at en sertifikatutsteder kan be klientene dine om å fornye tidlig. Der en enhet ikke kan kjøre ACME, bruker du leverandørens automatisering, eller terminerer TLS foran den på noe som kan.
3. Ha en annen sertifikatutsteder klar. En fungerende ACME-konto hos en annen utsteder, testet, og CAA-poster i DNS som tillater begge. Når én utsteder mister tilliten eller tilbakekaller i stor skala, blir byttet en konfigurasjonsendring.
4. Overvåk CT for domenene dine. Få et varsel for hvert nytt sertifikat for navnene dine. Da får du vite om uventet utstedelse samme dag som den skjer.
5. Behandle tillitslagre som avhengigheter. Oppdater dem gjennom vanlig patching, og bygg images på nytt etter en fast plan, ikke bare når koden endres.
6. Skriv hendelseshåndboken ut fra de to klokkene. 24 timer og fem dager: hvem som bestemmer, hvem som har tilgang til hvert system, hvilke systemer som krever manuelle steg, hvordan du når hver leverandør. Øv på den én gang i året ved å bytte sertifikatet på en tjeneste som tåler en feil. Offentlige sertifikatutstedere har siden 2025 måttet ha og teste en egen plan for massetilbakekalling; kundene deres trenger den andre halvdelen.

Hvis du lager produkter som andre kjører

Inneholder produktet ditt et tillitslager (en enhet, en installert applikasjon, et SDK), er kundene dine beskyttet først når oppdateringen din når dem. Send den ut, og fortell kundene hvilke versjoner som er rettet. Mozillas råd til dem som drifter tillitslagre: blokker de åtte mellomsertifikatene hvis programvaren din kan det, ellers «vurder om det er hensiktsmessig å fjerne tilliten til rotsertifikatene som signerte disse mellomsertifikatene».

Cyber Resilience Act gjelder her på to måter. Rapporteringsplikten, som har vært i kraft siden 11. september 2026, omfatter aktivt utnyttede sårbarheter, og ingen utnyttelse er meldt i denne saken. De vesentlige kravene, som gjelder fra 11. desember 2027, omfatter at sårbarheter skal kunne håndteres gjennom sikkerhetsoppdateringer; et produkt med en tillitsliste som ikke kan oppdateres, ville ikke oppfylle dem. Kunder som er omfattet av NIS2, kommer til å spørre leverandørene sine hvor raskt de håndterte dette, og det hjelper å ha svaret skriftlig.

Hva som fortsatt er åpent

• eMudhras gjenværende rotsertifikat. Chrome stilte eMudhra tolv spørsmål 21. oktober og har ikke kunngjort noen beslutning om emSign Root CA - G1. Mozilla fjerner det ikke «på nåværende tidspunkt».
• eMudhras migreringsvei. Selskapet sa til Mozilla at det ville flytte kundene til G1-hierarkiet sitt (RSA); statussiden snakker om «et alternativt, uavhengig drevet, offentlig klarert CA-hierarki». Chrome har spurt hvilket.
• Microsoft og Apple. Ingen av dem har publisert en uttalelse eller fjernet noen av rotsertifikatene fra tillitslageret sitt.
• Rettinger som gjenstår. Red Hat, Amazon Linux, Temurin og Corretto hadde ikke levert noe per 22. oktober; Buns retting var flettet inn, men ikke utgitt.
• Rotårsaken. eMudhra har ikke bekreftet den, og har sagt at selskapet vil verifisere på nytt hver nøkkelseremoni det har gjennomført.
• Sectigo. I en egen sak, åpen siden 5. september, har Sectigo avslått å tilbakekalle sertifikater der utvidet nøkkelbruk (extended key usage) ikke stemte med en setning i selskapets CPS, med det argumentet at setningen var tvetydig. 18. oktober talte selskapet om lag 72 millioner slike sertifikater som fortsatt var aktive. Noen deltakere i den offentlige diskusjonen har tatt til orde for å fjerne tilliten til Sectigo; ingen rotprogram har kunngjort en beslutning. Selskaper med Sectigo-sertifikater bør følge saken.

Hvor du får hjelp

Et sertifikatproblem gir seg sjelden til kjenne som et sertifikatproblem. Det viser seg som en kasse i nettbutikken som slutter å laste, en integrasjon som slutter å synkronisere eller en enhet som slutter å rapportere, som regel i en helg. Vi hjelper selskaper gjennom uker som denne uten driftsavbrudd, og setter ting opp slik at neste gang blir rutine:

• En eksponeringssjekk. Vi finner ut hvor systemene dine oppretter eller tar imot TLS-forbindelser, hvilket tillitslager hvert av dem bruker og hvilke sertifikater du serverer, inkludert containere, Java-tjenester, integrasjoner med banker, betalings- og logistikkleverandører, og enheter.
• Rettingene. Oppdateringer, nybygde images, blokkerte nøkler eller byttede sertifikater, gjennomført via endringsprosessen din og bekreftet mot Mozillas testservere.
• Automatisering for 2027. ACME med ARI på servere, lastbalanserere og appliances, en annen sertifikatutsteder, CAA-poster, CT-overvåking og en hendelseshåndbok, klart for sertifikater på 100 dager fra 15. mars 2027.
• Systemene ingen vil røre. Gamle Java-applikasjoner, appliances og innebygde klienter med egne tillitslagre er det vår tjeneste for vedlikehold av eldre systemer er til for.

Er du usikker på om du er berørt, skriv til office@c9group.dev med domenene og plattformene du kjører, eller bestill en samtale. Vi sier hva du bør sjekke først.