Mayor seguridad con certificados TLS con validez de 47 días para 2029.

Si su organización gestiona certificados TLS públicos en la actualidad y todavía depende de flujos de trabajo de renovación manuales, recordatorios de calendario o cualquier proceso que requiera que una persona detecte una fecha de vencimiento inminente y tome medidas, los próximos tres años van a ser realmente disruptivos.

El 11 de abril de 2025, el Foro CA/Browser aprobó la boleta SC-081v3, formalmente titulado “Presentar un cronograma para la reducción de los períodos de validez y reutilización de datos.” The vote was unambiguous: 25 Certificate Authorities in favor, zero against, with all four major browser vendors, Apple, Google, Microsoft, and Mozilla, voting yes. The result is a locked, phased schedule that reduces the maximum validity of all publicly trusted TLS certificates from 398 days today, down to 47 days by March 15, 2029.

En este blog, explicaremos con detalle qué exige la norma SC-081v3, por qué el Foro CA/Browser tomó esta decisión, cuáles son las consecuencias operativas para los equipos que gestionan certificados TLS y qué debería hacer su organización ahora mismo para adelantarse a cada fase.

TL; DR

• La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS de confianza pública de 398 días a 47 días en tres fases: 200 días a partir del 15 de marzo de 2026, 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029.
• Los períodos de reutilización de la validación de control de dominio (DCV) se reducen al mismo ritmo, hasta llegar a tan solo 10 días en 2029, lo que convierte la validación automatizada basada en ACME en un requisito en lugar de una conveniencia.
• Según los estudios del sector de 2025 y 2026 citados a continuación, el 72 % de las organizaciones ya han reportado al menos una interrupción relacionada con certificados en el último año, y solo el 34 % afirma tener una visión completa y actualizada de sus propios certificados.
• La renovación manual y los recordatorios del calendario no son adecuados para certificados de 47 días. La automatización basada en ACME, la verificación de la implementación y un inventario centralizado de certificados son ahora requisitos básicos, no optimizaciones.

Qué cambió y cuándo

La propuesta SC-081v3 fue presentada originalmente por Apple en enero de 2025, y el período de revisión de los derechos de propiedad intelectual finalizó el 13 de mayo de 2025 sin objeciones, lo que la convierte en plenamente aplicable a partir de esa fecha.

La propuesta modifica dos secciones de los Requisitos Básicos del TLS:

• Sección 6.3.2: establece el cronograma gradual para reducir los períodos máximos de validez de los certificados TLS.
• Sección 4.2.1: establece el cronograma paralelo para reducir el tiempo durante el cual se puede reutilizar la evidencia de validación de control de dominio (DCV) entre emisiones de certificados.

Ambos cambios entran en vigor en las mismas tres fases; todas ellas el 15 de marzo de cada año:

Fase	Fecha de vigencia	Validez máxima del certificado TLS	Período de reutilización del DCV
Fase 1	Marzo 15, 2026	200 días	200 días
Fase 2	Marzo 15, 2027	100 días	100 días
Fase 3	Marzo 15, 2029	47 días	10 días

Antes de que una Autoridad de Certificación (CA) pueda emitir un certificado TLS para un dominio, primero debe verificar que el solicitante realmente controla dicho dominio. Esto se conoce como validación de control de dominio. En la práctica, una CA requiere que el solicitante complete un desafío, generalmente colocando un archivo específico en una URL conocida del dominio (HTTP-01), agregando un registro DNS TXT específico (DNS-01) o respondiendo a un correo electrónico de validación enviado a una dirección de contacto registrada para el dominio. Una vez que la CA confirma que el desafío se ha superado, considera que el dominio está validado. Históricamente, esta evidencia de validación podía reutilizarse hasta por 398 días, lo que significa que una CA podía emitir certificados posteriores para el mismo dominio sin requerir una nueva prueba durante más de un año.

