Java pot acceptar certificats HTTPS falsos. Així ho tanques avui, amb pedaç o sense.

1. La resposta curta

Sí, és real i convé actuar aquesta setmana. Afecta qualsevol aplicació Java que es connecti per HTTPS a altres servidors: passarel·les de pagament, bancs, API o serveis de l'Administració. Un atacant situat al mig de la xarxa pot fer-se passar per aquell servidor i llegir o canviar el que hi circula. No és una porta oberta des d'internet, però la solució és tan barata que no compensa esperar.

2. Què ha passat, en 30 segons

eMudhra, una autoritat de certificació índia que ven certificats amb la marca emSign, va generar l'abril de 2025 vuit certificats intermedis amb un error greu: les seves claus privades eren nombres minúsculs. Una era literalment el 4. Qualsevol les pot recalcular a partir del mateix certificat, que és públic.

Amb una d'aquestes claus es pot signar un certificat vàlid per a qualsevol domini. El 17 d'octubre de 2026 un investigador ho va comunicar als navegadors, que els van bloquejar en pocs dies. eMudhra els va revocar el 18 i Sectigo, que n'havia signat versions creuades, el 19. Java hi va continuar confiant fins que Oracle va publicar dues alertes d'emergència fora del seu calendari trimestral.

3. Per què Java és la baula feble

El teu navegador ja estava protegit. La teva aplicació Java no, per tres motius que convé conèixer perquè es repetiran en el proper incident.

Què podria fer un atacant al mig

• Llegir credencials, tokens d'API i dades personals que la teva aplicació envia als seus proveïdors.
• Canviar respostes: l'estat d'un pagament, un import o el resultat d'una validació.
• Colar una dependència maliciosa en una compilació amb Maven o Gradle.
• Fer passar per signat un JAR maliciós, perquè dos dels intermedis servien per signar codi.

4. M'afecta? Comprova-ho en un minut

Afecta Oracle Java SE 8, 11, 17, 21, 25 i 27, GraalVM i qualsevol distribució d'OpenJDK el magatzem de la qual conservi aquestes arrels. També les versions sense suport i les aplicacions que porten el seu propi Java, com AutoFirma, OpenSearch o els entorns de desenvolupament. El més ràpid és mirar-ho.

Pas 1. Localitza el java.home de cada servei i desa'l a la variable JH:

java -XshowSettings:properties -version 2>&1 | grep java.home
JH="/opt/java/jdk-21"
KS="$JH/lib/security/cacerts"

Pas 2. Descarrega la comprovació oficial d'OpenJDK i executa-la amb el mateix Java que fa servir el servei. Amb Java 11 o posterior:

curl -fsSLO https://cr.openjdk.org/~mr/CheckCerts.java &&
"$JH/bin/java" CheckCerts.java

Amb Java 8 a 10, o si aquell Java no porta compilador (per exemple, un JRE), compila-la amb el javac de qualsevol JDK i executa la classe amb el Java del servei. Els avisos de javac són normals:

curl -fsSLO https://cr.openjdk.org/~mr/CheckCerts.java &&
javac -source 8 -target 8 CheckCerts.java &&
"$JH/bin/java" -cp . CheckCerts

A Windows, la comprovació va inclosa als blocs de l'opció 2.

Si respon No bad root certificates found, aquell magatzem està net. Si mostra BAD ROOT amb emSign ECC Root CA - G3 o AAA Certificate Services, continua llegint. Les arrels emSign Root CA - G1 i G2 no estan lligades als intermedis compromesos, tot i que Oracle també les retira.

Compte: comprova el magatzem del Java amb què la llances. Si un servei arrenca amb un altre magatzem, per exemple amb l'opció -Djavax.net.ssl.trustStore, revisa'l a part.

5. Opció 1: actualitzar Java (el recomanable)

És la via neta. Instal·la la versió de la teva branca publicada el 24 d'octubre, que bloqueja els intermedis i a més retira les arrels. Les del 21 d'octubre, com la 21.0.13.0.2, només fan el primer.

Si fas servir una altra distribució d'OpenJDK, com Temurin, Corretto, Zulu o la de Red Hat, busca a les seves notes de versió JDK-8395690 o CVE-2026-114820 i confirma-ho amb la comprovació del punt 4. GraalVM d'Oracle també està afectat i té la seva pròpia actualització.

Les versions sense suport, com Java 23 o 26, ja no reben pedaços. Fes servir l'opció 2 i planifica el salt a una versió amb suport a llarg termini. I recorda que el canvi no té efecte fins que reinicies cada servei i reconstrueixes les imatges de contenidor que porten Java a dins.

6. Opció 2: sense actualitzar, quatre ordres

Si avui no pots canviar de versió, fes a mà el mateix que fa el pedaç: retira del magatzem de Java les quatre arrels afectades. No canvies de versió ni recompiles res. Només reinicies.

