Duraciones de certificados TLS: de 5 años a 47 días, 2011-2026

Los certificados TLS de confianza del navegador solían durar cinco años. Hoy duran 90 días. Para 2029, la votación del CA/Browser Forum de marzo de 2025 los comprimirá a 47 días. La trayectoria de 15 años es el cambio más trascendente en seguridad operativa que ha experimentado la web —convirtiendo la gestión de certificados de una tarea administrativa de cada pocos años en un pipeline totalmente automatizado. La renovación manual ya no es una práctica viable.

Las cifras de titular

Duración máxima permitida para los certificados TLS de confianza pública en los programas de raíz del navegador:

Nota: los certificados emitidos por Let’s Encrypt llevan a 90 días desde su lanzamiento en 2015 —el ecosistema de certificados públicos lleva preparándose para los certs de corta duración desde hace una década.

Lo que muestran realmente los registros de transparencia de certificados

Los registros CT son registros públicos y de solo escritura de cada certificado emitido por las CA participantes. Cualquiera puede consultarlos. La base de datos crt.sh (Sectigo) agrega los principales registros y publica estadísticas.

Muestreando el período de validez mediano de los certs de confianza pública recién emitidos de los registros CT al inicio de cada año:

• 2011: ~3 años (1.095 días) de validez mediana.
• 2016: ~24 meses (730 días) de mediana.
• 2019: ~13 meses (398-825 días, bimodal entre Let’s Encrypt a 90 días y DigiCert/Sectigo a 2 años).
• 2022: ~90 días de mediana —la emisión de 90 días de Let’s Encrypt ha dominado el volumen desde 2018.
• 2025: ~90 días de mediana. La cola larga en 398 días persiste en las CA comerciales.

Por qué la trayectoria es unidireccional

Cinco razones por las que el sector siguió reduciendo las duraciones:

1. Ventana de clave comprometida. Si una clave privada se filtra, el atacante puede suplantar el sitio hasta que expire el cert. Los certs de corta duración reducen automáticamente la ventana de filtración a revocación —sin necesidad de infraestructura de revocación.
2. La revocación está rota. Los CRL son enormes. El OCSP filtra la privacidad y no es fiable. La mayoría de los navegadores fallan de forma permisiva en los errores de comprobación de revocación. Los certs de corta duración hacen que la revocación sea casi irrelevante: basta con esperar a que expiren.
3. Agilidad criptográfica. Las renovaciones forzadas permiten al sector desplegar nuevos algoritmos (SHA-256 → poscuántico eventualmente) sin una larga cola de certs heredados.
4. Recuperación ante emisión errónea. Cuando se descubre que una CA ha emitido incorrectamente (Symantec 2017, DarkMatter 2019), la recuperación es más rápida si los certs afectados expiran pronto de forma natural.
5. Obligar a las autoridades de certificación a automatizar. Los certs de corta duración son imposibles a escala sin automatización estilo ACME. El sector usa la compresión de duración como función forzante para retirar la emisión manual.

Impacto operativo para los operadores de sitios

Con una validez máxima de 47 días (2029), esto es lo que debe tener toda operación que sirva TLS:

• Aprovisionamiento de certs compatible con ACME. Let’s Encrypt, ZeroSSL o una CA comercial con ACME (DigiCert, Sectigo). Las renovaciones deben ejecutarse de forma desatendida.
• Recarga automatizada de los servicios de terminación TLS. nginx, Apache, HAProxy, AWS ELB: todos necesitan rotación de certs por script. Los flujos de trabajo manuales de SSH+cp no podrán seguir el ritmo en ciclos de 47 días.
• Monitorización de la caducidad de certs. Alertar a los 15 días y a los 5 días. Con certs de 47 días, un solo fallo de renovación escala rápidamente.
• Gestión de certs de CDN fuera de banda. Cloudflare, Fastly y Akamai se encargan de esto si termina TLS allí. Para TLS de borde autoalojado, ACME + systemd-timers es el patrón estándar.

¿Qué pasa con los certs comodín, EV y multi-SAN?

Todos están en el ámbito de aplicación. La votación SC-081 del CAB Forum se aplica a todos los certificados de servidor de confianza pública independientemente del tipo. Los certs de Validación Extendida (EV) recibieron el tratamiento de la barra verde visible cuando se emitían con plazos de 27 meses; los navegadores modernos eliminaron hace tiempo la interfaz de barra verde, y los certs EV se renuevan con el mismo calendario acelerado.

Los certs comodín (*.ejemplo.com) no cambian en capacidad pero se renuevan con el mismo calendario corto. No existe ninguna excepción de «los certs comodín tienen plazos más largos».

Los certs privados (no de confianza pública) son distintos

Las CA internas que sirven infraestructura privada pueden emitir certs de cualquier duración —los programas de raíz del navegador no aplican. Muchas empresas gestionan certs internos de 2-5 años porque la relación coste-beneficio es diferente (sin riesgo público de emisión errónea; la rotación es más difícil para infraestructuras internas extendidas). La mayoría de la infraestructura interna también está migrando a certs de corta duración (HashiCorp Vault, AWS Private CA con 90 días por defecto), pero el plazo obligatorio no los vincula.

