Firefox 49 incluirá el certificado raíz de la FNMT tras ocho años esperando…
o al menos eso parece. Muchas páginas oficiales de organizaciones gubernamentales españolas utilizan un certificado expedido por la
Fábrica Nacional de Moneda y Timbre. Internet Explorer y Chrome utilizan el mismo repositorio de certificados raíz (el del sistema operativo) mientras que Mozilla
tiene su propio criterio más restrictivo para incluir certificados en los que confía. Desde 2008 se intentaba que el certificado raíz de la FNMT cumpliera los requisitos para navegar sin alertas
. ¿Qué ha pasado durante todo este tiempo? ¿Por qué no se incluía? Este mes la discusión ha llegado a un acuerdo y parece que se incluirá en la versión 49 (que ya está en beta)… pero no es seguro todavía.
![]() |
| Esto es lo que ven los usuarios cuando se conectan a muchas páginas de organismos oficiales en España |
Para muchos usuarios de Firefox, utilizar cualquier certificado emitido por la FNMT ha supuesto un incordio durante muchos años. Esto en el mejor de los casos (que conocieran qué estaba pasando en realidad) puesto que se solucionaba instalando el certificado raíz en el navegador o añadiendo la excepción. Para los que no fueran conscientes de esto, simplemente obtendrían un mensaje que probablemente
les hiciera pensar en algún tipo de espionaje o malware alojado en su equipo. El problema se conoce de siempre, y ya en 2008 se pidió en Bugzilla que se resolviera. Pero el certificado raíz de la FNMT no cumplía con la
política de inclusión de Firefox. ¿Qué ha pasado en este tiempo?
Desde 2008![]() |
| Mensaje inicial de petición para incluir el certificado |
En mayo de 2008 se inicia la petición oficial. Por aquel entonces Firefox 3 estaba a punto de salir, y
se valoraba (ingenuamente) la posibilidad de incluir ya el certificado en él. En octubre, se quejan del problema varios usuarios explicando que es muy necesario para decenas de gestiones online en España. Kathleen Wilson de la fundación Mozilla se encarga desde entonces de las gestiones para conseguir que el certificado pase las pruebas… y
comienza el calvario.Durante 2009El primer análisis del certificado ya en 2009 encuentra muchos problemas. Su clave es de 1024 bits. Debe contar con un CRL público para revocaciones, se debe asegurar de que no se emiten CAs subordinadas con él, se debe comprobar que cada dominio para el que se emite corresponde a su dueño, y pasar una serie de auditorías realizadas por empresas independientes… entre otras condiciones. Algunos puntos se aclaran con una simple respuesta en Bugzilla, otros comienzan a dar problemas en los que Firefox no cede.
Entre respuesta y respuesta, pueden pasar semanas o meses. La tensión se palpa y la comunidad española de Mozilla calcula el tiempo entre respuestas para recriminar quién tarda más en contestar o tomarse en serio el asunto (si Mozilla o la FNMT).
"Even if 131 days is proof that Mozilla needs reviewing his process to get CAs accepted, the 240 days delay by FNMT, 180 days without a single commment, is completely unacceptable.". Mozilla pide que un representante de la FNMT, no la comunidad, realice a partir de entonces ciertas gestiones. Estamos ya en junio de 2009. El representante aparece en octubre y se hace cargo hasta hoy.
![]() |
| Primeras quejas en 2009 |
2010"Please move this. We all Spaniards need these certificates", se puede leer entre la discusión. Kathleen llega a 2010 con problemas menores y continúa con preguntas y necesidades no cubiertas para entrar en el club de certificados raíz de Mozilla. En este punto, es la propia FNMT la que retrasa el proceso por no cumplir ciertas especificaciones técnicas.
"To all Spanish users: please, don't add noise to this bug. Most of the delay in this process is due to FNMT (see comment #18), so distracting Mozilla staff from other tasks doesn't help at all. Instead, ping FNMT staff (in an educated manner, please!!) through their web contact form"En febrero de 2010, la FMNT pide desbloquear la situación, porque cree ya haber aportado todo lo necesario. Mozilla
se queja de textos en español, y que no puede copiarlos y pegarlos por ser PDFs protegidos. La comunidad los traduce por ellos, pero hay otros problemas con OCSP e incomprensibles laberintos burocráticos y de responsabilidades añadidos a problemas técnicos.
De 2011 a 2014Llega 2011 y comienza el proceso de auditoría. Una empresa técnica debe emitir un informe, que es validado por ASIMELEC (Asociación Multisectorial de Empresas de Tecnologías de la Información, Comunicaciones y Electrónica). Una vez completada buena parte de la burocracia y resueltos muchos problemas, el proceso pasa a "discusión pública" en Mozilla,
una maniobra que debe esperar una cola que va por orden, y en la que hay que esperar literalmente semanas para escalar cada puesto.
Llega a discusión pública en febrero 2012. Pero ahora es necesario volver a validar los documentos anteriores y corregir nuevos bugs. Falta la versión actualizada del CPS (Certificate Practice Statement).
Las conversaciones se dilatan. Pasan meses entre respuestas. Los usuarios se cansan de protestar. Estamos en 2014 y Kathleen todavía espera a algunos representantes a que respondan ciertas dudas y preguntas.
![]() |
| Cada parte tarda en responder ante cada duda o documento solicitado |
Ya en 2015Comienza una discusión sobre qué bits se quieren activar en el certificado (Websites, Email, Code Signing) y la necesidad de obtener nuevas auditorías externas y demostrar que se han seguido ciertos criterios de estándares.
La FMNT cree que muchos requerimientos se solapan entre ellas y que no todos son necesarias. Siguen problemas técnicos con OCSP.
Una ver recopilados los documentos y resueltas ciertas dudas, el proceso pasa a "discusión pública" de nuevo en Mozilla en octubre de 2015. En este 2016Se solucionan problemas menores de nomenclatura. Existen conflictos entre la ley española y la exigencias del cabforum.org (CA/Browser forum, entidad que fija los estándares de interacción entre estas entidades). Hasta que finalmente en un mensaje de
Kathleen el 11 de agosto de 2016…
![]() |
| Mensaje que recomienda cerrar el fallo y aprobarlo |
... se recomienda el cierre de la discusión y la aprobación "del fallo", lo que implica que posiblemente en sucesivas versiones se incluya el certificado, si todo va bien.
¿Conclusiones?Muchas. Es posible que la nueva versión 49 incluya el certificado,
aunque la versión beta, firmada el 22 de agosto, no lo hace.![]() |
| La versión beta, fechada el 22 de agosto, no contiene el certificado todavía |
Con respecto a los problemas burocráticos, una buena parte se resume en
esta entrada de Bugzilla.
![]() |
| Resumen de la situación |
Pero por otro lado:
- El proceso de inclusión de certificados en Firefox es engorroso de por sí. Unido a que lo emita una organización gubernamental (ya engorrosa en la gestión de todos sus procedimientos de por sí) probablemente ha influido bastante en que este proceso haya durado 8 años.
- La organización de Mozilla tampoco es especialmente ágil. Manejan sus propios tiempos y prioridades.
Pero la reflexión puede ir un poco más allá.
¿Están justificadas las reticencias de Mozilla? Han seguido estrictamente un protocolo de seguridad y calidad que garantiza un mínimo más que aceptable y esto es muy positivo, pero en la práctica, ¿de qué ha servido?
Los usuarios no han podido utilizar su navegador para innumerables gestiones durante años y, si el fin era proteger, realmente durante este periodo han protegido de poco al usuario, puesto el certificado ya está incluido en Windows al menos para Chrome e Internet Explorer.
El sistema ya confía en él.¿Y si durante este tiempo el certificado hubiera sido comprometido o se hubiera utilizado ilegítimamente? Esto es uno de los objetivos del duro proceso establecido por Mozilla: evitar que ocurra o mitigar el problema si finalmente pasa…
¿Habría llevado razón Mozilla al no haber confiado en él? Es posible, pero realmente no hubiera marcado la diferencia, puesto que los usuarios ya saben que no se puede utilizar Mozilla para ciertas gestiones y hubieran acudido a otro navegador que no les hubiera protegido de un mal uso de ese certificado.
![]() |
| Los certificados ya se encuentran en el repositorio de confianza de Windows |
¿Significa esto que Mozilla debe relajar sus condiciones e incorporar los mismos certificados del sistema en su propio repositorio? No, porque efectivamente,
en el sistema existen varias CA que el usuario probablemente no utilizará jamás (organizaciones gubernamentales de países totalmente ajenos, por ejemplo… puedes comprobarlo con
SSLCop) y que es un problema conocido desde hace tiempo… No, Mozilla no tiene por qué replicar tal cual o usar el repositorio del sistema operativo (como hace Chrome) pero al menos quizás sería sensato
haber llegado en este caso a un acuerdo de compromiso.Es loable seguir unas normas que elevan el listón, pero también buscar alternativas si tardan 8 años en aplicarse. Sobre todo si durante el proceso se gana poco o nada en seguridad a efectos prácticos. ¿Dónde está el límite en el que se debe insistir en resolver los estrictos procedimientos pero mientras se resuelven,
los usuarios se mantienen descontentos y alejados de la propia protección que se les quiere proporcionar?Por último, esto no deja de ser otra demostración de que el modelo TLS tradicional de CAs necesita cambios urgentes que lo simplifiquen, agilicen y lo hagan más robusto. Las diferentes iniciativas de
Certificate pinning son una consecuencia de estos cambios. Por cierto, que la FNMT no utiliza ni
HSTS ni HPKP.
Sergio de los Santos
ssantos@11paths.com
Ilustración 1: Detalles de los elementos que formarán parte de las listas blancas
Ilustración 2: Gestión de registros
