Sitios del gobierno indio sirven certificados revocados de eMudhra tras una revocación masiva

Un importante incidente de autoridad de certificación que involucra a eMudhra ha dejado a cientos de sitios web del gobierno indio sirviendo certificados digitales revocados. El problema surgió a mediados de octubre de 2026 cuando se comprometieron las claves privadas de varias autoridades de certificación intermedias, lo que llevó a la desconfianza hacia la emSign ECC Root CA - G3 por parte de navegadores principales como Chrome y Mozilla.

Qué ocurrió

El 17 de octubre de 2026, investigadores de seguridad descubrieron que ocho autoridades de certificación intermedias de eMudhra, encadenadas a la emSign ECC Root CA - G3, tenían claves privadas trivialmente recuperables. Estas claves fueron revocadas al día siguiente. En respuesta, Mozilla y Chrome procedieron a desconfiar de toda la raíz G3. Por separado, el 19 de octubre, eMudhra revocó 9.356 certificados en su jerarquía RSA no afectada, conocida como emSign Root CA - G1. La razón declarada para esta revocación masiva fue "Superseded" (Sustituido), afectando a cada certificado sin expirar que carecía de un OID de política de tipo de certificado específico requerido por la declaración de prácticas de certificación de eMudhra.

El Ministerio de Electrónica y Tecnología de la Información (MeitY) intentó minimizar la gravedad del incidente el 21 de octubre. Una publicación en redes sociales del ministerio afirmaba que el impacto en los sitios web indios era muy limitado y breve. Esta evaluación contradice la evidencia técnica que muestra que las claves defectuosas existían desde abril de 2025, permitiendo su recuperación potencial durante dieciocho meses. Además, el evento de revocación ha causado interrupciones generalizadas, con eMudhra estimando que 30.000 certificados de intermediarios no afectados requieren migración, muchos pertenecientes a universidades de EE. UU. en lugar de entidades indias.

A pesar de las garantías oficiales, los sitios del gobierno indio siguen sirviendo certificados revocados días después del evento. Cuatro organismos bajo MeitY mismo, incluido el Controller of Certifying Authorities (Controlador de Autoridades Certificantes), que regula a eMudhra, se encuentran entre los afectados. Un escaneo actualizado el 24 de octubre identificó 1.377 nombres de dominio del gobierno indio en certificados revocados, con 811 aún sirviéndolos activamente. Los servicios notables impactados incluyen el procesamiento de visas, portales de inmigración, plataformas de servicios ciudadanos como ICEGATE y recursos educativos.

Detalles clave

• Ocho CAs intermedias de eMudhra tenían claves privadas recuperables generadas en abril de 2025, lo que llevó a su revocación el 18 de octubre de 2026.
• El 19 de octubre de 2026, eMudhra revocó 9.356 certificados en su jerarquía RSA por falta de OIDs de política, afectando a 2.976 nombres de dominio gubernamentales.
• A fecha del 24 de octubre de 2026, 811 dominios del gobierno indio seguían sirviendo certificados revocados, incluidos servicios críticos como indianvisaonline.gov.in.
• El comportamiento del navegador varía significativamente: Firefox bloquea estos sitios mediante CRLite, mientras que Chrome, Edge y Safari a menudo permiten el acceso debido a listas de revocación incompletas.
• SSL Labs asigna una calificación F a estos sitios, marcándolos como revocados, pero siguen siendo accesibles para muchos usuarios dependiendo de su software cliente.
• El Controller of Certifying Authorities, el regulador de eMudhra en India, está sirviendo él mismo un certificado revocado de eMudhra en su sitio PKI.

Antecedentes

Los certificados de Transport Layer Security (TLS) verifican la identidad de los sitios web y cifran los datos en tránsito. Las Autoridades de Certificación (CA), como eMudhra, emiten estos certificados. Cuando una CA descubre una violación de seguridad o un error de configuración, debe revocar los certificados afectados. La revocación informa a los navegadores que un certificado previamente confiable ya no es válido. Los navegadores verifican el estado de revocación utilizando mecanismos como Listas de Revocación de Certificados (CRLs), Online Certificate Status Protocol (OCSP) o conjuntos compactos como CRLite y CRLSet.

En este caso, la inconsistencia surge porque diferentes navegadores utilizan métodos distintos para verificar la revocación. Firefox utiliza CRLite, que cubre todas las revocaciones y bloquea el acceso inmediatamente. Chrome utiliza CRLSet, que no había incluido estos certificados específicos a finales de octubre, permitiendo que las conexiones prosigan. Esta fragmentación significa que algunos usuarios ven errores mientras que otros no, creando una falsa sensación de seguridad para aquellos cuyos navegadores no hacen cumplir la revocación.

Por qué importa

Para equipos que ejecutan software autoalojado o gestionan infraestructura interna, este incidente destaca la fragilidad de depender exclusivamente de autoridades de certificación externas sin monitoreo independiente. Si una CA importante falla en notificar a sus suscriptores o si la aplicación por parte del navegador es inconsistente, sus servicios pueden parecer funcionales para algunos usuarios mientras son marcados como inseguros por otros. Esto puede conducir a riesgos de exposición de datos, pérdida de confianza del usuario y violaciones de cumplimiento normativo, especialmente para organizaciones que manejan datos sensibles de ciudadanos o clientes.

El retraso en reemplazar los certificados revocados también demuestra brechas operativas. Incluso cuando se emiten revocaciones, migrar miles de certificados requiere tiempo y coordinación. Sin alertas automatizadas y visibilidad sobre el estado del certificado, los equipos de TI pueden permanecer ignorantes de que sus servicios están degradados hasta que los usuarios reportan problemas. Para entidades gubernamentales y empresariales, este retraso puede interrumpir servicios críticos como solicitudes de visa o declaraciones de impuestos, causando daños reales.

Además, la ironía regulatoria de que el propio controlador esté sirviendo un certificado revocado subraya la necesidad de auditorías internas rigurosas. El cumplimiento no se trata solo de obtener un certificado, sino de mantener su validez a lo largo de todo su ciclo de vida. Los equipos deben asumir que las notificaciones externas pueden estar retrasadas o ser incompletas, haciendo esencial el monitoreo proactivo para mantener la disponibilidad y la postura de seguridad.

Qué puedes hacer

• Implementar monitoreo automatizado de certificados TLS que verifique el estado de revocación independientemente del comportamiento del navegador, utilizando herramientas que consulten directamente CRLs y respondedores OCSP.
• Configurar alertas para eventos de expiración y revocación de certificados para asegurar que tu equipo sea notificado antes de que los usuarios encuentren errores de conexión.
• Auditar regularmente tu inventario de certificados para identificar cualquier certificado emitido por CAs que estén experimentando incidentes de seguridad o eventos de desconfianza de raíces.
• Probar tus servicios en múltiples navegadores y dispositivos para entender cómo afectan los diferentes mecanismos de verificación de revocación al acceso del usuario.
• Mantener un plan de contingencia para el reemplazo rápido de certificados, incluyendo automatización preconfigurada para desplegar nuevos certificados desde CAs alternativas si es necesario.
• Revisar tus declaraciones de prácticas de certificación y asegurar que tus certificados incluyan todos los OIDs de política requeridos para evitar revocaciones masivas debido a errores de cumplimiento.