SC-081v3 reduce este período de reutilización en consonancia con la validez del certificado, reduciéndolo finalmente a tan solo 10 días para marzo de 2029. En ese momento, la propiedad del dominio deberá verificarse nuevamente en casi cada renovación de certificado, lo que convierte la DCV automatizada, mediante el protocolo de desafío-respuesta de ACME , en un requisito operativo indispensable en lugar de una optimización. Para obtener más información sobre la automatización del paso de validación del dominio, consulte la guía de Encryption Consulting sobre DCV persistente y conectores DNS.

A día de hoy, la Fase 1 ya está en vigor, y cualquier certificado TLS nuevo que se emita tendrá una validez máxima de 200 días. Los certificados emitidos antes de la fecha límite de cada fase conservan su validez original. Cualquier certificado emitido en o después de cada fecha límite deberá cumplir con el nuevo plazo máximo de validez para esa fase, ya que no existe un período de gracia para los certificados recién emitidos.

Por qué el Foro CA/Navegador tomó esta decisión

La tendencia a reducir la validez de los certificados lleva años gestándose. Los certificados TLS tenían una validez de hasta cinco años hasta 2015, cuando el CA/Browser Forum la redujo a tres. En 2018, el máximo se redujo a dos años. En 2020, Apple limitó unilateralmente la confianza en los nuevos certificados a 398 días en Safari, lo que obligó al sector a adoptar ese límite de forma generalizada.

• Limitar el radio de explosión: Cuando se roba una clave privada, se emite un certificado de forma fraudulenta o se descubre que un algoritmo de firma es débil, el daño potencial es directamente proporcional al tiempo que el certificado permanece válido. Un certificado con 47 días de validez restante representa un margen de confianza vulnerable mucho menor que uno con 398 días.
• Hacer efectiva la revocación: La revocación de certificados, en la práctica, está en gran medida rota. El Protocolo de estado de certificados en línea (OCSP) funciona sobre una base de fallo suave en la mayoría de los navegadores, es decir, si el respondedor OCSP no es accesible, los navegadores normalmente continúan en lugar de bloquear la conexión. Listas de revocación de certificados (CRL) se actualizan con poca frecuencia y se revisan de forma inconsistente. Let's Encrypt comenzó a eliminar gradualmente OCSP por completo en 2024 y completó esa transición en 2025, citando su ineficacia.
• Prácticas criptográficas más rigurosas: Los certificados de larga duración permiten a las organizaciones aplazar las migraciones de algoritmos. Un certificado emitido con una clave débil o un algoritmo obsoleto en 2023 podría seguir en producción en 2026 si su validez se extiende hasta entonces. Los periodos de validez más cortos obligan a una emisión más frecuente, lo que implica más oportunidades para aplicar los estándares de algoritmos y claves actuales.
• Automatización requerida: El Foro CA/Browser ha declarado explícitamente que uno de los objetivos de SC-081v3 es impulsar la adopción de la gestión automatizada del ciclo de vida de los certificados. Un certificado de 47 días que se renueva cada seis semanas no es compatible con los procesos manuales, ya que la carga operativa es demasiado elevada. Esto hará que este proceso sea más fiable, auditable y resistente que cualquier proceso que dependa de la intervención humana.

La magnitud del problema: lo que muestran los datos

La disrupción descrita anteriormente no es hipotética. Investigaciones recientes del sector sobre la gestión de certificados e identidad de máquinas aportan datos reales que la respaldan:

• 72% of organizations experienced at least one certificate-related outage in the past 12 months, and 45% said outages were happening weekly, up from just 12% weekly in 2022, according to CyberArk’s Informe sobre el estado de la seguridad de la identidad de las máquinas de 2025.
• Only 34% of organizations have a complete, current view of their own digital certificates, and nearly three-quarters are very or extremely concerned about outages caused by expired certificates, per DigiCert’s Informe global de investigación sobre PKI de 2026Publicado el 2 de junio de 2026 y basado en una encuesta realizada a más de 400 altos directivos de TI y seguridad.
• Machine identities now outnumber human identities by an estimated 82 to 1, and 79% of security leaders expect that number to grow further, by as much as 150%, over the next year, according to CyberArk research cited in its Actualización del portafolio de seguridad de identidad de máquinas de octubre de 2025.

