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

La propuesta SC-081v3 del Foro CA/Browser, aprobada en abril de 2025, reduce la validez máxima de los certificados TLS de confianza pública de 398 a 47 días a partir del 15 de marzo de 2029, en tres fases. Si su organización aún depende de flujos de trabajo de renovación manuales, recordatorios de calendario o cualquier proceso que requiera intervención humana para el seguimiento de la caducidad de los certificados, el cálculo operativo deja de ser viable antes de que llegue la fase final. La primera acción necesaria es un inventario completo de certificados: no se puede automatizar lo que no se encuentra.

Respuesta rápida: ¿En qué consiste el requisito del certificado TLS de 47 días?

La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS de 398 días a 47 días para el 15 de marzo de 2029, en tres fases: 200 días a partir del 15 de marzo de 2026 (ya en vigor), 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029. La reutilización de la validación de control de dominio (DCV) se reduce según el mismo calendario, alcanzando los 10 días en 2029. Los procesos de renovación manual no son compatibles con este calendario. Se requiere automatización basada en ACME.

Puntos Clave

• La propuesta SC-081v3 del Foro CA/Browser reduce la validez máxima de los certificados TLS 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. La fase 1 ya está en vigor.
• Los períodos de reutilización de la validación del control de dominio (DCV) se reducen al mismo ritmo, llegando a tan solo 10 días en 2029, lo que convierte la validación automatizada de dominios basada en ACME en un requisito operativo indispensable, no en una optimización.
• El 72 % de las organizaciones experimentaron al menos una interrupción relacionada con certificados en los últimos 12 meses, y solo el 34 % tiene una visión completa y actualizada de sus propios certificados. El cronograma de 47 días comprime esa misma carga de trabajo en ciclos seis veces más cortos.
• 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.
• El anclaje de certificados es fundamentalmente incompatible con la validez de 47 días. Los entornos que utilizan el anclaje deben migrar a la verificación de confianza estándar basada en CA antes de marzo de 2029.
• La brecha entre la renovación y la implementación, donde se obtiene un certificado renovado pero no se implementa, es un modo de fallo crítico con una validez de 47 días. La automatización debe incluir la verificación posterior a la implementación.

¿Qué cambios introdujo la propuesta electoral SC-081v3 y cuándo entra en vigor cada fase?

La propuesta SC-081v3 fue presentada originalmente por Apple en enero de 2025. El Foro CA/Browser la aprobó el 11 de abril de 2025, con 25 Autoridades de Certificación votando a favor y ninguna en contra. Los cuatro principales proveedores de navegadores (Apple, Google, Microsoft y Mozilla) votaron a favor. El período de revisión de derechos de propiedad intelectual finalizó el 13 de mayo de 2025 sin objeciones, lo que hizo que la propuesta fuera plenamente vinculante a partir de esa fecha.

La propuesta modifica dos secciones de los Requisitos Básicos de TLS del Foro CA/Browser:

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

Ambos cambios entrarán en vigor en tres fases, todas ellas el 15 de marzo de cada año:

Fase	Fecha efectiva	Validez máxima del certificado TLS	Período máximo de reutilización de DCV	estado actual
Fase 1	Marzo 15, 2026	200 días	200 días	En efecto. Cualquier certificado TLS nuevo emitido a partir de esta fecha tiene una vigencia máxima de 200 días.
Fase 2	Marzo 15, 2027	100 días	100 días	Próximamente. La frecuencia de renovación se duplica con respecto a la Fase 1.
Fase 3	Marzo 15, 2029	47 días	10 días	Próximamente. Los certificados se renuevan aproximadamente cada 6 semanas. El DCV debe volver a verificarse en casi todas las renovaciones.

La validación del control de dominio (DCV) es el proceso que utiliza una Autoridad de Certificación para verificar que el solicitante del certificado controla el dominio solicitado. Históricamente, esta evidencia validada podía reutilizarse hasta por 398 días. SC-081v3 reduce este período de reutilización a solo 10 días para marzo de 2029, lo que significa que la propiedad del dominio debe verificarse nuevamente en casi cada renovación del certificado. Para obtener una guía detallada sobre cómo automatizar el paso de DCV, consulte nuestra guía sobre DCV persistente y conectores DNS.

