eMudhran CA-avainten vaarantuminen: mitä yritysten pitää tarkistaa ja korjata nyt

Lauantaina 17. lokakuuta 2026 eräs tietoturvatutkija ilmoitti, että intialaisen varmentajan (CA) eMudhran ylläpitämien kahdeksan välivarmenteen yksityiset avaimet pystyi kuka tahansa päättelemään julkisista varmenteista. Jokainen avaimista oli lukua 256 pienempi luku. Yksi niistä oli luku 4. Kahdeksasta kuusi pystyi myöntämään TLS-varmenteita, joihin Apple, Google, Microsoft ja Mozilla luottavat; kaksi muuta pystyivät allekirjoittamaan Windows-ohjelmistoja.

Chrome esti kuusi TLS-avainta tunnin ja neljänkymmenen minuutin kuluttua ilmoituksesta, Firefox samana iltana. Verkkoa selaavien osalta vaara oli ohi lauantai-iltaan mennessä.

Kaikelle muulle se ei ollut ohi. Palvelimet, kontit, Java-sovellukset, Python-skriptit, maksuintegraatiot ja verkkoon kytketyt laitteet vertaavat varmenteita omaan kopioonsa luotettujen varmentajien luettelosta, ja useimmat näistä kopioista muuttuvat vasta, kun joku asentaa päivityksen. Siihen asti mille tahansa verkkotunnukselle tehty varmenne, joka on allekirjoitettu jollakin näistä avaimista, menee läpi aitona, ja avaimet ovat olleet julkisia 20. lokakuuta lähtien.

Samalla viikolla GoDaddy alkoi mitätöidä 404 607 varmennetta, koska niiden sisältämät varmennepolitiikan tiedot eivät vastanneet yhtiön omia julkaistuja asiakirjoja. Asiakkaiden piti ladata ja asentaa korvaavat varmenteet itse.

Tämä opas on niille, joiden on vastattava kysymykseen ”koskeeko tämä meitä?”: IT- ja ylläpitopäälliköille, teknologiajohtajille ja perustajille, joiden liiketoiminta pyörii verkkosivuston, API:n tai verkkoon kytketyn tuotteen varassa. Se kertoo Mozillan, Googlen, eMudhran, GoDaddyn ja ohjelmistotoimittajien julkaisemien poikkeamatietojen pohjalta, mitä tapahtui; mitä tarkistaa tänään; mitä päivittää tällä viikolla; ja mitä ottaa käyttöön, jotta seuraava samanlainen poikkeama on rutiinia. Kaikki tässä kuvattu on tilanne 22. lokakuuta 2026, ja tapaus on yhä auki.

Mitä tapahtui

eMudhra loi kahdeksan välivarmennetta avainseremoniassa 30. huhtikuuta 2025. Yhtiön oma selvitys, joka julkaistiin Mozillan poikkeamatiketissä 19. lokakuuta: avainten käärimis- ja purkuvaiheen (key wrap ja unwrap) testissä, joka oli hyväksytty tavallisesta menettelystä poikkeavana, oli virhe, joka loi laitteistoturvamoduuliin (HSM) aiottujen avainten rinnalle toisen, heikon avainjoukon. Avainten tunnisteet olivat samankaltaiset, heikkoja avaimia käytettiin vahingossa varmennepyyntöjen luomiseen, ja eMudhran juurivarmenne allekirjoitti ne. Samat pyynnöt menivät Sectigolle, joka ristiinallekirjoitti kaikki kahdeksan AAA Certificate Services -juurivarmenteellaan 14. toukokuuta 2025. eMudhra kertoo, ettei se ole ”vielä vahvistanut tarkkaa juurisyytä”.

Mozilla kuvasi lopputuloksen: ”P384-yksityisavaimet ovat satunnaisesti valittuja kokonaislukuja 1:n ja ryhmän kertaluvun väliltä. Kaikki 8 vaarantunutta avainta käyttivät lukua 256 pienempiä kokonaislukuja.” Mozilla sai ilmoituksen klo 20.06 UTC ja selvitti avaimet itse klo 21.48 ”tietämättä mitään alkuperäisen ilmoittajan käyttämästä menetelmästä”. Tutkija kertoo löytäneensä ne Googlen avoimen lähdekoodin paranoid_crypto-kirjastolla ”sellaisenaan”. Heikot avaimet olivat olleet osa julkisesti luotettuja varmenneketjuja lähes 18 kuukautta.