Estas cifras describen una industria que ya estaba sobrecargada con una validez de 398 días. Comprimir la misma carga de trabajo en ciclos de 47 días, con mucho menos margen para una renovación no realizada o un dominio no verificado, es algo que los procesos manuales no pueden absorber. Para obtener más información sobre cómo el crecimiento de la identidad de máquina agrava este problema, especialmente para los equipos de PKI, consulte la Guía de identidad de máquina para equipos de PKI de Encryption Consulting.

¿Qué significan operativamente los certificados de 47 días?

Las consecuencias operativas de SC-081v3 varían significativamente según el tamaño y la complejidad de la configuración de su certificado y el estado actual de sus prácticas de gestión de certificados.

Visibilidad del inventario de certificados

No se puede gestionar la renovación de certificados cuya existencia se desconoce. La dispersión de certificados, donde estos se emiten en múltiples equipos, entornos de nube, clústeres de Kubernetes , configuraciones de CDN y servidores heredados sin un seguimiento centralizado, es la causa más común de problemas de caducidad. Con ciclos de renovación anuales, un certificado no detectado puede pasar desapercibido durante meses antes de caducar. Con ciclos de 47 días, un certificado sin seguimiento caducará a las pocas semanas de su emisión.

La creación de una visibilidad integral del inventario de certificados en todos los entornos, incluidos los servicios internos, la infraestructura que no está orientada al cliente y los certificados gestionados por equipos externos o servicios de terceros, es el requisito fundamental para esta actualización del cronograma de validez de los certificados.

Integración de CI/CD y despliegue

Uno de los fallos más comunes en entornos de certificados automatizados es la brecha entre la renovación y el despliegue. En este caso, el cliente ACME obtiene correctamente un nuevo certificado, pero el paso de despliegue que lo instala en el servidor, balanceador de carga o entrada de Kubernetes correspondiente falla silenciosamente. El certificado renovado permanece en un sistema de archivos o almacén de secretos, mientras que el antiguo sigue gestionando el tráfico hasta que caduca.

Con una validez de 47 días, la falta de implementación constituye un fallo crítico. La renovación del certificado debe integrarse con la implementación y el nuevo certificado debe verificarse como implementado y gestionando el tráfico antes de que la renovación se considere completa.

Infraestructura heredada y fijación de certificados

Las aplicaciones heredadas con certificados codificados, los dispositivos IoT con autoridades de certificación integradas en el firmware, los sistemas que utilizan el anclaje de certificados y los entornos con procesos de implementación manuales representan puntos en los que los certificados de 47 días crean verdaderos desafíos que la automatización por sí sola no puede resolver.

El anclaje de certificados, donde un cliente se configura para confiar únicamente en un certificado o clave pública específicos, en lugar de cualquier certificado de una CA de confianza, es fundamentalmente incompatible con la validez de 47 días. Si el certificado anclado debe reemplazarse cada seis semanas, la configuración del cliente debe actualizarse con la misma frecuencia. La única solución viable para entornos con anclaje de certificados es migrar completamente a la verificación de confianza estándar basada en CA antes de que entre en vigor la normativa de 47 días.

Gestión manual frente a gestión automatizada de certificados: ¿Qué enfoque resiste 47 días?

Antes de repasar el plan de preparación de siete pasos que se detalla a continuación, resulta útil ver los dos modelos operativos uno al lado del otro.