¿Por qué el Foro CA/Browser tomó esta decisión?

La tendencia hacia una menor validez de los certificados se ha ido gestando durante más de una década. Los certificados TLS tenían una validez de hasta cinco años hasta 2015. El máximo se redujo a tres años en 2015, a dos años en 2018 y a 398 días en 2020, cuando Apple limitó unilateralmente la confianza en los nuevos certificados en Safari. SC-081v3 continúa esta trayectoria con un límite fijo. El Foro CA/Browser articuló cuatro razones para este cambio:

• Limitar el alcance de los daños causados ​​por certificados comprometidos: 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 es directamente proporcional a la duración de la validez del certificado. Un certificado de 47 días representa un margen de confianza vulnerable mucho menor que un certificado de 398 días.
• Hacer efectiva la revocación: La revocación de certificados está en gran medida rota en la práctica. El Protocolo de estado de certificados en línea (OCSP) funciona sobre una base de fallo suave en la mayoría de los navegadores, lo que significa que si el respondedor OCSP no es accesible, los navegadores continúan en lugar de bloquear la conexión. Listas de revocación de certificados (CRL) se actualizan con poca frecuencia y se comprueban de forma inconsistente. Let's Encrypt eliminó por completo OCSP en 2024 y completó esa transición en 2025. Con una validez de 47 días, la expiración natural se convierte en el principal mecanismo de revocación.
• Implementar 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 puede permanecer en producción hasta 2025 con una validez de 398 días. Los periodos de validez más cortos obligan a una emisión más frecuente y a una aplicación más constante de los estándares de algoritmos y claves vigentes.
• Impulsar la adopción de la automatización: El Foro CA/Browser declaró 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 es operativamente incompatible con los procesos manuales, lo que convierte la automatización en un requisito estructural más que en una buena práctica.

¿Qué revelan los datos sobre el grado de madurez actual de la gestión de certificados?

La disrupción que crea SC-081v3 no es hipotética. Los estudios de la industria muestran un entorno que ya está sobrecargado con una validez de 398 días:

• Según el Informe sobre el estado de la seguridad de la identidad de las máquinas de 2025, el 72 % de las organizaciones experimentaron al menos una interrupción relacionada con certificados en los últimos 12 meses, y el 45 % afirmó que las interrupciones se producían semanalmente, frente a solo el 12 % que informaba de interrupciones semanales en 2022.
• Según una encuesta global realizada en 2026 a más de 400 altos directivos de TI y seguridad, solo el 34 % de las organizaciones tienen una visión completa y actualizada de sus propios certificados digitales, y casi tres cuartas partes están muy o extremadamente preocupadas por las interrupciones causadas por certificados caducados.
• Actualmente, se estima que las identidades de las máquinas superan a las identidades humanas en una proporción de 82 a 1, y el 79% de los líderes de seguridad prevén que esa proporción aumente aún más, hasta un 150%, durante el próximo año.

Estas cifras describen una industria que ya presentaba problemas con los ciclos de renovación anuales. Comprimir la misma carga de trabajo en ciclos de 47 días, con una ventana de reutilización de DCV de 10 días que requiere la reverificación del dominio en casi cada renovación, es algo que los procesos manuales no pueden gestionar. Para obtener más información sobre cómo el crecimiento de la identidad de las máquinas agrava este problema para los equipos de PKI, consulte nuestra Guía de identidad de máquinas para equipos de PKI.

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

Las consecuencias operativas de SC-081v3 varían según el tamaño y la complejidad del conjunto de certificados y el estado actual de las prácticas de gestión de certificados. Tres áreas generan los desafíos operativos más consistentes:

Visibilidad del inventario de certificados

No se puede automatizar la renovación de certificados cuya existencia se desconoce. La proliferación de certificados en múltiples equipos, entornos en la nube, clústeres de Kubernetes , configuraciones de CDN y servidores heredados 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. Crear una visibilidad completa del inventario de certificados en todos los entornos, incluidos los servicios internos, la infraestructura no orientada al cliente y los certificados gestionados por equipos externos, es el requisito fundamental para todo lo demás.

La brecha entre renovación y despliegue

