Hacia la renovación mensual de certificados

A finales de 2024, Apple sorprendió a todos al reducir la vigencia máxima de los certificados a solo 45 días. Tomó algunos meses y un par de revisiones menores, pero para abril de 2025 la decisión se formalizó como la propuesta SC-081v3 del CA/Browser Forum. Por si aún no lo sabías, los cambios son bastante drásticos, reduciendo la vigencia máxima permitida para los certificados de los actuales 398 días a solo 47 días en marzo de 2029. Tampoco hay tiempo que perder, porque hay dos hitos intermedios: la primera reducción será a 200 días en marzo de 2026 (¡ya casi!), y la segunda a 100 días en marzo de 2027.

En la práctica, estamos pasando de renovaciones anuales a día de hoy, a dos veces por año en 2026, a renovaciones trimestrales en 2027, y finalmente mensuales en 2029. 

Como resultado, todos están corriendo para detectar dónde tienen certificados públicos y luego implementar automatización. A largo plazo, estos cambios mejorarán las cosas, pero la carga de trabajo adicional a corto plazo supone un reto importante para muchos.

Let's Encrypt, la autoridad certificadora gratuita de donde la mayoría obtiene sus certificados, y pionera de los certificados de 90 días, tiene un cronograma aún más agresivo: reducirán sus certificados a 45 días en febrero de 2028. Probablemente esto no te preocupe demasiado. Sus certificados siempre se emiten de forma automática, lo que significa que no tendrás que hacer nada salvo observar el cambio.

Hay muchos buenos argumentos a favor de reducir la vigencia de los certificados. Ten en cuenta lo siguiente:

• La renovación manual es ineficiente. Se han invertido incontables horas de trabajo en planificar, coordinar y ejecutar esta tarea rutinaria. Además, cada vez que hay un cambio manual, existe la posibilidad de romper algo, lo que requiere aún más recursos para solucionarlo. Cuando la vigencia de los certificados es corta, la renovación manual se vuelve inviable y, en consecuencia, todos deberán implementar automatización. A largo plazo, todos se beneficiarán de esto.
• La renovación automática es ágil. Las PKIs públicas ponen gran énfasis en la corrección de los certificados. Ser estrictos evita largas y acaloradas discusiones sobre si un error en particular es lo suficientemente grave como para considerarse una mala emisión. El ecosistema optó por ser meticuloso para evitar este tipo de conversaciones. Por ello, cuando se cometen errores, hay que corregirlos, incluso si no tienen un impacto práctico. La renovación forzada de certificados por errores de las autoridades certificadoras nunca es bien recibida por los clientes, pero la automatización es una solución. En RFC 9773, ACME fue ampliado para permitir que las autoridades certificadoras desencadenen la renovación automática de certificados defectuosos.
• Las vigencias cortas favorecen la agilidad criptográfica. Antes confiábamos en la función hash SHA1 para las firmas de los certificados, hasta que nos dimos cuenta de que estaba comprometida. La migración a SHA2 tomó mucho tiempo, en parte porque había muchos certificados de larga vigencia usando SHA1. Por tanto, los navegadores no podían dejar de aceptarlos de inmediato sin provocar grandes problemas. Con vigencias más cortas, problemas similares serán mucho más fáciles de gestionar.
• No se realiza comprobación de revocación. Hace algunos años, los principales navegadores decidieron dejar de comprobar la revocación, argumentando problemas de rendimiento, disponibilidad y privacidad. (Firefox es la única excepción, ya que implementó una funcionalidad llamada CRLite, desplegada actualmente en sus plataformas de escritorio). Esto genera una situación incómoda: si un certificado es comprometido, existe una ventana de oportunidad de hasta 398 días para su mal uso. Reducir la vigencia de los certificados es la única forma fiable de solventar este problema.
• Los certificados residuales están por todas partes. Hoy en día ya es poco común obtener tus propios certificados. En su lugar, nos damos de alta en plataformas que obtienen certificados en nuestro nombre. Este es uno de los aspectos difusos de las PKIs públicas: estos certificados llevan nuestros nombres de dominio, pero están bajo el control de un tercero. ¿De quién son realmente? Cuando migras de una plataforma a otra, tus antiguos certificados siguen activos… en algún lugar. Lo mismo ocurre cuando cambia la titularidad de un dominio; el propietario anterior retiene cierto control sobre el nombre de dominio que ya no le pertenece. Hay más información en este artículo de investigación. Vigencias de certificados más cortas también ayudarán a reducir el impacto de este problema.

Está claro que es algo positivo, pero no queda tan claro por qué deberíamos quedarnos en 47 días. Se podría argumentar que 90 días lograrían el mismo objetivo, con menos riesgo de saturar los mecanismos de emisión y supervisión. Por otro lado, podríamos ver propuestas para acortar aún más la vigencia máxima en el futuro… pero sería muy difícil justificar una reducción adicional para todos.

