Ciberseguridad

Escondió un mensaje en su certificado HTTPS y Let’s Encrypt lo firmó

Un desarrollador generó una clave RSA con un mensaje oculto en su certificado TLS. Let's Encrypt la firmó sin revisar y el truco revela un problema viejo.

Escondió un mensaje en su certificado HTTPS y Let's Encrypt lo firmó - Facialix
Anuncios

El autor de maurycyz.com publicó el 8 de noviembre un certificado de su propio sitio con un mensaje escondido dentro de la clave pública.

Let’s Encrypt lo firmó sin objeciones y el certificado sigue activo hasta el 6 de febrero de 2027. No es un fallo de TLS, pero deja a la vista algo incómodo: la autoridad valida el control del dominio, no la calidad de la clave.

Cómo se mete texto dentro de una clave RSA

Una clave pública RSA son dos números: el módulo n y el exponente e. El exponente está estandarizado y la autoridad lo rechaza fuera de norma, así que el espacio libre es el módulo.

El método es directo: genera dos primos aleatorios, calcula n y modifica sus bytes para que el texto aparezca legible en base64. El módulo ya no es el producto original, pero se arregla dividiendo n entre p, redondeando y buscando el siguiente primo.

Como p y q son de tamaño similar, el mensaje sobrevive en la mitad alta.

Con la clave privada reconstruida, el resto es el trámite normal: CSR con openssl, desafío ACME con certbot y firma de la autoridad.

El mensaje que quedó en el certificado

La cadena empieza con una frase que resume la broma: «You dont actually have to pick random private keys». Después afirma que nadie revisa esas cosas y menciona a una autoridad que usó el número 4 durante un año.

El certificado se puede comprobar en vivo: el titular es maurycyz.com, lo emitió Let’s Encrypt YR2 y vale hasta el 6 de febrero de 2027 con el texto dentro de la clave pública.

La referencia incómoda: eMudhra y la clave 4

La broma no era una hipérbole. El 17 de octubre de 2026, un investigador que se identifica como «Wayne» reportó que las claves privadas de ocho certificados intermedios de eMudhra, una autoridad india, se podían recuperar desde los certificados públicos. Eran 4, 56, 66, 115, 155, 156, 230 y 237.

Una clave P-384 debería tener unos 115 dígitos y 2^384 combinaciones. Estas tenían menos de ocho bits de entropía: Scott Helme las recuperó todas en menos de un segundo.

eMudhra dijo que se generaron el 30 de abril de 2025 en una ceremonia con módulos Utimaco y que un fallo del script publicó las claves débiles. Chrome y Firefox bloquearon los certificados en horas y la empresa los revocó el 18 de octubre.

Lo que esto dice del sistema de certificados

El truco reduce la entropía y puede dejar p y q demasiado cerca, lo que facilita la factorización por el método de Fermat. Para un sitio público el riesgo es acotado por el secreto perfecto de TLS; para cualquier cosa importante, el autor recomienda no usar estas claves.

El punto de fondo es otro: nadie revisa la estructura de la clave. La autoridad comprueba que quien pide el certificado controla el dominio, no si el módulo tiene patrones raros o si se generó con suficiente aleatoriedad. El caso eMudhra demuestra hasta dónde llega ese hueco.

El candado del navegador no dice nada sobre cómo se generó la clave. Y fuera de los navegadores la revocación sigue siendo frágil: Helme comprobó que curl, Python y Node.js aceptaban un certificado falso con la configuración por defecto; Windows solo lo rechazaba con la verificación de revocación activa.

El certificado es una broma, pero funciona porque el sistema solo mira el dominio. La pregunta no es si alguien puede esconder un mensaje en su clave, sino cuántas claves malas pasan sin que nadie las mire.

Avatar photo
Sobre el autor

Julio Del Angel

Redactor en Facialix

Ingeniero en Sistemas, egresado del Instituto Tecnológico Superior de Pánuco (TecNM), Veracruz. Especializado en desarrollo de software, tecnología e inteligencia artificial. Fundador y editor de Facialix, donde analiza noticias, avances científicos y oportunidades educativas.

Ver todos sus artículos →

Deja un comentario