Uno de los fallos más comunes en entornos de certificados automatizados es la brecha entre la renovación y el despliegue: 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 sin usar mientras el antiguo sigue gestionando el tráfico hasta su vencimiento. Con una validez de 47 días, esta brecha constituye un fallo crítico. La renovación del certificado debe integrarse con la verificación del despliegue, confirmando que el nuevo certificado se está utilizando realmente para los clientes antes de que la renovación se marque como completada.

Infraestructura heredada y fijación de certificados

Las aplicaciones heredadas con certificados codificados, los dispositivos IoT con autoridades de certificación (CA) integradas en el firmware y los entornos que utilizan la fijación de certificados representan situaciones en las que los certificados de 47 días plantean desafíos que la automatización por sí sola no puede resolver. La fijación de certificados, donde un cliente se configura para confiar únicamente en un certificado o clave pública específicos en lugar de en cualquier certificado de una CA de confianza, es fundamentalmente incompatible con la validez de 47 días. La única solución viable para entornos con fijación de certificados es migrar de esta práctica a la verificación de confianza estándar basada en CA antes de marzo de 2029.

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

La comparación que se muestra a continuación demuestra por qué los procesos manuales dejan de ser viables antes de que llegue la Fase 3:

Requisito con validez de 47 días	Manual o basado en calendario	Gestión automatizada del ciclo de vida del cliente (ACME + CertSecure Manager)
Renovaciones por certificado al año	1 hoy, cifra que aumentará a 8 o más para marzo de 2029.	Mismo volumen, sin aumento de personal.
Validación de dominio (reutilización de DCV cada 10 días para 2029)	Volver a ejecutar manualmente en cada ciclo de renovación.	Intercambio de desafío-respuesta entre máquinas mediante protocolos ACME (HTTP-01, DNS-01)
Inventario de certificados	Hojas de cálculo, conocimiento tribal y escaneos manuales	Descubrimiento continuo en la nube, en las instalaciones 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; cobertura inconsistente en todos los entornos.	Historial centralizado y exportable de renovaciones y emisiones en todos los entornos.
Automatización de vehículos eléctricos de corriente continua	Finalización manual del desafío; se interrumpe en la ventana de reutilización de 10 días.	ACME automatiza la finalización del desafío; los conectores DNS permiten la verificación continua de dominio persistente (DCV).

¿Cómo deben prepararse las organizaciones para el plazo de 47 días para la obtención del certificado?

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. La siguiente secuencia de siete pasos refleja el orden en que deben resolverse las dependencias:

1. Cree un inventario completo de certificados: Descubra todos los certificados TLS públicos en todos los entornos y equipos. Utilice la monitorización de registros de Transparencia de Certificados (CT), las API de proveedores de la nube, el escaneo de red y las integraciones con la consola de administración de su CA. CBOM seguro Realiza un descubrimiento criptográfico continuo en entornos de nube, locales y Kubernetes, lo que le brinda una visión completa de cada certificado antes de automatizar cualquier proceso. Este es el paso fundamental: todo lo demás depende de saber qué certificados tiene. Artefacto de evidencia: inventario completo de certificados con CA, fecha de vencimiento, ubicación de instalación y propietario para cada certificado.
2. Establecer alertas de renovación con plazos de entrega adecuados para 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 (Fase 3), las alertas se activarán entre los 25 y 30 días, con alertas de escalada a los 14 y 7 días. Artefacto de evidencia: Configuración de alertas de la plataforma CLM que muestra el umbral por entorno y fase.
3. Estandarizar el uso de ACME para la emisión de certificados: El protocolo ACME (Automated Certificate Management Environment) (RFC 8555) es el mecanismo diseñado específicamente para la emisión y renovación automatizada de certificados. Administrador de CertSecure Admite de forma nativa ACME junto con los protocolos SCEP y EST, integrándose directamente con autoridades de certificación públicas y privadas. Documentos de evidencia: registros de implementación del cliente ACME; registros de éxito de renovación automatizada que muestran la finalización de la validación del dominio.
4. Elimine los intervalos de renovación predefinidos: Audite todos los scripts, tareas programadas y configuraciones de automatización para detectar intervalos de renovación fijos, como «renovar cada 60 días» o «renovar cada 90 días». Reemplácelos con una lógica de renovación dinámica basada en las fechas de vencimiento de los certificados o en las señales ACME ARI (Información de Renovación Automática). Prueba: resultados de la auditoría de configuración; automatización actualizada que muestre la lógica de renovación basada en el vencimiento.
5. Cerrar la brecha entre renovación e implementación: Para cada certificado incluido en el ámbito de aplicación, verifique que el proceso de renovación incluya un paso de implementación y un paso de verificación posterior a la implementación que confirme 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. Prueba documental: registros de verificación de implementación que demuestren que el certificado entregado coincide con el certificado renovado para cada evento de renovación.
6. Abordar la infraestructura heredada y la fijación de certificados: Identifique los sistemas que no pueden participar en la renovación automática: servidores heredados, certificados integrados en el firmware y configuraciones fijas. Para cada uno, defina una ruta de migración antes de la Fase 3. Estos cambios suelen ser los que más tiempo consumen y deben comenzar mucho antes de marzo de 2029. Documentación requerida: inventario de la infraestructura heredada; plan de migración con responsable y fecha límite para cada sistema; registros de eliminación de la fijación de certificados.
7. Establecer una gobernanza centralizada de CLM: Migrar a una plataforma centralizada de gestión del ciclo de vida de los certificados que ofrezca inventario unificado, automatización de renovaciones, orquestación de despliegues 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. Prueba: Despliegue de la plataforma CLM que abarca todos los entornos incluidos en el alcance; informe de cumplimiento que muestra cero certificados a menos de 7 días de su vencimiento.