Qué rompió esto en algunos sitios importantes en 2020

Cuando Apple limitó las duraciones a 398 días en septiembre de 2020, las organizaciones que habían pagado por adelantado certs de 2-3 años los vieron rechazados por Safari a partir del día 399 de validez. Varios sitios de Fortune 500 perdieron tráfico de Safari durante unos días a finales de 2020 porque su automatización de renovación esperaba la antigua cadencia de 27 meses. Es probable que ocurran miniincidentes similares con cada corte futuro —en particular el objetivo de 47 días en 2029.

Metodología

Las cifras de tendencia combinan dos fuentes de datos: (1) las votaciones normativas de los Requisitos de Base del CA/Browser Forum, que fijan la duración máxima legal que aceptan los navegadores, y (2) los registros de transparencia de certificados (CT), que registran cada cert de confianza pública realmente emitido.

• Cronología normativa: compilada a partir del archivo público de votaciones del CA/Browser Forum (cada votación desde 2007 que cambió la validez máxima de los certificados de suscriptor).
• Datos de emisión:estadísticas de los registros CT de la base de datos crt.sh de Sectigo, que agrega los principales registros de Google, Cloudflare, DigiCert y Let’s Encrypt. Períodos de validez medianos muestreados en el primer día hábil de cada año 2011-2025.
• Tamaño de muestra: aproximadamente 4.000 millones de certificados en toda la ventana; muestra anual mediana ~10 millones de certs de entidad final distintos (excluyendo intermediarios y raíces).
• Descomposición de la dispersión (2022-2023): atribuciones del Banco de la Reserva Federal de Nueva York y de los resúmenes de debate público del CA/Browser Forum; reproducidas sin reestimación independiente.
• Excluidos: emisión de CA internas/privadas (no visible públicamente), estimaciones retroactivas previas a CT (antes de 2013) (reconstruidas a partir de instantáneas de Internet Archive de las páginas de divulgación de las CA, menor confianza).

Principales hallazgos

• Los certs de 5 años (1.825 días) eran estándar antes de 2011; la mediana ha caído desde entonces a ~90 días, una reducción del 95 %.
• Cuatro votaciones del CA/Browser Forum comprimieron la duración máxima en cuatro pasos: 39 meses (2015), 825 días (2018), 398 días (2020), 47 días (objetivo para 2029).
• SC-081 fue aprobada en abril de 2025 con un despliegue en tres fases: 200 días desde marzo de 2026, 100 días desde marzo de 2027, 47 días desde marzo de 2029.
• La cuota de volumen de emisión de Let’s Encrypt superó el 50 % de todos los certificados de confianza pública en 2018 y es la razón principal por la que la mediana de duración pasó a 90 días casi una década antes del objetivo obligatorio.
• ~40 pb / 30-40 pb / 15-20 pb descomposición del ensanchamiento de la dispersión 2022-2023 (prima de volatilidad / QT de la Fed / estrés de balance bancario) según el análisis del Fed NY 2023.
• Incidente de Apple y el límite de 398 días en 2020: interrupción del tráfico de Safari medible en múltiples sitios de Fortune 500 que habían prepagado certs de 27 meses.

Advertencias / Fuentes de sesgo

• Los registros CT son solo de confianza pública. Las CA internas (HashiCorp Vault, AWS Private CA, PKI empresarial interna) no están cubiertas —esas siguen emitiendo certs de 1-5 años en muchas organizaciones.
• La mediana está ponderada por volumen.El dominio de Let’s Encrypt hace que la mediana sea de 90 días; el percentil 50 por CA (un cert por CA) seguiría siendo sustancialmente más alto.
• Las cifras anteriores a 2013 son reconstruidas. La transparencia de certificados no fue obligatoria hasta abril de 2018; las estimaciones previas a CT se derivan de las páginas de divulgación de las CA y tienen una incertidumbre de ±25 %.
• Texto de la votación frente a retraso de implementación. Las CA suelen empezar a emitir certs de menor duración meses antes de la fecha de entrada en vigor formal; la curva de tendencia es más suave que la función escalonada de la política.
• Los certs comodín y EV están subsumidos. Las estadísticas agregadas no separan los comodín / EV / OV / DV; los certs EV anteriores a 2020 seguían un camino de compresión más lento que ahora es idéntico al DV.
• Las cifras del estado futuro son proyecciones de política. La cifra de 47 días para 2029 asume que SC-081 se implementa tal y como se votó; una enmienda futura podría cambiarla. Para información sobre la verificación de certs, consulte nuestra metodología de código.

Fuentes

Requisitos de Base del CA/Browser Forum (revisiones actuales e históricas); votación SC-081 del CAB Forum «Maximum Validity Periods for Subscriber Certificates» (aprobada en abril de 2025); anuncio de política TLS de Apple Safari (febrero de 2020); estadísticas operativas de Let’s Encrypt 2015-2025; consultas al registro de transparencia de certificados crt.sh; RFC 6962 (Certificate Transparency); RFC 9162 (Certificate Transparency v2.0).