Kahdeksan varmennetta:

Kukin avain on kahdessa varmenteessa. Toisen myönsi eMudhran emSign Root TLS CA - G3 tai emSign Root CS CA - G3, jotka ketjuuntuvat emSign ECC Root CA - G3 -juurivarmenteeseen; toinen on Sectigon ristiinvarmenne, jonka myöntäjä on AAA Certificate Services. Toisella polulla on merkitystä, koska jotkin varmennesäilöt (trust store), joissa ei ole koskaan ollut eMudhran juurivarmennetta, luottavat yhä tuohon vanhaan Sectigon juurivarmenteeseen.

Onko hyökkäyksiä tapahtunut?

Kukaan ei ole raportoinut väärinkäytöstä, ja selainten osalta on hyvä syy uskoa, ettei sitä ollut. Chrome, kuten muutkin Certificate Transparency -lokitusta (CT, julkinen loki, johon varmentajat kirjaavat myöntämänsä varmenteet) edellyttävät asiakasohjelmat, hyväksyy varmenteen vain, jos se on kirjattu julkisiin CT-lokeihin. Googlen mukaan yhtään näihin kuuteen välivarmenteeseen ketjuuntuvaa TLS-varmennetta ei ollut kirjattu lokeihin ennen sen estoa, joten ”näiden varmentajien myöntämiä vilpillisiä varmenteita ei olisi voitu käyttää CT:tä edellyttäviä asiakasohjelmia vastaan”.

Selaimen ulkopuolella kuva on toinen. Mozillan poikkeamasivun mukaan ”monet selainekosysteemin ulkopuoliset asiakasohjelmat eivät edellytä Certificate Transparency -lokitusta. Emme tiedä, ovatko hyökkääjät hyödyntäneet virheellistä avainten luontia näihin asiakasohjelmiin kohdistuvissa hyökkäyksissä.” Tuo ikkuna avautui keväällä 2025 ja sulkeutuu kunkin asiakasohjelman osalta vasta, kun se päivitetään. eMudhra kertoo, ettei se ole tietoinen mistään näytöstä siitä, että avaimet olisi selvitetty ennen julkistusta, ja Cloudflare kertoo, ettei sen tarkastelu löytänyt aktiivista hyödyntämistä sen palveluissa.

Nyt kun avaimet ovat julkisia, varmenteen väärentäminen ei vaadi taitoa. Mozillan poikkeamasivulla on luettelo testipalvelimista, jotka esittävät vaarantuneilla avaimilla myönnettyjä varmenteita, jotta kuka tahansa voi testata asiakasohjelmansa niitä vasten (komennot ovat alempana).

Mitä väärennetty varmenne mahdollistaa: kuka tahansa, joka pystyy sieppaamaan liikenteen ohjelmistosi ja sen kutsuman palvelun välillä (jaetussa verkossa, murretun reitittimen tai myrkytetyn DNS-vastauksen kautta), voi esiintyä tuona palveluna, lukea, mitä ohjelmistosi lähettää, API-avaimet ja henkilötiedot mukaan lukien, ja muuttaa sitä, mitä se vastaanottaa. Kahdesta koodinallekirjoitusavaimesta jommallakummalla allekirjoitettu ohjelmisto olisi läpäissyt Windowsin allekirjoitustarkistuksen siihen asti, kunnes Microsoftin esto saavutti koneen.

Ketä tämä koskee

Ongelmia on kolme erillistä, ja yhdellä yrityksellä voi olla ne kaikki.

1. Ohjelmistot, jotka luottavat yhä vaarantuneisiin avaimiin

