SC-081v3: certificados TLS de 47 días, por qué y cómo prepararte
Por CaptainDNS
Publicado el 19 de marzo de 2026
- SC-081v3 aprobado: la duración de vida máxima de los certificados TLS pasa de 398 días a 47 días en marzo de 2029, en 3 fases (200 d en 2026, 100 d en 2027, 47 d en 2029)
- La reutilización DCV también baja: de 398 días a 10 días, imponiendo una revalidación de dominio casi continua en cada renovación
- La automatización ya no es opcional: sin ACME o equivalente, la renovación manual cada 47 días es insostenible
- Descubre también cómo SC-085v2 impone la validación DNSSEC por las CA, una medida complementaria que entró en vigor el mismo día
El 15 de marzo de 2026 marca un punto de inflexión para el ecosistema TLS. Dos ballots del CA/Browser Forum entran en vigor simultáneamente: SC-085v2, que obliga a las autoridades de certificación a validar DNSSEC durante la emisión de certificados, y la primera fase de SC-081v3, que reduce la duración máxima de los certificados TLS de 398 a 200 días. La coincidencia no es casual: ambos textos participan en la misma refundación de la confianza en la web.
SC-081v3 fue aprobado por el CA/Browser Forum en abril de 2025 con un apoyo masivo: 25 votos a favor, 0 en contra, 5 abstenciones. Apple, impulsor de la propuesta, fue secundado por Google, Mozilla y Microsoft. El mensaje es claro: la era de los certificados de un año ha terminado. Para marzo de 2029, la duración máxima de un certificado TLS será de 47 días, y la reutilización de las pruebas de validación de dominio (DCV) estará limitada a 10 días.
Este artículo cubre el histórico completo de las reducciones de duración, el detalle del ballot SC-081v3, las razones técnicas del cambio, las caídas que aceleraron la decisión, la automatización ACME, el papel de Let's Encrypt, el impacto en los certificados de pago, la interacción con SC-085v2 y DNSSEC, y una guía práctica para preparar tu infraestructura.
Tus renovaciones de certificados, están automatizadas?
De 10 años a 47 días: la historia de la reducción
La duración de vida de los certificados TLS no ha dejado de disminuir desde la creación del sistema. Cada reducción provocó resistencias y después una adaptación rápida de la industria. El patrón es constante: un actor impone un cambio, el ecosistema se adapta y nadie vuelve atrás.
Antes de 2012: hasta 10 años. Las primeras versiones de los certificados SSL no imponían ningún límite estricto de duración. Circulaban certificados de 8 a 10 años. La revocación dependía de listas CRL que rara vez se consultaban. El riesgo de compromiso durante un período así era considerable, pero el coste de los certificados (varios cientos de dólares) incentivaba a maximizar su duración de vida.
2012: 5 años (Baseline Requirements v1). El CA/Browser Forum publica la primera versión de los Baseline Requirements. La duración máxima se fija en 60 meses. Es la primera normalización global de las prácticas de emisión de certificados TLS.
2015: 39 meses. El Ballot 193 reduce la duración a 39 meses. La industria se adapta sin incidentes importantes. Los certificados de 3 años se convierten en la norma para los clientes empresariales.
2018: 825 días. Nueva reducción a 825 días (aproximadamente 27 meses) a través del Ballot 193 revisado. Los certificados de 2 años se imponen. Let's Encrypt, lanzado en 2015, ya había popularizado los certificados de 90 días y demostrado que la automatización funciona a gran escala.
2020: 398 días (decisión unilateral de Apple). Apple anuncia unilateralmente en febrero de 2020 que Safari dejará de aceptar certificados de más de 398 días emitidos después del 1 de septiembre de 2020. Google y Mozilla siguen en las semanas siguientes. El CA/Browser Forum no necesitó votar: los editores de navegadores impusieron el cambio a través de sus root programs. La industria protesta, pero se adapta en pocos meses.
2023: Google propone 90 días. En su hoja de ruta "Moving Forward, Together", Google propone reducir la duración máxima a 90 días. La propuesta no se somete a votación inmediata, pero lanza el debate.
2024: SC-081v1 retirado, v2 fracasa. La primera versión del ballot se retira antes de la votación. SC-081v2 se somete a voto pero no obtiene la supermayoría necesaria. Varias CA se oponen al calendario, considerado demasiado agresivo. Los ballots SC-22 y 185, que planteaban reducciones similares, ya habían fracasado en años anteriores.
Abril de 2025: SC-081v3 aprobado. La tercera versión alcanza el consenso. El calendario se distribuye en 4 fases entre 2026 y 2029, dejando tiempo a la industria para adaptarse. Resultado de la votación: 25 a favor, 0 en contra, 5 abstenciones.
El patrón es nítido: cada reducción fue combatida, luego adoptada, y finalmente considerada insuficiente unos años más tarde. La dirección es irreversible.
Ballot SC-081v3: qué cambia concretamente
SC-081v3 no se limita a acortar la duración de los certificados. También reduce el período de reutilización de las pruebas de validación de dominio (DCV reuse), forzando una revalidación casi continua.
Las 4 fases de la reducción
| Fase | Fecha de entrada en vigor | Duración máx. certificado | Reutilización DCV máx. |
|---|---|---|---|
| Fase 0 (actual) | Antes del 15 de marzo de 2026 | 398 días | 398 días |
| Fase 1 | 15 de marzo de 2026 | 200 días | 200 días |
| Fase 2 | 15 de marzo de 2027 | 100 días | 100 días |
| Fase 3 | 15 de marzo de 2029 | 47 días | 10 días |
Entender la reutilización DCV
La validación de control de dominio (DCV) es el proceso por el cual una CA verifica que el solicitante controla el dominio. Actualmente, una prueba DCV puede reutilizarse durante 398 días: si validas tu dominio hoy, la CA puede emitir un nuevo certificado en los 398 días siguientes sin solicitar una nueva prueba.
SC-081v3 reduce esta ventana de reutilización en paralelo con la duración de los certificados. En la fase 3, la reutilización DCV baja a 10 días. Concretamente, cada renovación de certificado requerirá una nueva validación de dominio, ya que un certificado de 47 días debe renovarse antes de expirar y la prueba DCV solo será válida durante 10 días.
Por qué 47 días y no un número redondo
El número 47 no es arbitrario. Corresponde a un ciclo de renovación de 30 días con un margen de 17 días. La idea: si el cliente ACME renueva el certificado 30 días antes de la expiración (como recomienda la mayoría de los clientes), quedan 17 días de margen en caso de fallo. Una renovación al mes, con una red de seguridad de más de dos semanas.
Lo que no cambia
SC-081v3 se aplica a todos los tipos de certificados TLS públicos: DV (Domain Validation), OV (Organization Validation) y EV (Extended Validation). No hay excepción para los certificados OV o EV, al contrario de lo que algunos comentaristas habían esperado. La distinción DV/OV/EV se refiere al nivel de verificación de la identidad de la organización, no a la duración del certificado.
Los intentos fallidos
SC-081v3 no es el primer intento de reducción. Varios ballots habían fracasado a lo largo de los años. El Ballot 185 (2017) proponía pasar a 13 meses y fue rechazado. El Ballot SC-22 intentó una reducción a 397 días y fracasó. SC-081v1 fue retirado antes de la votación. SC-081v2 no obtuvo la supermayoría del lado CA. La v3 lo logró extendiendo el calendario y añadiendo un margen suficiente en cada fase.
Por qué certificados más cortos
La reducción de la duración de los certificados responde a varios problemas estructurales del ecosistema TLS. Ninguno de ellos puede resolverse con los mecanismos actuales.
La revocación está rota
El mecanismo previsto para invalidar un certificado comprometido no funciona en la práctica. Las listas de revocación (CRL) alcanzan cientos de megabytes: la CRL de Let's Encrypt superaba los 300 MB antes del abandono de OCSP. OCSP (Online Certificate Status Protocol) sufre del problema del soft-fail: si el servidor OCSP no responde, el navegador acepta el certificado por defecto, haciendo la verificación inútil. Chrome reemplazó OCSP por CRLSets, una lista compacta que cubre aproximadamente el 2 % de los certificados revocados. Let's Encrypt abandonó oficialmente OCSP a finales de 2024, reconociendo el fracaso del mecanismo.
Con certificados de 47 días, la revocación se vuelve menos crítica. Un certificado comprometido expira naturalmente en pocas semanas, limitando la ventana de explotación sin depender de un mecanismo de revocación deficiente.
Criptoagilidad y migración poscuántica
Los certificados cortos facilitan la migración hacia nuevos algoritmos criptográficos. El NIST publicó en agosto de 2024 los estándares finales para la criptografía poscuántica: ML-KEM (Key Encapsulation) y ML-DSA (Digital Signatures). La transición hacia estos algoritmos requerirá reemplazar los certificados existentes. Con certificados de 47 días, todo el ecosistema migra en 47 días como máximo, frente a más de un año con certificados de 398 días.
Ventana de compromiso reducida
Un certificado comprometido de 398 días puede ser explotado durante más de un año. Con 47 días, la ventana de explotación máxima pasa a menos de 7 semanas. Es una reducción del 88 %. Si una clave privada es robada, el atacante dispone de unas pocas semanas en lugar de más de un año para explotarla.
La automatización forzada reduce las caídas
Paradójicamente, los certificados más cortos reducen las caídas relacionadas con la expiración. La razón: obligan a automatizar. Un certificado de 398 días puede gestionarse manualmente (mal), olvidarse y después expirar de golpe. Un certificado de 47 días no deja opción: sin automatización, la renovación es imposible de mantener. Las organizaciones que automatizan ya no sufren caídas por expiración.
Alineación con el modelo zero trust
El modelo Zero Trust se basa en la verificación continua. Un certificado de 398 días otorga una confianza implícita durante más de un año, lo que contradice el principio. Los certificados cortos imponen una reverificación frecuente de la identidad del servidor, alineando la PKI web con los principios Zero Trust.
Las caídas que lo cambiaron todo
Varios incidentes graves demostraron las consecuencias de una gestión manual de los certificados. Cada caída reforzó el argumento a favor de la automatización y de la reducción de duración.
Equifax (2017): 147,9 millones de personas expuestas
En marzo de 2015, Equifax deja expirar un certificado SSL en un equipo de inspección de tráfico de red. Este certificado caducado desde 19 meses impide la detección de una intrusión activa. Los atacantes explotan una vulnerabilidad Apache Struts sin parchear durante 76 días, exfiltrando los datos personales de 147,9 millones de personas. El coste total supera los 1380 millones de dólares. La investigación revela que la empresa gestionaba más de 300 certificados manualmente, sin inventario centralizado.
Ericsson/O2 UK (2018): 32 millones de usuarios sin red
El 6 de diciembre de 2018, un certificado intermedio de Ericsson expira en la infraestructura de red de O2 UK. La expiración provoca una caída total de la red móvil para 32 millones de abonados durante más de 12 horas. SoftBank en Japón sufre una caída idéntica el mismo día. El coste estimado supera los 133 millones de dólares. El certificado, con una duración de vida de 15 años, había sido instalado y olvidado.
Microsoft Teams (2020): 3 horas de caída mundial
El 3 de febrero de 2020, Microsoft Teams sufre una caída de 3 horas en pleno auge del teletrabajo por la COVID-19. La causa: un certificado de autenticación expirado. El incidente afecta a millones de usuarios en teletrabajo en un momento en que Teams se había convertido en una herramienta crítica para miles de empresas.
Let's Encrypt (2021): la expiración de un certificado raíz histórico
El 30 de septiembre de 2021, el certificado raíz DST Root CA X3, utilizado por Let's Encrypt para la compatibilidad con dispositivos antiguos, expira. Millones de dispositivos con Android 7.1 y versiones anteriores pierden el acceso a sitios que usan Let's Encrypt. El incidente ilustra la complejidad de la gestión de certificados raíz y la necesidad de cadenas de confianza ágiles.
El punto común de estos incidentes: cada caída implica un certificado gestionado manualmente, olvidado, o cuya duración de vida superaba con creces las necesidades operativas.
ACME y la automatización obligatoria
Con certificados de 47 días y una reutilización DCV de 10 días, la renovación manual se vuelve físicamente imposible para cualquier infraestructura con más de un puñado de certificados. ACME (Automatic Certificate Management Environment) es el protocolo que hace posible la automatización.
El protocolo ACME (RFC 8555)
ACME estandariza el diálogo entre un cliente (tu servidor) y una CA. El proceso sigue tres pasos: el cliente demuestra que controla el dominio (challenge), la CA verifica la prueba y luego emite el certificado. Existen tres tipos de challenges:
- HTTP-01: el cliente coloca un archivo en una URL específica. La CA verifica que el archivo es accesible. Sencillo pero incompatible con los certificados wildcard.
- DNS-01: el cliente publica un registro TXT bajo
_acme-challenge.captaindns.com. La CA consulta el DNS. Compatible con wildcard, ideal para entornos automatizados. - TLS-ALPN-01: el cliente configura un certificado temporal con una extensión ALPN específica. Útil cuando no controlas ni el DNS ni el servidor web.
Clientes ACME
El ecosistema de clientes ACME es maduro y cubre todos los entornos:
- Certbot: el cliente de referencia, mantenido por la EFF. Compatible con Linux, macOS, Windows. Plugins para Apache y NGINX.
- acme.sh: script shell puro, sin dependencias. Más de 150 API DNS compatibles para el challenge dns-01.
- Lego: cliente Go, popular en entornos containerizados y pipelines CI/CD.
- Caddy: servidor web con ACME integrado. Obtiene y renueva los certificados automáticamente, sin configuración.
- Traefik: reverse proxy cloud-native con ACME integrado. Gestiona los certificados para todos los backends.
ACME en la nube
Los principales proveedores cloud integran la automatización de certificados:
- AWS Certificate Manager (ACM): certificados gratuitos con renovación automática para los servicios AWS (ALB, CloudFront, API Gateway).
- Google Cloud Managed Certificates: renovación automática para los load balancers GCP.
- Azure App Service Managed Certificates: certificados gratuitos y renovados automáticamente.
- Cloudflare: certificados edge y origin gestionados automáticamente, con soporte de certificados de 15 días.
ACME renewal information (ARI, RFC 9773)
ARI es una extensión ACME que permite a la CA comunicar al cliente la ventana óptima de renovación. En lugar de renovar sistemáticamente a un porcentaje fijo de la duración restante, el cliente consulta a la CA para conocer el momento ideal. Esto permite a la CA distribuir la carga y señalar una renovación anticipada en caso de compromiso de clave. Let's Encrypt soporta ARI desde 2024.
NGINX y el módulo ACME nativo
En agosto de 2025, NGINX publicó un módulo nativo ACME que permite al servidor web obtener y renovar sus certificados directamente, sin cliente externo. Esta integración simplifica considerablemente el despliegue en entornos que usan NGINX como frontend.
Soluciones empresariales
Para las grandes organizaciones que gestionan miles de certificados, las soluciones CLM (Certificate Lifecycle Management) orquestan la renovación a escala:
- HashiCorp Vault PKI: motor PKI integrado en Vault, con emisión y rotación automatizadas.
- Venafi / CyberArk: plataforma CLM enterprise (CyberArk adquirió Venafi por 1540 millones de dólares en 2024).
- Keyfactor: plataforma de gestión del ciclo de vida de certificados e identidades de máquina.
- Sectigo Certificate Manager: CLM con ACME integrado, cubriendo certificados públicos y privados.
Let's Encrypt como pionero
Let's Encrypt no esperó a SC-081v3 para empujar a la industria hacia certificados cortos. La autoridad de certificación gratuita y automatizada posee aproximadamente el 63,9 % de cuota de mercado de los certificados TLS web y emite más de 10 millones de certificados al día. Su influencia en el ecosistema es considerable.
Certificados de 6 días en producción
Desde enero de 2026, Let's Encrypt ofrece certificados de 6 días en disponibilidad general. Estos certificados ultracortos están dirigidos a entornos altamente automatizados (CDN, plataformas cloud, CI/CD) donde la renovación está totalmente gestionada por ACME. El objetivo: demostrar que duraciones de vida muy cortas funcionan a escala industrial.
Hacia certificados de 45 días por defecto
Let's Encrypt ha anunciado un plan de transición hacia certificados de 45 días por defecto. El calendario prevé una fase opt-in a partir de mayo de 2026, seguida de un cambio al valor por defecto de 45 días en febrero de 2028. Esta anticipación del calendario SC-081v3 (que impone 47 días en marzo de 2029) da al ecosistema un año de ventaja para validar los pipelines de automatización.
El abandono de OCSP
A finales de 2024, Let's Encrypt anunció el abandono progresivo de OCSP, completado en 2025. La razón: OCSP no funciona (soft-fail en los navegadores, problemas de privacidad, carga en el servidor). Esta decisión aceleró la reflexión de la industria sobre la revocación y reforzó el argumento de los certificados cortos. Si la revocación no funciona, la única alternativa es limitar la duración de vida de los certificados.
Let's Encrypt demuestra cada día que la automatización a gran escala es viable. Más de 400 millones de sitios web usan sus certificados. El paso a 47 días no será un problema para los entornos ya automatizados: será un no-evento.
Impacto en los certificados de pago y el ecosistema CA
SC-081v3 transforma el modelo de negocio de las autoridades de certificación y pone en cuestión el valor añadido de los certificados de pago.
OV y EV: siguen siendo válidos, pero más cortos
Los certificados OV (Organization Validation) y EV (Extended Validation) siguen disponibles. La validación de organización (verificación de la identidad de la empresa, dirección, número de registro) sigue aportando un valor diferencial respecto a la simple validación de dominio. Pero la duración del certificado se reduce de la misma manera: 200 días en 2026, 100 días en 2027, 47 días en 2029. Un certificado EV de 47 días impone el mismo ritmo de renovación que un certificado DV.
El giro hacia suscripciones y CLM
Las CA de pago están pivotando su modelo de negocio. En lugar de vender certificados unitarios con duración fija, ofrecen suscripciones anuales que incluyen renovaciones ilimitadas y un cliente ACME integrado. DigiCert, Sectigo y GlobalSign ofrecen plataformas CLM (Certificate Lifecycle Management) que automatizan la renovación ACME para certificados OV y EV.
La consolidación del mercado CA
La adquisición de Venafi por CyberArk por 1540 millones de dólares en 2024 ilustra la consolidación del mercado. El valor se desplaza de la emisión de certificados hacia la gestión del ciclo de vida. Las CA que no ofrecen automatización integrada pierden cuota de mercado frente a Let's Encrypt y las soluciones CLM.
Wildcards y multi-SAN
Los certificados wildcard (*.captaindns.com) y multi-SAN (varios dominios en un solo certificado) requieren el challenge DNS-01 para la validación. Con renovaciones cada 47 días, la automatización del challenge dns-01 a través de la API del proveedor DNS se vuelve indispensable. Los principales proveedores DNS (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) ofrecen todos APIs compatibles con los clientes ACME.
La automatización cuestiona el certificado de pago
La automatización ACME nivela el terreno de juego. Un certificado DV gratuito de Let's Encrypt, renovado automáticamente cada 47 días, ofrece el mismo nivel de cifrado que un certificado EV de pago. La diferencia se limita a la barra de direcciones del navegador (que ya no muestra el nombre de la organización desde 2019) y a la garantía financiera asociada al certificado. Para la mayoría de los sitios web, esta diferencia ya no justifica el sobrecoste.
Interacción con SC-085v2: DNSSEC y renovaciones frecuentes
SC-081v3 y SC-085v2 entran en vigor el mismo mes y crean un efecto multiplicador en la cadena de confianza DNS. Para entender SC-085v2 en detalle, consulta nuestro artículo dedicado.
El efecto multiplicador
Con SC-085v2, cada validación de dominio (DCV) incluye ahora una verificación DNSSEC. Con la fase 3 de SC-081v3, un certificado de 47 días implica aproximadamente 8 renovaciones al año en lugar de 1. Cada renovación desencadena una DCV, y cada DCV verifica DNSSEC. El número de verificaciones DNSSEC ligadas a los certificados se multiplica por 8.
Escenario de caída: DNSSEC roto + certificados cortos
Consideremos un escenario concreto. Tu certificado TLS expira en 15 días. Tu cliente ACME intenta la renovación. La CA realiza la validación DNS-01 y verifica DNSSEC conforme a SC-085v2. Pero una rotación de clave DNSSEC ha fallado: el registro DS en el TLD ya no corresponde a la KSK de tu zona. El resolvedor de la CA devuelve BOGUS, la DCV falla y el certificado no se renueva.
Con un certificado de 398 días, tienes meses para detectar y corregir el problema. Con un certificado de 47 días, tienes como máximo 17 días (el margen integrado en el ciclo de renovación). Si el problema DNSSEC persiste, tu certificado expira y tu sitio se vuelve inaccesible.
Rotación DANE/TLSA y certificados cortos
Si usas DANE para autenticar tus certificados TLS mediante registros TLSA firmados por DNSSEC, la rotación de los registros TLSA debe seguir el ritmo de las renovaciones de certificados. Con un certificado de 47 días, el registro TLSA debe actualizarse en cada renovación (salvo en modo DANE-EE 3 1 1 con SPKI, que sobrevive a la renovación si la clave pública no cambia). Consulta nuestra guía DANE/TLSA para las estrategias de rotación.
Pipeline unificado: la recomendación
La combinación SC-081v3 + SC-085v2 impone un enfoque unificado. El pipeline de renovación de certificados debe integrar:
- La renovación ACME del certificado TLS
- La verificación previa de la cadena DNSSEC
- La actualización de los registros DANE/TLSA si es necesario
- La monitorización continua de los tres componentes
Tratar estos elementos por separado multiplica los puntos de fallo. Un pipeline unificado que verifique DNSSEC antes de lanzar la renovación ACME, y luego actualice TLSA tras la emisión, reduce considerablemente el riesgo de caída.
Guía práctica: preparar tu infraestructura
La transición hacia certificados de 47 días se realiza en 4 fases a lo largo de 3 años. Cada fase impone restricciones más estrictas. Aquí tienes los 6 pasos para preparar tu infraestructura.
Paso 1: inventariar todos tus certificados
Antes de automatizar, necesitas saber qué gestionas. Usa varias fuentes para elaborar un inventario completo:
- Certificate Transparency logs: consulta los logs CT (crt.sh) para listar todos los certificados emitidos para tus dominios.
- Escaneo de red: usa herramientas como
sslyzeonmappara descubrir los certificados activos en tu infraestructura. - Herramientas CLM: plataformas como Keyfactor o Venafi Discovery escanean tu red y tus nubes para identificar certificados no catalogados.
- Nuestro DNSSEC Checker: verifica la cadena de confianza DNSSEC, indispensable para la renovación de certificados desde SC-085v2.
Documenta para cada certificado: el dominio, la CA emisora, la fecha de expiración, el tipo (DV/OV/EV), el modo de renovación (manual o automatizado) y el responsable.
Paso 2: desplegar un cliente ACME adecuado
Elige un cliente ACME adaptado a tu entorno:
- Servidor web standalone: Certbot con el plugin apropiado (Apache, NGINX) o Caddy con ACME integrado.
- Entorno containerizado: cert-manager para Kubernetes, Lego para los pipelines CI/CD.
- Infraestructura cloud: AWS ACM, Google Cloud Managed Certificates o Azure App Service Managed Certificates.
- Entorno mixto: acme.sh por su flexibilidad y compatibilidad con más de 150 API DNS.
Prueba la renovación con un dry-run antes de pasar a producción. Valida que el cliente pueda renovar sin intervención humana.
Paso 3: automatizar la validación DNS
Para el challenge dns-01 (requerido para los certificados wildcard), tu cliente ACME debe poder crear y eliminar registros TXT a través de la API de tu proveedor DNS. Configura los accesos API con permisos mínimos: creación y eliminación de registros TXT bajo _acme-challenge únicamente.
Si tu proveedor DNS no ofrece API, migra a un proveedor que la ofrezca. En 2026, la ausencia de API DNS es un factor bloqueante.
Paso 4: verificar tu cadena DNSSEC
Con SC-085v2, una cadena DNSSEC rota bloquea la renovación de certificados. Verifica:
- La presencia y validez del registro DS en el TLD
- La coherencia entre el DS y la KSK publicada en tu zona
- La validez de las firmas RRSIG (fechas de expiración)
- La automatización de la rotación de claves ZSK y KSK
Consulta nuestra guía sobre la cadena de confianza DNSSEC para los detalles técnicos. Usa el DNSSEC Checker para un diagnóstico completo.
Paso 5: implementar la monitorización
Despliega alertas en tres ejes:
- Expiración de los certificados TLS: alerta a 30 días, 14 días y 7 días antes de la expiración.
- Firmas DNSSEC (RRSIG): alerta cuando las firmas se acercan a su fecha de expiración.
- Registros DANE/TLSA: verificación de que los registros TLSA corresponden al certificado activo.
La monitorización es la red de seguridad que detecta los fallos de automatización antes de que se conviertan en caídas.
Paso 6: planificar la migración progresiva
No esperes a marzo de 2029 para pasar a 47 días. Adopta un plan progresivo:
- Desde ahora: automatiza todos los certificados con duraciones de 90 días (Let's Encrypt por defecto).
- 2026: prueba los certificados de 6 días de Let's Encrypt en un entorno de staging.
- 2027: pasa a producción con certificados de 100 días o menos.
- 2028: activa los certificados de 45 días de Let's Encrypt (opt-in) para validar tu pipeline antes del plazo.
- 2029: el paso a 47 días es un no-evento, tu infraestructura está lista.
Plan de acción: preparar tu infraestructura
- Inventariar todos tus certificados: discovery via CT logs, escaneo de red, herramientas CLM
- Desplegar un cliente ACME: Certbot, acme.sh o Lego según el entorno
- Automatizar la validación DNS: API del proveedor DNS para el challenge dns-01
- Verificar DNSSEC: cadena de confianza válida, rotaciones de claves automatizadas
- Implementar la monitorización: alertas de expiración de certificados + RRSIG + TLSA
- Probar con certificados cortos: Let's Encrypt 90 d y luego 6 d para validar el pipeline
FAQ
Qué es el Ballot SC-081v3 del CA/Browser Forum?
SC-081v3 es un ballot aprobado en abril de 2025 por el CA/Browser Forum que reduce progresivamente la duración de vida máxima de los certificados TLS públicos. La duración pasa de 398 días a 200 días (marzo 2026), después 100 días (marzo 2027) y finalmente 47 días (marzo 2029). También reduce el período de reutilización de las pruebas de validación de dominio (DCV) hasta 10 días en la fase final.
Cuándo son obligatorios los certificados de 47 días?
Los certificados de 47 días máximo son obligatorios a partir del 15 de marzo de 2029 (fase 3 del ballot). Antes de esa fecha, se aplican dos fases intermedias: 200 días máximo desde el 15 de marzo de 2026 y 100 días máximo desde el 15 de marzo de 2027. Los certificados emitidos antes de cada fecha límite siguen siendo válidos hasta su expiración natural.
Mis certificados actuales serán revocados?
No. Los certificados ya emitidos siguen siendo válidos hasta su fecha de expiración, independientemente de la fase en curso. SC-081v3 se aplica únicamente a los nuevos certificados emitidos después de cada fecha de entrada en vigor. Un certificado de 398 días emitido el 14 de marzo de 2026 seguirá siendo válido durante toda su duración.
Por qué 47 días y no un número redondo?
El número 47 corresponde a un ciclo de renovación de 30 días más un margen de 17 días. Si el cliente ACME renueva 30 días antes de la expiración (la práctica recomendada), quedan 17 días de margen en caso de fallo en la renovación. Este margen permite detectar y corregir los problemas antes de la expiración efectiva del certificado.
Los certificados EV y OV están afectados?
Sí. SC-081v3 se aplica a todos los tipos de certificados TLS públicos, incluidos DV, OV y EV. No hay ninguna excepción. La distinción entre estos tipos se refiere al nivel de verificación de la identidad de la organización, no a la duración del certificado. Un certificado EV estará limitado a 47 días igual que un certificado DV a partir de marzo de 2029.
Qué es la reducción de la reutilización DCV?
La reutilización DCV (Domain Control Validation) permite a una CA reutilizar una prueba de control de dominio para emitir varios certificados sin solicitar una nueva validación. SC-081v3 reduce esta ventana de 398 días a 10 días en la fase final. Concretamente, cada renovación de certificado en la fase 3 requerirá una nueva prueba de control del dominio.
Debo pasarme a Let's Encrypt?
No necesariamente. Let's Encrypt es una opción sólida para los certificados DV automatizados, pero otras CA también soportan ACME: DigiCert, Sectigo, GlobalSign y ZeroSSL ofrecen endpoints ACME. Si necesitas certificados OV o EV, deberás quedarte con una CA de pago, pero con un cliente ACME para la renovación automatizada.
Cómo funciona ACME para la renovación automática?
ACME (RFC 8555) automatiza el diálogo entre tu servidor y la CA. El cliente ACME demuestra que controlas el dominio (mediante un challenge HTTP-01, DNS-01 o TLS-ALPN-01), la CA verifica la prueba y luego emite el certificado. El cliente programa la renovación automática antes de la expiración. Todo el proceso se realiza sin intervención humana.
Cuál es la relación entre SC-081v3 y SC-085v2 (DNSSEC)?
SC-085v2 obliga a las CA a validar DNSSEC durante la DCV. SC-081v3 multiplica las DCV al acortar la duración de los certificados. Combinados, estos dos ballots crean un efecto multiplicador: 8 renovaciones al año (47 días) significan 8 verificaciones DNSSEC en lugar de 1. Un DNSSEC roto bloquea de forma más rápida y más frecuente la renovación de tus certificados.
Los certificados internos (PKI privada) están afectados?
No. SC-081v3 se aplica únicamente a los certificados emitidos por CA públicamente aprobadas (aquellas cuyo certificado raíz está incluido en los almacenes de confianza de los navegadores). Los certificados emitidos por una PKI privada interna de tu organización no están sujetos a los Baseline Requirements del CA/Browser Forum y no se ven afectados por esta reducción.
Glosario
- CA/Browser Forum: consorcio que agrupa a las autoridades de certificación y a los editores de navegadores. Publica los Baseline Requirements, el marco normativo que todas las CA públicas deben respetar para que sus certificados sean aceptados por los navegadores.
- Ballot: propuesta de modificación de los Baseline Requirements sometida a votación de los miembros del CA/Browser Forum. Un ballot debe obtener una supermayoría del lado CA y la unanimidad del lado navegadores para ser aprobado.
- DCV (Domain Control Validation): proceso por el cual una CA verifica que el solicitante de un certificado controla efectivamente el dominio. Los métodos habituales son DNS-01, HTTP-01 y email. La reutilización DCV permite reutilizar una prueba existente para emisiones posteriores.
- ACME (Automatic Certificate Management Environment): protocolo estandarizado (RFC 8555) para la automatización de la emisión y la renovación de certificados TLS. Utilizado por Let's Encrypt, certbot, acme.sh, Lego y cert-manager.
- CRL (Certificate Revocation List): lista de certificados revocados publicada por una CA. Las CRL son voluminosas (varios cientos de MB) y rara vez consultadas por los navegadores, lo que limita su eficacia.
- OCSP (Online Certificate Status Protocol): protocolo de verificación en tiempo real del estado de revocación de un certificado. En la práctica, los navegadores ignoran los errores OCSP (soft-fail), haciendo el mecanismo ineficaz. Let's Encrypt abandonó OCSP en 2025.
- Criptoagilidad: capacidad de un sistema para migrar rápidamente hacia nuevos algoritmos criptográficos. Los certificados cortos facilitan esta migración al limitar la duración durante la cual un algoritmo obsoleto permanece en servicio.
- DANE/TLSA: protocolo que permite publicar en el DNS (mediante registros TLSA firmados por DNSSEC) el certificado esperado en un servidor. Elimina la dependencia de las CA para la autenticación del certificado.