Requisito con validez de 47 días	Manual / basado en calendario	Gestión automatizada del ciclo de vida del cliente (ACME + CertSecure Manager)
Renovaciones por certificado al año	1 en la actualidad, cifra que aumentará a más de 8 para 2029.	Mismo volumen, sin aumento de personal.
Validación de dominio (reutilización de DCV cada 10 días para 2029)	Volver a realizarlo manualmente en cada renovación.	Interacción máquina a máquina mediante ACME
Inventario de certificados	Hojas de cálculo y conocimiento tribal	Descubrimiento continuo en la nube, en entornos locales y en Kubernetes.
Brecha entre renovación y despliegue	Es común que los certificados renovados permanezcan sin usar mientras caducan los antiguos.	El despliegue se verifica automáticamente antes de que la renovación se marque como completada.
Riesgo de interrupción	Alta, en consonancia con la tasa de interrupción del sector del 72% citada anteriormente.	Menor; la renovación se activa en función de la fecha de vencimiento, no de un recordatorio del calendario.
Informes de auditoría y cumplimiento	Extracción manual de registros, inconsistente	Historial centralizado y exportable de renovaciones y emisiones

Los procesos manuales ya resultaban saturados con una validez de 398 días. Con 47 días, y dado que la validación del dominio se realiza casi con la misma frecuencia que la emisión, dejan de ser una opción viable para cualquier organización que gestione más de un puñado de certificados públicos.

Prepárese para la menor validez del certificado TLS.

Con la Fase 1 ya en marcha y la Fase 2 prevista para marzo de 2027, el plazo para construir la infraestructura necesaria para la era de los 47 días no es ilimitado. A continuación, se presenta una secuencia práctica para la preparación:

Paso 1: Cree un inventario completo de certificados.

Descubra todos los certificados TLS públicos que su organización ha emitido, en todos los entornos y equipos. Utilice la monitorización de registros de Transparencia de Certificados (CT), las API de proveedores en la nube, el escaneo de red y las integraciones con la consola de administración de su CA para crear un inventario centralizado. CBOM Secure de Encryption Consulting está diseñado específicamente para esto. Realiza un descubrimiento criptográfico continuo en toda su configuración, lo que le proporciona una visión completa de cada objeto criptográfico antes de comenzar a automatizar cualquier proceso. Este es el paso fundamental, ya que todo lo demás depende de conocer su entorno.

Paso 2: Establecer alertas de renovación con plazos de entrega adecuados.

Los umbrales de alerta deben reconfigurarse en cada fase. Con una validez inferior a 200 días (Fase 1), configure las alertas de renovación 60 días antes del vencimiento. Con una validez inferior a 100 días (Fase 2), configure las alertas 30 días antes. Con una validez inferior a 47 días, las alertas deben activarse entre los 25 y 30 días, con alertas progresivas a los 14 y 7 días.

Paso 3: Estandarizar el uso de ACME para la emisión de certificados.

ACME (Automated Certificate Management Environment) es el protocolo diseñado específicamente para la emisión y renovación automatizada de certificados. CertSecure Manager de Encryption Consulting admite ACME de forma nativa, junto con los protocolos SCEP y EST, lo que lo convierte en la plataforma ideal para estandarizar la emisión y renovación automatizada de certificados a cualquier escala. Se integra directamente con CA públicas y privadas, lo que garantiza que sus flujos de trabajo de renovación basados ​​en ACME sean totalmente compatibles con cualquier CA que utilice su organización. Para obtener más información sobre la automatización del paso de validación de dominio, incluidos los conectores DCV persistentes y DNS, consulte la guía de Encryption Consulting sobre la automatización de la validación DNS con CertSecure Manager.

Paso 4: Eliminar los intervalos de renovación predefinidos

Audite todos los scripts, tareas programadas y configuraciones de automatización que controlan la renovación de certificados. Cualquier configuración con un intervalo de renovación fijo, como «renovar cada 60 días» o «renovar cada 90 días», dejará de funcionar a medida que la vida útil de los certificados se acorte. Sustitúyala por una lógica de renovación dinámica basada en las fechas de caducidad de los certificados o en las señales ARI de ACME.

Paso 5: Cerrar la brecha entre renovación e implementación.

Para cada certificado de su inventario, verifique que el proceso de renovación incluya un paso de implementación y un paso de verificación posterior a la implementación, confirmando que el certificado renovado se esté entregando a los clientes. Esto es fundamental en entornos donde la renovación y la implementación se gestionan mediante sistemas o equipos independientes.