Tämä koskee lähes jokaista yritystä: mikä tahansa HTTPS-kutsuja tekevä ohjelma, jonka varmennesäilössä on yhä emSign ECC Root CA - G3 tai AAA Certificate Services ja jolle ei ole toimitettu kahdeksan avaimen estoa. Tyypillisiä paikkoja:

• Linux-palvelimet ja konttikuvat, jotka on rakennettu ennen 20. tai 21. lokakuuta. Esimerkiksi paikkaamaton Debian 12 luottaa kumpaankin ketjuun.
• Ohjelmointikielten ajoympäristöt, joilla on oma luettelonsa: Node.js, Pythonin certifi, Javan cacerts, PHP:n Composer-varmennepaketti, Rustin webpki-roots.
• macOS:n komentorivityökalut. Mozillan poikkeamasivun mukaan sisäänrakennetut curl, git, python3, perl, ruby ja openssl tarkistavat varmenteet tiedostoa /etc/ssl/cert.pem vasten tarkistamatta mitätöintejä, eikä Apple ole päivittänyt tiedostoa.
• Windows-koneet, jotka eivät saa Microsoftin automaattisia päivityksiä kiellettyjen varmenteiden luetteloon, yleensä siksi, että ryhmäkäytäntö (Group Policy) on poistanut ne käytöstä tai verkossa ei ole internetyhteyttä.
• Appliance-laitteet, muut laitteet ja kolmannen osapuolen ohjelmistot, joihin on paketoitu oma CA-tiedosto, kuten kuormantasaajat, VPN-yhdyskäytävät, SDK:t ja sulautetut ohjaimet.

Jokainen ajoympäristö on tarkistettava erikseen. Testissämme 22. lokakuuta paikkaamaton Debian 12 -kone, jossa oli Node.js 24.18, hyväksyi eMudhran juurivarmenteeseen päättyvän ketjun ja hylkäsi Sectigon juurivarmenteeseen päättyvän, kun taas saman koneen Python hyväksyi molemmat.

2. Yritykset, joiden omat varmenteet ketjuuntuvat poistettuun juurivarmenteeseen

Mozilla ja Linux-jakelut ovat poistaneet emSign ECC Root CA - G3 -juurivarmenteen, ja Chrome seuraa 27. lokakuuta. Sen alla olevat voimassa olevat varmenteet lakkaavat toimimasta kussakin asiakasohjelmassa sitä mukaa kuin se päivittyy. Googlen ohje: verkkosivustojen ylläpitäjien, joilla on tällaisia varmenteita, ”on välittömästi hankittava ja asennettava uusi TLS-varmenne toisesta PKI-hierarkiasta, joka sisältyy Chrome Root Storeen”.

Chrome laski 21. lokakuuta CT-lokeista noin 30 800 tämän juurivarmenteen alaista vanhenematonta varmennetta. Niistä 30 791 tuli kahdesta InCommonin välivarmenteesta; InCommon on Internet2:n yhdysvaltalaisille yliopistoille ja tutkimuslaitoksille ylläpitämä varmennepalvelu, joka myöntää ECC-varmenteita eMudhran CERTInext-alustan kautta. eMudhran omista välivarmenteista tuli 18 varmennetta. eMudhran mukaan noin 30 000 varmennetta on siirrettävä, ja niistä noin 97 % on myönnetty ACME:n kautta; yhtiö kertoo myöntävänsä korvaavia varmenteita toisesta hierarkiasta.

Jos sivustosi on Cloudflaren takana Full (strict) -tilassa ja origin-palvelin esittää tämän juurivarmenteen alaisen varmenteen, Cloudflaren mukaan luottamuksen poistaminen ”aiheuttaisi katkoja”, ja se kehottaa asiakkaita ”tarkistamaan mukautetut origin-varmenteensa ja palvelinasetuksensa”.

eMudhran toisen juurivarmenteen, emSign Root CA - G1, RSA-varmenteet eivät toistaiseksi ole ongelman piirissä. Mozilla kertoo, ettei se poista tätä juurivarmennetta ”tällä hetkellä”; Chrome ”tutkii tarkasti eMudhran jäljellä olevien CA-varmenteiden mukanaolon jatkumista”. Jos olet riippuvainen minkä tahansa tyyppisistä eMudhran tai CERTInextin varmenteista, hanki toinen varmentaja valmiiksi nyt.

