Java puede aceptar certificados HTTPS falsos. Así lo cierras hoy, con parche o sin él.

1. La respuesta corta

Sí, es real y conviene actuar esta semana. Afecta a cualquier aplicación Java que se conecte por HTTPS a otros servidores: pasarelas de pago, bancos, APIs o servicios de la Administración. Un atacante situado en medio de la red puede hacerse pasar por ese servidor y leer o cambiar lo que viaja. No es una puerta abierta desde internet, pero el arreglo es tan barato que no compensa esperar.

2. Qué ha pasado, en 30 segundos

eMudhra, una autoridad de certificación india que vende certificados con la marca emSign, generó en abril de 2025 ocho certificados intermedios con un fallo grave: sus claves privadas eran números diminutos. Una era literalmente el 4. Cualquiera puede recalcularlas a partir del propio certificado, que es público.

Con una de esas claves se puede firmar un certificado válido para cualquier dominio. El 17 de octubre de 2026 un investigador lo comunicó a los navegadores, que los bloquearon en pocos días. eMudhra los revocó el 18 y Sectigo, que había firmado versiones cruzadas, el 19. Java siguió confiando en ellos hasta que Oracle publicó dos alertas de emergencia fuera de su calendario trimestral.

3. Por qué Java es el eslabón débil

Tu navegador ya estaba protegido. Tu aplicación Java no, por tres motivos que conviene conocer porque se repetirán en el próximo incidente.

Qué podría hacer un atacante en medio

• Leer credenciales, tokens de API y datos personales que tu aplicación envía a sus proveedores.
• Cambiar respuestas: el estado de un pago, un importe o el resultado de una validación.
• Colar una dependencia maliciosa en una compilación con Maven o Gradle.
• Hacer pasar por firmado un JAR malicioso, porque dos de los intermedios servían para firmar código.

4. ¿Me afecta? Compruébalo en un minuto

Afecta a Oracle Java SE 8, 11, 17, 21, 25 y 27, a GraalVM y a cualquier distribución de OpenJDK cuyo almacén conserve esas raíces. También a las versiones sin soporte y a las aplicaciones que traen su propio Java, como AutoFirma, OpenSearch o los entornos de desarrollo. Lo más rápido es mirarlo.

Paso 1. Localiza el java.home de cada servicio y guárdalo en la variable JH:

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

Paso 2. Descarga la comprobación oficial de OpenJDK y ejecútala con el mismo Java que usa el servicio. Con Java 11 o superior:

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

Con Java 8 a 10, o si ese Java no trae compilador (por ejemplo, un JRE), compílala con el javac de cualquier JDK y ejecuta la clase con el Java del servicio. Los avisos de javac son normales:

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

En Windows, la comprobación va incluida en los bloques de la opción 2.

Si responde No bad root certificates found, ese almacén está limpio. Si muestra BAD ROOT con emSign ECC Root CA - G3 o AAA Certificate Services, sigue leyendo. Las raíces emSign Root CA - G1 y G2 no están ligadas a los intermedios comprometidos, aunque Oracle también las retira.

Ojo: comprueba el almacén del Java con el que la lanzas. Si un servicio arranca con otro almacén, por ejemplo con la opción -Djavax.net.ssl.trustStore, revísalo aparte.

5. Opción 1: actualizar Java (lo recomendable)

Es la vía limpia. Instala la versión de tu rama publicada el 24 de octubre, que bloquea los intermedios y además retira las raíces. Las del 21 de octubre, como la 21.0.13.0.2, solo hacen lo primero.

Si usas otra distribución de OpenJDK, como Temurin, Corretto, Zulu o la de Red Hat, busca en sus notas de versión JDK-8395690 o CVE-2026-114820 y confírmalo con la comprobación del punto 4. GraalVM de Oracle también está afectado y tiene su propia actualización.

Las versiones sin soporte, como Java 23 o 26, ya no reciben parches. Usa la opción 2 y planifica el salto a una versión con soporte a largo plazo. Y recuerda que el cambio no surte efecto hasta que reinicias cada servicio y reconstruyes las imágenes de contenedor que llevan Java dentro.

6. Opción 2: sin actualizar, cuatro órdenes

Si hoy no puedes cambiar de versión, haz a mano lo mismo que hace el parche: retira del almacén de Java las cuatro raíces afectadas. No cambias de versión ni recompilas nada. Solo reinicias.

Linux o macOS, de Java 8 a Java 27. Hace una copia con nombre único y, solo si la copia sale bien, retira las raíces:

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, desde PowerShell abierto como administrador. Si la copia falla, no borra nada:

$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 $_ }

Después, en la misma consola, lanza la comprobación. Con Java 11 o superior:

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

Con Java 8 a 10, o si ese Java no trae compilador, lanza este otro bloque de comprobación en su lugar. Necesita el javac de 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 $_ }

Cambia la ruta de la primera línea por tu java.home. changeit es la contraseña por defecto del almacén. Si keytool te sugiere usar la opción -cacerts, no pasa nada. Si dice que un alias no existe, la comprobación final te dirá si queda alguna raíz con otro nombre.

Reinicia los servicios Java. En Linux y macOS, repite la comprobación del punto 4. Debe decir No bad root certificates found.

7. Si tu Java viene de tu distribución Linux

Si instalaste Java con apt o dnf, normalmente usa el almacén del sistema y basta con actualizarlo. Hay una excepción importante en Debian y Ubuntu.

RHEL 8, 9 y 10, Fedora, Oracle Linux, Rocky y Alma (en RHEL 7 el paquete corregido aún está pendiente):

sudo dnf upgrade ca-certificates

Debian y Ubuntu: actualizar no basta, por un fallo antiguo de ca-certificates-java que no borra del almacén de Java lo que el sistema ya retiró. Hay que regenerarlo:

Antes de regenerar: esto borra las CA internas que alguien añadiera a mano con keytool a ese almacén. Las instaladas en /usr/local/share/ca-certificates vuelven solas. Si tenías alguna añadida a mano, vuelve a importarla desde la copia antes de reiniciar. Si un paso falla, el bloque se detiene.

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

Después, reinicia los servicios Java y comprueba con CheckCerts. Si aún salen emSign ECC Root CA - G3 o AAA Certificate Services, tu paquete ca-certificates todavía no trae el arreglo.

8. Lo que este caso pide al cumplimiento

Si tu organización trabaja con el ENS, la ISO 27001, NIS2 o datos personales, esto no es solo un ajuste técnico. Es una prueba de que tu gestión de vulnerabilidades funciona de verdad.

• Inventario. Saber qué Java corre en servidores, contenedores, integración continua y aplicaciones de terceros que traen el suyo, que pueden recuperar su almacén original al actualizarse. Lo que no está inventariado no se parchea.
• Evidencia. Dejar registrado qué revisaste, qué cambiaste y cuándo. Es lo que esperan el ENS (op.exp.4), la ISO 27001 (control 8.8) y NIS2 (artículo 21).
• Versiones sin soporte. Un Java que ya no recibe parches es una deuda que este caso hace visible. Planifica el salto a Java 21 o 25.
• Posible brecha. Si sospechas que alguien interceptó tráfico con datos personales, valora si es una brecha que debes notificar en 72 horas (RGPD, artículo 33).