Lista de verificación de auditoría de preparación de TLS de 47 días

Utilice esta lista de verificación para evaluar la preparación de su organización para cada fase de SC-081v3. Los elementos están organizados según la fase en la que se vuelven críticos:

Área de control	Requisito	Crítico por	Artefacto de evidencia	Estado
Inventario de certificados	Inventario completo de todos los certificados TLS públicos con CA, fecha de vencimiento, ubicación de instalación y equipo responsable.	Ahora (Fase 1 en vigor)	Exportación de inventario CLM o informe de descubrimiento seguro CBOM	Para actuar
Cumplimiento de la fase 1	Todos los nuevos certificados TLS emitidos a partir del 15 de marzo de 2026 tienen una validez máxima de 200 días.	15 de marzo de 2026 (ya en vigor)	Configuración de la política de emisión de la CA; auditoría de certificados que confirma que ningún certificado nuevo supera los 200 días.	Para actuar
Implementación de automatización ACME	Se ha implementado la renovación automatizada basada en ACME para todos los certificados TLS públicos.	Antes de la Fase 2 (marzo de 2027)	Registros de implementación de clientes ACME; registros de éxito de renovación automatizada	Para actuar
Automatización de vehículos eléctricos de corriente continua	Validación automatizada del control de dominio capaz de completar los desafíos HTTP-01 o DNS-01 sin intervención manual.	Antes de la Fase 2 (marzo de 2027); crítico para la Fase 3 (periodo de reutilización de 10 días).	Registros de finalización del desafío ACME; configuración del conector DNS	Para actuar
Umbrales de alerta de renovación	Umbrales de alerta configurados por fase: 60 días para la Fase 1, 30 días para la Fase 2, de 25 a 30 días para la Fase 3.	En curso; actualización en cada fase	Configuración de alertas de la plataforma CLM; evidencia de entrega de alertas	Para actuar
Auditoría de intervalo de renovación codificada	Ningún script de automatización ni tarea programada utiliza intervalos de renovación predefinidos; todos utilizan lógica basada en la caducidad o ACME ARI.	Antes de la Fase 2 (marzo de 2027)	Resultados de la auditoría de configuración; scripts actualizados que muestran la lógica de renovación dinámica.	Para actuar
Cierre de la brecha entre renovación y despliegue	La automatización de la renovación de certificados incluye una verificación posterior a la implementación que confirma que el nuevo certificado se entrega a los clientes.	Antes de la Fase 2 (marzo de 2027)	Registros de verificación de despliegue por evento de renovación	Para actuar
Cumplimiento de la fase 2	Todos los nuevos certificados TLS emitidos a partir del 15 de marzo de 2027 tienen una validez máxima de 100 días.	Marzo 15, 2027	Configuración de la política de emisión de la CA; auditoría de certificados que confirma el cumplimiento.	Para actuar
Migración de infraestructura heredada	Todos los sistemas que utilizan la implementación manual de certificados, certificados codificados o CA integradas en el firmware tienen un plan de migración documentado con fecha objetivo anterior a marzo de 2029.	Antes de la Fase 3 (marzo de 2029)	Inventario de infraestructura heredada; plan de migración con responsable y fecha objetivo.	Para actuar
eliminación de fijación de certificados	Ningún sistema de producción utiliza el anclaje de certificados o claves públicas para certificados de confianza pública.	Antes de la Fase 3 (marzo de 2029)	Auditoría del código de la aplicación; registro de eliminación de anclajes; verificación de confianza estándar basada en CA confirmada	Para actuar
Cumplimiento de la fase 3	Todos los certificados TLS nuevos emitidos a partir del 15 de marzo de 2029 tienen una validez máxima de 47 días; la reutilización de DCV no excede los 10 días.	Marzo 15, 2029	Política de emisión de la CA; registros de automatización de DCV; auditoría de certificados que confirma el cumplimiento	Para actuar
Gobernanza central de CLM	La plataforma CLM centralizada proporciona inventario unificado, automatización de renovaciones, orquestación de despliegues e informes de cumplimiento en todos los entornos.	Antes de la Fase 3 (marzo de 2029)	Informe de cobertura de la plataforma CLM; informe de cumplimiento que muestra cero certificados dentro de los 7 días posteriores a su vencimiento.	Para actuar
Criptoagilidad para sistemas de autenticación	La plataforma CLM admite la emisión de certificados post-cuánticos para futuras migraciones a medida que los programas raíz de los navegadores adoptan los estándares NIST PQC.	Planificación actual; ejecución entre 2028 y 2030.	Hoja de ruta del proveedor de PQC; documentación de soporte de PQC de la plataforma CLM	Para actuar