3. GoDaddyn asiakkaat

GoDaddyn tapauksella ei ole mitään tekemistä eMudhran kanssa, mutta se osui samalle viikolle ja paljon useampaan sivustoon. GoDaddy ilmoitti Mozillalle 15. lokakuuta, että sen GoDaddy- ja Starfield-hierarkioiden varmenteissa oli varmennepolitiikan tietoja (politiikkojen OID-tunnisteita ja CPS-linkkejä), jotka eivät vastanneet sen oman CP/CPS:n profiileja; CP/CPS on asiakirja, jossa varmentaja kertoo, mitä se myöntää. Kyse ei ole varmenteiden tietoturvaviasta. Jokaista julkista varmentajaa sitovan Baseline Requirements -säännöstön mukaan se on silti syy mitätöidä ne viiden päivän kuluessa.

Ongelma koski 404 607 varmennetta, joista 396 055 oli verkkotunnusvalidoituja. GoDaddy mitätöi 170 566 varmennetta määräaikaan 18. lokakuuta klo 23.45 UTC mennessä ja 227 422 seuraavaan aamuun mennessä; sen asiakastiedotteen mukaan loput mitätöitiin 21. lokakuuta. GoDaddy myöntää varmenteet uudelleen, mutta niiden asentaminen jää asiakkaan tehtäväksi: ”verkkosivustosi kävijät saattavat nähdä tietoturvavaroituksia, ja sivustosi voi muuttua saavuttamattomaksi, kunnes uusi varmenne on asennettu.”

Mitä tarkistaa tänään

1. Mitä omat palvelimesi lähettävät? Listaa jokaisen julkisen palvelinnimen esittämän ketjun myöntäjät:

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

Jos jollakin rivillä mainitaan eMudhra, emSign, jokin varmentajista EM ... G3B tai G3C tai InCommon Intermediate CA - DVG3C, OVG3C tai EVG3C, varmenne on vaihdettava ennen 27. lokakuuta. Pelkkä AAA Certificate Services on normaali, koska monissa tavallisissa Sectigon ketjuissa se on yhä mukana. Posti- ja hakemistopalveluille lisää -starttls smtp (tai imap, ldap) ja oikea portti. Ota mukaan myös sisäiset palvelimet, kuormantasaajat ja CDN:n takana olevat origin-palvelimet.

2. Mitä verkkotunnuksillesi on myönnetty? CT-lokeista näkyy jokainen varmenne, jonka julkinen varmentaja on myöntänyt nimillesi, myös sellaiset, joiden tilaamista kukaan yrityksessä ei muista:

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

Tulosteesta näkyy myös, mitä varmentajia yrityksesi todellisuudessa käyttää, ja siitä alkaa alempana kuvattu luettelo.

3. Luottavatko asiakasohjelmasi vaarantuneisiin avaimiin? Mozillan testipalvelimet esittävät vaarantuneilla avaimilla myönnettyjä varmenteita, joten varmennevirhe on hyvä tulos. Testaa molemmat ketjut: ensimmäinen palvelin ketjuuntuu eMudhran juurivarmenteeseen, toinen Sectigon, ja sama varmennesäilö voi reputtaa toisen testin ja läpäistä toisen.

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 vastaa vain curlin puolesta. Tee sama pyyntö kunkin sovelluksen oman TLS-pinon kautta siinä ympäristössä, jossa sovellus toimii:

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')"