En su Informe Anual de 2024, Internet Security Research Group (ISRG, grupo propietario de Let's Encrypt) llevó la reducción de la vigencia de los certificados al extremo y anunció certificados de seis días para 2025. Esto no tendrá sentido para la mayoría de organizaciones, pero son perfectos para quienes quieren minimizar el riesgo de certificados comprometidos. En el peor de los casos, la ventana de exposición es de solo seis días. Eso realmente es mejor que las garantías proporcionadas por la comprobación de revocación en línea (tal y como se implementaba en la práctica), que era de 7 días.

Disfruto un poco de arqueología PKI, así que dediqué algo de tiempo a investigar la historia de la vigencia máxima de los certificados. En cierto modo, los cambios aplicados durante estos años reflejan la evolución de las PKIs públicas, desde una situación de "salvaje oeste" en sus inicios, hasta la estricta regulación y supervisión actual. También tiene algo de telenovela.

Las primeras restricciones se introdujeron con la primera versión del documento Baseline Requirements (BR) del CA/Browser Forum, que establece cómo deben emitirse los certificados. Antes del BR, no había límites como tales, y era posible obtener un certificado con hasta 10 años de vigencia si así lo deseabas. La primera versión de BR limitó la vigencia a 60 meses desde 2012, con una reducción posterior a 39 meses pospuesta hasta 2015.

Dos años después, en 2017, hubo primero una votación fallida (Ballot 185) para restringir los certificados a 398 días. Prácticamente todas las autoridades certificadoras votaron "no". Curiosamente, dos fabricantes de navegadores también votaron "no" y uno se abstuvo. Sin embargo, solo un mes después, Ballot 193 tuvo éxito y redujo la vigencia de los certificados a 825 días.

Dos años más tarde, en octubre de 2019, el segundo intento de reducir la vigencia a 398 días (Ballot SC-022v2) también fracasó. Nuevamente, las autoridades certificadoras no apoyaron la propuesta. Al leer las justificaciones, la principal razón era el aumento de carga para los clientes. Hacer algo el doble de veces cuesta el doble. Los navegadores no sienten el dolor del cliente, pero las autoridades certificadoras sí, y sus incentivos no estaban alineados. Esta votación, más que ninguna otra, evidenció la profunda brecha entre navegadores y autoridades certificadoras.

Al final, aunque Google impulsó SC022, Apple tomó una decisión unilateral y, en el CA/Browser Forum meeting in February 2020, anunció que, a partir de septiembre de 2020, no aceptarían nuevos certificados con más de 398 días de vigencia. Formalmente, los cambios a BR se realizaron en Ballot SC-031, denominado con entusiasmo "Browser Alignment".

Como ya sabrás, Apple también lideró el impulso más reciente a los 47 días. Esta vez, la mayoría de autoridades certificadoras votaron a favor. La pregunta es cuántas lo hicieron por convicción y cuántas porque no tenían alternativa.

Para ser justos, la situación en 2025 es mucho mejor en términos de automatización, tras 10 años de emisión automatizada mediante Automatic Certificate Management Environment (ACME). Quizás haya una sensación de que la automatización integral está al alcance. Además, la propuesta fue clara sobre adoptar un enfoque escalonado para poder retroceder si aparece algún obstáculo importante.

Un análisis más detallado de la propuesta SC-081v3 (que introdujo la reducción final de las vigencias de los certificados) revela que también se reduce el periodo de reutilización de validaciones. Si no estás familiarizado con las PKI, quizás ni siquiera sabías que las validaciones de certificados se pueden reutilizar, pero sí es posible.

En su día, cuando la mayoría de las validaciones eran manuales, poder reutilizar los resultados era un gran ahorro de tiempo para clientes y autoridades certificadoras. Las entidades certificadoras validaban a sus clientes y sus dominios solo de manera periódica, tras lo cual podían emitir certificados para sus propiedades prácticamente al instante. Cualquiera que haya pasado por el proceso de validación manual sabe que podía llevar días. Este enfoque tenía mucho sentido y ahorraba mucho trabajo.

Para la validación de sujeto (por ejemplo, identidad de la organización), el límite actual es de 825 días, pero se reducirá a 398 días en marzo de 2026, sin futuras reducciones. Esta actividad debe hacerse manualmente y requiere mucho trabajo, por lo que tiene sentido permitir una reutilización más prolongada.

En cambio, la reutilización de validaciones de nombres de dominio y direcciones IP, que pueden automatizarse por completo, se reducirá siguiendo un patrón similar al de los certificados, pero el hito final será solo de 10 días.

Estos cambios son otro impulso hacia la automatización total de todo lo que sea posible. Forma parte de un proceso de saneamiento más amplio, que también incluyó la eliminación de métodos antiguos de validación, como WHOIS, email y comunicación telefónica (por ejemplo, SC-090, SC-091 y SC-080v3). Como resultado, los titulares de dominios tendrán más control sobre quién puede emitir certificados para sus propiedades. Sin embargo, no necesariamente implicará más trabajo para ninguna de las partes, ya que se están introduciendo nuevas funciones centradas en la señalización continua de quién tiene permiso para emitir, como el uso de un registro DNS persistente para validación de dominio (también incluido en SC-091).