Cómo la consultoría en cifrado puede ayudar con la transición de 47 días

Encryption Consulting es una empresa de criptografía aplicada con certificación ISO/IEC 27001:2022 y SOC 2. Nuestra cartera de servicios abarca todos los componentes de la transición de 47 días: gestión automatizada del ciclo de vida, descubrimiento criptográfico, infraestructura de clave pública (PKI) totalmente gestionada y preparación para la era post-cuántica.

• Administrador de CertSecure: Administrador de CertSecure es la plataforma de gestión del ciclo de vida de certificados de Encryption Consulting y la respuesta operativa más directa a lo que exige el mandato de 47 días. Automatiza la emisión, renovación e implementación de certificados a gran escala utilizando los protocolos ACME, SCEP y EST. Automatiza la inscripción y renovación en servidores web como Apache, Tomcat e IIS, y balanceadores de carga como F5 BIG-IP. Las renovaciones se activan dinámicamente a partir de los datos de vencimiento del certificado, no de intervalos predefinidos, lo que la hace inherentemente compatible con cada fase de SC-081v3. Está diseñada con la criptoagilidad como base, lo que permite a las organizaciones migrar a certificados post-cuánticos de forma controlada y gradual a medida que los programas raíz de los navegadores adoptan los estándares NIST PQC. Consulte nuestra Guía de migración a la criptografía postcuántica para el marco completo de migración de nueve fases.
• CBOM Seguro (Inventario Criptográfico): CBOM seguro Descubre todos los certificados de su infraestructura, incluidas las cuentas en la nube, los entornos locales y los clústeres de Kubernetes, para que sepa con precisión qué necesita ser gestionado automáticamente antes de cada fecha límite. Este es el paso fundamental en la secuencia de preparación de siete pasos: no se puede automatizar lo que no se encuentra. Consulte también nuestra guía para El punto ciego criptográfico que se esconde en su propia infraestructura. para saber por qué la mayoría de los inventarios carecen de certificados críticos.
• Infraestructura de clave pública como servicio: Para las organizaciones que necesitan manejar la carga significativamente mayor de emisión de certificados con una duración de 47 días sin una revisión completa de la infraestructura PKI interna, PKI como servicio Proporciona una CA totalmente administrada, diseñada para escalar con la nueva frecuencia de renovación. A medida que las tasas de emisión se multipliquen por seis para 2029, las organizaciones que operan con una infraestructura de CA interna con recursos insuficientes se enfrentarán a problemas de rendimiento y disponibilidad. PKI-as-a-Service absorbe esa carga sin necesidad de realizar cambios en la infraestructura interna.
• Conectores DCV y DNS persistentes: Para las organizaciones que necesitan automatizar el paso de validación del dominio, nuestra Conector DCV y DNS persistente Esta guía abarca la automatización del desafío ACME para la ventana de reutilización de DCV de 10 días que llega en la Fase 3.