Paso 6: Abordar la infraestructura heredada

Identifique los sistemas que no pueden participar en la renovación automática, incluidos los servidores heredados, los certificados integrados en el firmware y las configuraciones fijas. Para cada uno, defina una ruta de migración antes de que la Fase 2 lo exija. Estos suelen ser los cambios que requieren más tiempo y recursos, y deben comenzar mucho antes de la fecha límite.

Paso 7: Establecer visibilidad y gobernanza centralizadas.

Adopte una plataforma centralizada de gestión del ciclo de vida de los certificados (CLM), como nuestro CertSecure Manager, que ofrece inventario unificado, automatización de renovaciones, orquestación de implementaciones e informes de cumplimiento en todos los entornos. La complejidad operativa de la era de los 47 días no es compatible con la gestión fragmentada de certificados por entorno.

Cómo puede ayudar la consultoría de cifrado

En Encryption Consulting, hemos creado una cartera de productos y servicios diseñados específicamente para ayudar a las organizaciones a afrontar la transición de certificados de 47 días, desde la gestión automatizada del ciclo de vida y el descubrimiento criptográfico hasta la infraestructura de clave pública (PKI) totalmente gestionada y la preparación post-cuántica.

CertSecure Manager es la plataforma de gestión del ciclo de vida de certificados de Encryption Consulting y la respuesta más directa a lo que exige el plazo de 47 días. Automatiza la emisión, renovación e implementación de certificados a gran escala mediante los protocolos ACME, SCEP y EST, y está diseñada específicamente para ciclos de renovación frecuentes donde los procesos manuales resultan insuficientes.

La plataforma automatiza la inscripción y renovación de certificados en servidores web como Apache, Tomcat e IIS, y con balanceadores de carga como F5 BIG-IP. Se integra con autoridades de certificación públicas de confianza como DigiCert y Entrust, y con autoridades de certificación privadas de confianza como Microsoft PKI, AWS Private CA y HashiCorp CA. Las renovaciones se activan dinámicamente a partir de la fecha de vencimiento del certificado, en lugar de intervalos predefinidos, lo que garantiza su compatibilidad con cada nueva fase del calendario SC-081v3.

Está diseñada con la criptoagilidad como pilar fundamental y, a medida que los estándares PQC finalizados del NIST comienzan a influir en los requisitos de los navegadores y los programas raíz, la plataforma ayuda a las organizaciones a evaluar su postura criptográfica actual y a migrar a certificados seguros frente a la computación cuántica de forma controlada y gradual, sin necesidad de reemplazar la plataforma ni realizar migraciones manuales disruptivas. Para conocer la secuencia completa que sigue este trabajo de criptoagilidad, consulte la Guía de migración de criptografía post-cuántica (9 fases) de Encryption Consulting.

Además de nuestro CertSecure Manager, también ofrecemos PKI como servicio para organizaciones que necesitan gestionar el considerable aumento en la emisión de certificados, consecuencia de la vigencia de 47 días, sin necesidad de construir ni renovar su infraestructura PKI interna. Este servicio proporciona una PKI totalmente gestionada, diseñada para escalar con la nueva frecuencia de renovación. A medida que aumenten las tasas de emisión de certificados para 2029, las organizaciones con infraestructuras de CA internas con recursos insuficientes se enfrentarán a problemas de rendimiento y disponibilidad. PKI como servicio absorbe esta carga sin requerir cambios en la infraestructura interna, lo que permite a su equipo centrarse en la gobernanza y el cumplimiento normativo en lugar de en las operaciones de CA.

CBOM Secure es otro producto de Encryption Consulting para la detección e inventario criptográfico que le ayudará a lograr y ejecutar la hoja de ruta para el cambio de 47 días para los certificados TLS. Antes de poder automatizar la gestión de certificados, necesita saber con exactitud qué activos criptográficos existen en su entorno. CBOM Secure detecta todos los certificados en su infraestructura, para que sepa con precisión qué necesita automatizar antes de cada fecha límite. Para obtener más información sobre por qué la mayoría de los inventarios criptográficos pasan por alto este riesgo, consulte El punto ciego criptográfico oculto en su propia infraestructura.