Linux o macOS, de Java 8 a Java 27. Fa una còpia amb un nom únic i, només si la còpia surt bé, retira les arrels:

JH="/opt/java/jdk-21"
KS="$JH/lib/security/cacerts"
B=$(sudo mktemp "$KS.bak-$(date +%Y%m%d)-XXXXXX") && sudo cp "$KS" "$B" &&
for a in emsignrootcag1 emsignrootcag2 emsigneccrootcag3 comodoaaaca; do
  sudo "$JH/bin/keytool" -delete -keystore "$KS" -storepass changeit -alias "$a [jdk]"
done

Windows, des de PowerShell obert com a administrador. Si la còpia falla, no esborra res:

$JH = "C:\Program Files\Java\jdk-21"
$KS = "$JH\lib\security\cacerts"
try {
  [IO.File]::Copy($KS, "$KS.bak-$(Get-Date -Format yyyyMMdd-HHmmss)", $false)
  foreach ($a in "emsignrootcag1","emsignrootcag2","emsigneccrootcag3","comodoaaaca") {
    & "$JH\bin\keytool" -delete -keystore $KS -storepass changeit -alias "$a [jdk]"
  }
} catch { Write-Warning $_ }

Després, a la mateixa consola, llança la comprovació. Amb Java 11 o posterior:

try {
  Invoke-WebRequest https://cr.openjdk.org/~mr/CheckCerts.java -OutFile CheckCerts.java -ErrorAction Stop
  & "$JH\bin\java" CheckCerts.java
} catch { Write-Warning $_ }

Amb Java 8 a 10, o si aquell Java no porta compilador, llança aquest altre bloc de comprovació en lloc seu. Necessita el javac d'un JDK 8 o posterior:

try {
  Invoke-WebRequest https://cr.openjdk.org/~mr/CheckCerts.java -OutFile CheckCerts.java -ErrorAction Stop
  javac -source 8 -target 8 CheckCerts.java
  if ($LASTEXITCODE -eq 0) { & "$JH\bin\java" -cp . CheckCerts }
} catch { Write-Warning $_ }

Canvia la ruta de la primera línia pel teu java.home. changeit és la contrasenya per defecte del magatzem. Si keytool et suggereix fer servir l'opció -cacerts, no passa res. Si diu que un àlies no existeix, la comprovació final et dirà si queda alguna arrel amb un altre nom.

Reinicia els serveis Java. A Linux i macOS, repeteix la comprovació del punt 4. Ha de dir No bad root certificates found.

7. Si el teu Java ve de la teva distribució Linux

Si vas instal·lar Java amb apt o dnf, normalment fa servir el magatzem del sistema i n'hi ha prou d'actualitzar-lo. Hi ha una excepció important a Debian i Ubuntu.

RHEL 8, 9 i 10, Fedora, Oracle Linux, Rocky i Alma (a RHEL 7 el paquet corregit encara està pendent):

sudo dnf upgrade ca-certificates

Debian i Ubuntu: no n'hi ha prou d'actualitzar, per un error antic de ca-certificates-java que no esborra del magatzem de Java el que el sistema ja ha retirat. Cal regenerar-lo:

Abans de regenerar: això esborra les CA internes que algú hagi afegit a mà amb keytool en aquest magatzem. Les instal·lades a /usr/local/share/ca-certificates tornen soles. Si en tenies alguna d'afegida a mà, torna-la a importar des de la còpia abans de reiniciar. Si un pas falla, el bloc s'atura.

sudo apt update &&
sudo apt install --only-upgrade ca-certificates ca-certificates-java &&
B=$(sudo mktemp /root/java-cacerts.bak-XXXXXX) && sudo cp -L /etc/ssl/certs/java/cacerts "$B" &&
sudo rm -f /etc/ssl/certs/java/cacerts &&
sudo update-ca-certificates --fresh

Després, reinicia els serveis Java i comprova-ho amb CheckCerts. Si encara surten emSign ECC Root CA - G3 o AAA Certificate Services, el teu paquet ca-certificates encara no porta la correcció.

8. El que aquest cas demana al compliment

Si la teva organització treballa amb l'ENS, la ISO 27001, NIS2 o dades personals, això no és només un ajust tècnic. És una prova que la teva gestió de vulnerabilitats funciona de debò.

• Inventari. Saber quin Java s'executa en servidors, contenidors, integració contínua i aplicacions de tercers que porten el seu, que poden recuperar el seu magatzem original quan s'actualitzen. El que no està inventariat no s'apedaça.
• Evidència. Deixar registrat què vas revisar, què vas canviar i quan. És el que esperen l'ENS (op.exp.4), la ISO 27001 (control 8.8) i NIS2 (article 21).
• Versions sense suport. Un Java que ja no rep pedaços és un deute que aquest cas fa visible. Planifica el salt a Java 21 o 25.
• Possible bretxa. Si sospites que algú va interceptar trànsit amb dades personals, valora si és una bretxa que has de notificar en 72 hores (RGPD, article 33).