Conclusión

La decisión del Foro CA/Browser 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. La Fase 1 ya está en vigor. La Fase 2 llegará en marzo de 2027. El plazo de 47 días en marzo de 2029 es una fecha límite fija que la aplicación de la normativa por parte de los navegadores hará innegociable.

Las organizaciones que gestionan cada fase con éxito son aquellas que tratan la administració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 esperan a que cada fase fuerce la situación se enfrentarán a crisis operativas recurrentes con una frecuencia cada vez mayor a medida que los periodos de validez se acorten.

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 en abril de 2025, reduce la validez máxima de los certificados TLS de confianza pública de 398 días a 47 días para el 15 de marzo de 2029, 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. Todos los principales proveedores de navegadores, incluidos Apple, Google, Microsoft y Mozilla, votaron a favor. La primera fase ya está en vigor.

¿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 a partir de cada fecha límite. No hay período de gracia: cualquier certificado emitido a partir del 15 de marzo de 2026 debe cumplir con el plazo máximo de 200 días para esa fase.

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

La reutilización de DCV (Verificación de Propiedad de Dominio) determina cuánto tiempo una Autoridad de Certificación puede confiar en una verificación previa de propiedad de dominio antes de requerir una nueva prueba. SC-081v3 reduce este plazo a 10 días para marzo de 2029, lo que significa que la propiedad del dominio deberá verificarse nuevamente en casi cada renovación de certificado. Esto convierte la validación automatizada de dominios basada en ACME en un requisito operativo indispensable, en lugar de una simple conveniencia.

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

No. SC-081v3 solo rige los certificados TLS de confianza pública emitidos por las CA en los programas raíz del navegador. La infraestructura de clave pública (PKI) privada o interna no está sujeta a los requisitos básicos del Foro de CA/Navegadores y puede seguir utilizando períodos de validez más largos. Muchas organizaciones optan por alinear su política interna con el calendario público para lograr coherencia y simplificar la automatización de la gestión del ciclo de vida del código (CLM).

¿Qué es el anclaje de certificados y por qué es incompatible con los certificados de 47 días?

El anclaje de certificados incorpora un certificado o clave pública específica en la aplicación o dispositivo del cliente. Con ciclos de renovación de 47 días, el cliente debe actualizarse cada seis semanas, lo cual resulta inviable desde el punto de vista operativo. La única solución viable es migrar del anclaje de certificados a la verificación de confianza estándar basada en autoridades de certificación antes de marzo de 2029.

¿Qué es la brecha entre renovación e implementación y cómo la cierran las organizaciones?

La brecha entre la renovación y la implementación se produce cuando se obtiene un nuevo certificado pero no se implementa, lo que provoca que el certificado antiguo siga gestionando el tráfico hasta su vencimiento. Con una validez de 47 días, esto constituye un fallo crítico. Para solucionarlo, es necesario que la automatización de la renovación de certificados incluya una verificación posterior a la implementación que confirme que el nuevo certificado se está utilizando correctamente antes de marcar la renovación como completada.

¿Cómo deben prepararse las organizaciones para obtener certificados TLS con una validez de 47 días?

La secuencia de siete pasos es: (1) crear un inventario completo de certificados; (2) establecer umbrales de alerta de renovación adecuados para cada fase; (3) estandarizar la automatización ACME; (4) eliminar los intervalos de renovación predefinidos; (5) cerrar la brecha entre la renovación y la implementación; (6) abordar la infraestructura heredada y la fijación de certificados; y (7) establecer una gobernanza centralizada de CLM. Comience con el inventario, ya que todos los demás pasos dependen de saber qué certificados posee.