Conclusión

La decisión del CA/Browser Forum de reducir la validez de los certificados TLS a 47 días para marzo de 2029 representa el cambio más significativo en la gestión del ciclo de vida de los certificados en más de una década. Con la Fase 1 ya en marcha y la Fase 2 prevista para marzo de 2027, el plazo de 47 días para 2029 se encuentra ahora a solo unos meses de distancia en los cronogramas de planificación de infraestructura.

Las organizaciones que comprendan y apliquen estas fases con fluidez serán aquellas que traten la gestión del ciclo de vida de los certificados como una infraestructura automatizada, supervisada, gobernada centralmente y sometida a pruebas continuas, en lugar de una tarea administrativa periódica. Las organizaciones que esperen a que cada fase fuerce la situación se enfrentarán a crisis operativas recurrentes, cuya frecuencia aumentará a medida que se acorten los periodos de validez.

En Encryption Consulting, estamos aquí para ayudarle en cada etapa de este proceso. Es el momento de construir esta infraestructura, antes de que la Fase 2 genere problemas y dificulte su gestión.

Preguntas frecuentes

¿Cuál es la norma del Foro CA/Browser sobre la validez de los certificados durante 47 días?

La propuesta SC-081v3, aprobada por el Foro CA/Browser en abril de 2025, reduce el período máximo de validez de los certificados TLS de confianza pública de 398 días a 47 días a partir del 15 de marzo de 2029. Se implementará gradualmente en tres etapas: 200 días a partir del 15 de marzo de 2026, 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029. Todos los principales proveedores de navegadores, incluidos Apple, Google, Microsoft y Mozilla, votaron a favor.

¿Es necesario reemplazar anticipadamente los certificados emitidos antes de la fecha límite de una fase?

No. Un certificado emitido antes de la fecha de entrada en vigor de una fase conserva su período de validez original hasta su vencimiento natural. El nuevo plazo máximo solo se aplica a los certificados emitidos o renovados en o después de cada fecha límite, por lo que no hay período de gracia para nuevas emisiones, pero los certificados existentes no se acortan retroactivamente.

¿Qué es la reutilización de la validación de control de dominio (DCV) y por qué es importante en este caso?

La reutilización de DCV (Verificación de Propiedad de Dominio) determina durante cuánto tiempo una Autoridad de Certificación puede confiar en una verificación previa de propiedad de dominio en lugar de volver a verificarla antes de emitir un nuevo certificado. La norma SC-081v3 reduce este período de reutilización al mismo ritmo que la validez del certificado, hasta solo 10 días para marzo de 2029, lo que convierte la validación automatizada de dominios basada en ACME en un requisito práctico en lugar de una simple conveniencia.

¿Se aplica la regla de los 47 días a los certificados internos o privados?

No. La norma SC-081v3 solo rige los certificados TLS de confianza pública, es decir, aquellos emitidos por las autoridades de certificación (CA) en los programas raíz de los navegadores para servidores con acceso a internet. La infraestructura de clave pública (PKI) privada o interna, utilizada exclusivamente dentro de una red corporativa, no está sujeta a los requisitos básicos del Foro de Autoridades de Certificación/Navegadores y puede seguir utilizando períodos de validez más largos, aunque muchas organizaciones optan por alinear su política interna con el calendario público para mantener la coherencia.

¿Cómo deberían las organizaciones empezar a prepararse para los certificados de 47 días?

Comience con un inventario completo de todos los certificados TLS públicos en uso, ya que los certificados no controlados son la causa más común de interrupciones por vencimiento. A partir de ahí, implemente la emisión y renovación automatizadas basadas en ACME, configure alertas de renovación que se reduzcan gradualmente en cada fase y aborde cualquier sistema heredado, como certificados fijados o integrados en el firmware, que no puedan participar en la renovación automatizada.