Kaksi Python-riviä eivät ole päällekkäisiä: urllib käyttää käyttöjärjestelmän varmennesäilöä, requests käyttää certifiä. Toista jokainen rivi dv-g3b-aaa-emudhra-palvelimella. Javassa tee mikä tahansa HTTPS-kutsu testipalvelimille kyseisestä JVM:stä ja tarkista, onko sen varmennesäilössä kumpaakaan juurivarmennetta (Java 9 tai uudempi; Java 8:ssa käytä -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Juurivarmenne varmennesäilössä ei yksinään todista altistumista, koska Go, Node.js, Deno ja Rustin rustls-webpki estävät nyt kahdeksan avainta riippumatta siitä, mitä varmennesäilössä on. Testipalvelimet ratkaisevat asian.

4. Windows-laitekannat. Microsoft ei ole julkaissut poikkeamasta mitään, mutta kiellettyjen varmenteiden luettelo, jonka Windows lataa automaattisesti, on estänyt kaikki kahdeksan avainta 20. lokakuuta lähtien. Poikkeuksia ovat koneet, joissa ryhmäkäytäntö on poistanut juurivarmenteiden automaattiset päivitykset käytöstä, sekä verkot, joista ei ole yhteyttä Windows Updateen; niihin luettelo on toimitettava muuta kautta. certutil -verifyCTL Disallowed näyttää koneen välimuistissa olevan kopion. Mozillan poikkeamasivulla on skripti yksittäisille koneille, ja sivun mukaan sitä ”ei suositella yrityksen hallinnoimille laitteille”.

5. GoDaddyn varmenteet. Tarkista, minkä varmenteen kukin palvelin todella esittää:

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

Jos myöntäjä on GoDaddy tai Starfield, vertaa sarjanumeroa GoDaddy-tilisi varmenteisiin. Jos GoDaddy näyttää kohdan ”Install your new certificate” (asenna uusi varmenteesi), palvelimella on yhä mitätöity varmenne.

Yksi sääntö pätee kaikkeen: älä poista virhettä kytkemällä varmenteiden tarkistusta pois päältä. Cloudflaren sanoin: ”On tärkeää, ettei näitä virheitä ratkaista poistamalla tarkistus käytöstä.” Asiakasohjelma, joka ei tarkista, luottaa jokaiseen väärennettyyn varmenteeseen, ei vain näihin.

Mitä päivittää tällä viikolla

Korjauksia on kahdenlaisia. Kahden juurivarmenteen poistaminen sulkee kaikki polut asiakasohjelmalta, joka käyttää kyseistä varmennesäilöä, mutta se rikkoo myös niiden alla olevat voimassa olevat varmenteet. Kahdeksan avaimen estäminen niiden julkisen avaimen tiivisteen perusteella, kuten Go, Node.js, Deno, Electron, rustls-webpki, Composer ja Windows tekevät, sulkee aukon eikä riko mitään muuta. Jos alustasi tarjoaa jälkimmäisen, suosi sitä.

”Ei vielä” tarkoittaa, ettei mitään ollut julkaistu 22. lokakuuta mennessä. Tarkista tilanne uudelleen ennen kuin suunnittelet sen varaan.

Neljä asiaa, joihin tiimit kompastuvat:

• Konttikuvat säilyttävät vanhan luettelon. Ennen 20. tai 21. lokakuuta rakennettu konttikuva luottaa avaimiin, kunnes se rakennetaan uudelleen päivitetyn pohjakuvan päälle, ja saman tagin hakeminen uudelleen auttaa vasta, kun pohjakuva on rakennettu uudelleen. Rakenna uudelleen, ota uudelleen käyttöön ja kysy niiltä toimittajilta, joiden konttikuvia ajat.
• Prosessit pitävät sen, minkä ne latasivat. Ohjelma lukee varmennesäilönsä käynnistyessään, joten käynnistä pitkään käynnissä olevat palvelut uudelleen päivityksen jälkeen. Node.js huomauttaa lisäksi, että ennen päivitystä muodostettuja TLS-istuntoja, joita jatketaan päivityksen jälkeen, ei tarkisteta uudelleen.
• Sovelluksilla on omat CA-tiedostonsa. SDK:iden ja sovellusten mukana tulee usein oma cacert.pem tai ca-bundle.crt. Etsi niitä repositorioista ja konttikuvista, esimerkiksi komennolla find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, ja varaudu siihen, että niitä on useampi kuin yksi: esimerkiksi pipillä on oma kopionsa certifistä.
• Laitteet odottavat toimittajaansa. Kysy jokaiselta toimittajalta kirjallisesti, mitä varmennesäilöä tuote käyttää ja milloin päivitys julkaistaan. Siihen asti laite luottaa väärennettyihin varmenteisiin jokaisen kutsumansa palvelun osalta, joten rajoita, mihin se pääsee.

Jos poistat AAA Certificate Services -juurivarmenteen käsin, kuten Debian, Ubuntu ESM, Fedora ja Red Hatin kiertotie tekevät, testaa sen jälkeen yhteydet palveluihin, joilla on Sectigon varmenteet: jotkin vanhemmat palvelimet lähettävät yhä ketjun, joka päättyy tuohon juurivarmenteeseen.

Mitä ottaa käyttöön ennen seuraavaa kertaa

On harvinaista, että varmentaja jättää avaimet näin heikoiksi. Joukkomitätöinnit eivät ole harvinaisia. Nämä ovat Mozillan bugiseurantaan kirjatut vuoden 2026 suuret tapaukset:

Yksikään näistä viidestä ei ollut tietoturvan pettäminen. Jokaisessa varmenne oli ristiriidassa varmentajan oman asiakirjan kanssa, ja Baseline Requirements -säännöstö (kohta 4.9.1.1) vaatii silti mitätöinnin viiden päivän kuluessa. Kun avain on vaarantunut tai verkkotunnuksen validointiin ei voi luottaa, määräaika on 24 tuntia. Kukaan ei voi pidentää sitä puolestasi. DigiCertin vuoden 2024 joukkomitätöinnissä, joka koski 83 267 varmennetta, Chrome Root Program kirjoitti, ettei sillä ”ole valtuuksia myöntää poikkeuksia”; eräs asiakas sai tuomioistuimelta määräyksen, joka pysäytti sen varmenteiden mitätöinnin, ja määräys kumottiin neljä päivää myöhemmin.

Se, miten vaihdot sujuivat, kertoo paljon. Heinäkuussa HARICA käytti ACME Renewal Information (ARI) -mekanismia kehottaakseen asiakkaidensa ACME-asiakasohjelmia uusimaan varmenteet etuajassa ja myönsi muut varmenteet itse uudelleen; kahdesta mitätöinnistään suuremmassa 87 % kyseisistä nimistä oli vaihdettu määräaikaan mennessä. GoDaddy, jonka asiakkaat lataavat ja asentavat jokaisen korvaavan varmenteen itse, oli mitätöinyt 42 % kyseisistä varmenteistaan määräaikaansa mennessä.

Uusimissykli lyhenee joka tapauksessa:

• CA/Browser Forumin SC-081-päätöksen mukaan julkiset TLS-varmenteet on rajattu 200 päivään 15. maaliskuuta 2026 alkaen. Raja laskee 100 päivään 15. maaliskuuta 2027 ja 47 päivään 15. maaliskuuta 2029, jolloin verkkotunnuksen validointia voi käyttää uudelleen vain 10 päivän ajan.
• Let's Encrypt siirtyy oletuksena 64 päivän varmenteisiin 10. helmikuuta 2027 ja 45 päivän varmenteisiin vuotta myöhemmin.
• Julkiset TLS-varmenteet menettävät asiakkaan todennuksen. Let's Encrypt lakkasi sisällyttämästä sitä varmenteisiinsa 8. heinäkuuta 2026, ja Chrome Root Program edellyttää, että 15. maaliskuuta 2027 alkaen myönnetyt varmenteet ovat vain palvelimen todennukseen. Jos käytät julkisia varmenteita asiakasvarmenteina mutual TLS -yhteyksissä, mikä on yleistä B2B-API-integraatioissa, nämä yhteydet tarvitsevat yksityisen varmentajan.

Kun voimassaoloaika on 100 päivää ja sitten 47, varmenteiden asentaminen käsin lakkaa olemasta realistinen vaihtoehto. Yritys, joka automatisoi tämän aikataulun mukaan, on valmis myös seuraavaan joukkomitätöintiin. Mitä se vaatii:

1. Tiedä, mitä sinulla on, kumpaankin suuntaan. Yksi luettelo jokaisesta varmenteesta, jota palvelimesi esittävät: palvelinnimi, myöntäjä, vanhenemispäivä, uusimistapa ja vastuuhenkilö. Toinen luettelo jokaisesta varmennesäilöstä, jonka varassa ohjelmistosi toimii: käyttöjärjestelmän paketti, kunkin ohjelmointikielen varmennepaketti, jokainen sovelluksen tai laitteen sisällä oleva CA-tiedosto. Yllä kuvattu CT-haku aloittaa ensimmäisen luettelon; ohjelmiston osaluettelo (SBOM) tai riippuvuusluettelo aloittaa toisen.
2. Automatisoi myöntäminen ja asennus. ACME kaikkialla, missä sitä voi ajaa, ARI:n kanssa (RFC 9773), jotta varmentaja voi kehottaa asiakasohjelmiasi uusimaan varmenteet etuajassa. Jos laite ei pysty ajamaan ACME:tä, käytä toimittajan automaatiota tai päätä TLS-yhteys sen edessä johonkin, joka pystyy siihen.
3. Pidä toinen varmentaja valmiina. Toimiva ja testattu ACME-tili toisella varmentajalla sekä DNS:ssä CAA-tietueet, jotka sallivat molemmat. Kun yksi varmentaja menettää luottamuksen tai mitätöi varmenteita joukoittain, vaihdosta tulee asetusmuutos.
4. Seuraa CT-lokeja verkkotunnustesi osalta. Hanki hälytys jokaisesta nimillesi myönnetystä uudesta varmenteesta. Saat tiedon odottamattomasta myöntämisestä samana päivänä, kun se tapahtuu.
5. Käsittele varmennesäilöjä riippuvuuksina. Päivitä ne tavallisen paikkauksen yhteydessä ja rakenna konttikuvat uudelleen aikataulun mukaan eikä vain koodin muuttuessa.
6. Kirjoita toimintaohje (runbook) kahden kellon mukaan. 24 tuntia ja viisi päivää: kuka päättää, kenellä on pääsy kuhunkin järjestelmään, mitkä järjestelmät vaativat käsin tehtäviä vaiheita, miten kunkin toimittajan tavoittaa. Harjoittele sitä kerran vuodessa vaihtamalla varmenne palvelussa, jossa virhe on siedettävissä. Julkisten varmentajien on vuodesta 2025 lähtien pitänyt ylläpitää ja testata omaa joukkomitätöintisuunnitelmaansa; niiden asiakkaat tarvitsevat toisen puolen.

Jos teet tuotteita, joita muut käyttävät

Jos tuotteessasi on varmennesäilö (laite, asennettava sovellus, SDK), asiakkaasi ovat suojassa vasta, kun päivityksesi saavuttaa heidät. Julkaise se ja kerro asiakkaille, mitkä versiot on korjattu. Mozillan neuvo varmennesäilöjen ylläpitäjille: estä kahdeksan välivarmennetta, jos ohjelmistosi pystyy siihen, ja muussa tapauksessa ”harkitse, onko näiden välivarmenteiden allekirjoittaneisiin juurivarmenteisiin kohdistuvan luottamuksen poistaminen tarkoituksenmukaista”.

EU:n kyberresilienssisäädös (Cyber Resilience Act) koskee tätä kahdella tavalla. Sen ilmoitusvelvollisuus, joka on ollut voimassa 11. syyskuuta 2026 alkaen, koskee aktiivisesti hyödynnettyjä haavoittuvuuksia, eikä tässä tapauksessa ole raportoitu hyödyntämistä. Sen olennaisiin vaatimuksiin, joita sovelletaan 11. joulukuuta 2027 alkaen, kuuluu, että haavoittuvuudet voidaan korjata tietoturvapäivityksillä; tuote, jonka luotettujen varmenteiden luetteloa ei voi päivittää, ei täyttäisi niitä. NIS2-direktiivin piiriin kuuluvat asiakkaat kysyvät toimittajiltaan, kuinka nopeasti nämä hoitivat asian, ja vastaus kannattaa olla valmiiksi kirjattuna.

Mikä on vielä auki

• eMudhran jäljellä oleva juurivarmenne. Chrome esitti eMudhralle kaksitoista kysymystä 21. lokakuuta eikä ole ilmoittanut päätöstä emSign Root CA - G1 -juurivarmenteesta. Mozilla ei poista sitä ”tällä hetkellä”.
• eMudhran siirtymäpolku. Yhtiö kertoi Mozillalle siirtävänsä asiakkaat G1 (RSA) -hierarkiaansa; sen tilasivulla puhutaan ”vaihtoehtoisesta, itsenäisesti ylläpidetystä, julkisesti luotetusta CA-hierarkiasta”. Chrome on kysynyt, mistä hierarkiasta on kyse.
• Microsoft ja Apple. Kumpikaan ei ole julkaissut lausuntoa eikä poistanut kumpaakaan juurivarmennetta varmennesäilöstään.
• Odottavat korjaukset. Red Hat, Amazon Linux, Temurin ja Corretto eivät olleet julkaisseet mitään 22. lokakuuta mennessä; Bunin korjaus oli yhdistetty koodiin mutta ei julkaistu.
• Juurisyy. eMudhra ei ole vahvistanut sitä ja on kertonut tarkistavansa uudelleen jokaisen järjestämänsä avainseremonian.
• Sectigo. Erillisessä, 5. syyskuuta lähtien auki olleessa tapauksessa Sectigo on kieltäytynyt mitätöimästä varmenteita, joiden laajennettu avaimen käyttö (extended key usage) ei vastannut erästä sen CPS:n virkettä, vedoten siihen, että virke oli monitulkintainen. Sen laskelman mukaan niitä oli 18. lokakuuta yhä voimassa noin 72 miljoonaa. Osa julkisen keskustelun osallistujista on vaatinut luottamuksen poistamista; mikään juurivarmenneohjelma ei ole ilmoittanut päätöksestä. Yritysten, joilla on Sectigon varmenteita, kannattaa seurata tapausta.

Mistä saat apua

Varmenneongelma esittäytyy harvoin varmenneongelmana. Se näkyy kassasivuna, joka ei enää lataudu, integraationa, joka lakkaa synkronoimasta, tai laitteena, joka lakkaa raportoimasta, yleensä viikonloppuna. Autamme yrityksiä selviämään tämänkaltaisista viikoista ilman käyttökatkoja ja järjestämään asiat niin, että seuraava kerta on rutiinia:

• Altistumisen tarkistus. Selvitämme, missä järjestelmäsi avaavat tai vastaanottavat TLS-yhteyksiä, mitä varmennesäilöä kukin käyttää ja mitä varmenteita palvelimesi esittävät, mukaan lukien kontit, Java-palvelut, integraatiot pankkien, maksupalveluiden ja logistiikkayritysten kanssa sekä laitteet.
• Korjaukset. Päivitykset, uudelleen rakennetut konttikuvat, estetyt avaimet tai vaihdetut varmenteet, tehtyinä muutoksenhallintaprosessisi kautta ja varmistettuina Mozillan testipalvelimia vasten.
• Automaatio vuotta 2027 varten. ACME ja ARI palvelimille, kuormantasaajille ja appliance-laitteille, toinen varmentaja, CAA-tietueet, CT-seuranta ja toimintaohje, valmiina 100 päivän varmenteisiin 15. maaliskuuta 2027 alkaen.
• Järjestelmät, joihin kukaan ei halua koskea. Vanhat Java-sovellukset, appliance-laitteet ja sulautetut asiakasohjelmat omine varmennesäilöineen ovat juuri sitä, mitä varten vanhojen järjestelmien ylläpitopalvelumme on olemassa.

Jos et ole varma, koskeeko tämä sinua, kirjoita osoitteeseen office@c9group.dev ja kerro, mitä verkkotunnuksia ja alustoja käytät, tai varaa puhelu. Kerromme, mitä kannattaa tarkistaa ensin.