Prepárate para el acortamiento de la validez de los certificados

La validez máxima del certificado TLS público se reducirá gradualmente en los próximos años:

• Hasta el 15 de marzo de 2026, la validez máxima del certificado TLS es de 398 días.
• Desde el 15 de marzo de 2026, la validez máxima del certificado TLS será de 200 días.
• Desde el 15 de marzo de 2027, la validez máxima del certificado TLS será de 100 días.
• Desde el 15 de marzo de 2029, la validez máxima del certificado TLS será de 47 días.

También se verá reducida la duración máxima del reutilización de la información de verificación del dominio e IP:

• Hasta el 15 de marzo de 2026, la duración máxima del reutilización de datos de verificación es de 398 días.
• Desde el 15 de marzo de 2026, la duración máxima del reutilización de datos de verificación será de 200 días.
• Desde el 15 de marzo de 2027, la duración máxima del reutilización de datos de verificación será de 100 días.
• Desde el 15 de marzo de 2029, la duración máxima del reutilización de datos de verificación será de 10 días.

La validez máxima del certificado determina el número máximo de días por los cuales el certificado se considera válido. Para que una autoridad de certificación (CA) pueda emitir un certificado, debe verificar que el solicitante realmente controla el dominio o dirección IP mencionada en el certificado.

Si hoy tienes un certificado y lo renuevas una vez al año (según las reglas actuales), se verifica nuevamente el control del dominio en cada renovación.

Pero, ¿qué pasa si necesitas reemplazar un certificado antes de la renovación, por ejemplo, si se compromete la clave privada? En ese caso, la CA puede reutilizar la verificación realizada en la última renovación, evitando así la necesidad de una nueva validación. Esto es posible porque la duración máxima del reutilización de verificación del dominio aún no ha expirado.

Los requisitos básicos (llamados Requisitos Básicos, es decir, las reglas del CA/B Forum para la emisión de certificados) siempre han definido ambos límites de tiempo, pero generalmente están configurados en el mismo valor.

El cambio en la última fase de las nuevas reglas - en la que la validez máxima del certificado cae a 47 días, mientras que la verificación del dominio solo se puede reutilizar durante 10 días - tiene como objetivo que las verificaciones se realicen con más frecuencia. El CA/B Forum considera que la información sobre el control del dominio se vuelve obsoleta muy rápidamente.

El mismo cronograma de comprobación del dominio también se aplicará a los certificados OV y EV. Gradualmente será necesario llevar a cabo la verificación del dominio en los mismos intervalos que para los certificados DV, es decir, cada 200 / 100 / 10 días.

Los demás datos contenidos en los certificados OV y EV (como el nombre y dirección de la organización) solo requerirán renovación cada 398 días. Aunque la verificación del dominio puede y debe ser automatizada, esta información adicional no se puede automatizar por completo.

No, no exactamente. La restricción se aplica a los certificados que las autoridades de certificación (CA) pueden emitir, no a los certificados que los navegadores pueden aceptar.

El navegador solo verifica si la fecha actual cae dentro del período de validez del certificado.

Una vez que entren en vigor los cambios en las reglas, las autoridades de certificación ya no podrán emitir certificados TLS con una validez superior a 200 / 100 / 47 días.

Sin embargo, un certificado con una validez de 398 días emitido antes de la entrada en vigor del cambio permanecerá válido hasta su expiración. Lo mismo se aplica a los certificados con una validez de 200 días en el momento del cambio al límite de 100 días y para los certificados con una validez de 100 días en la transición al límite de 47 días.

No, los requisitos básicos son obligatorios solo para las autoridades de certificación públicas.

La PKI interna funciona dentro de su red o nubes. Incluye autoridades de certificación, pero las políticas que aplican las autoridades de certificación internas - incluida la duración de los certificados - las establece usted mismo. Puede ser conveniente elegir una corta duración de validez también para la PKI interna, pero no es obligatorio. Puede operar todo el software para PKI interna por su cuenta, pero es una tarea compleja y propensa a errores. DigiCert ofrece varias soluciones de PKI interna para entornos empresariales, en la nube y de fabricación.

No. Durante la duración del pedido (en años), no hay costos adicionales por renovar o reemplazar certificados. Durante la validez del pedido, puede hacer un número ilimitado de reissues.

No, se refieren solo a los certificados finales (leaf) emitidos por la autoridad de certificación intermedia. No existen reglas de CA/B Forum u otros organismos de estandarización que limiten la validez de los certificados root y intermediate, pero generalmente se consideran buenas prácticas y los proveedores de software que utilizan certificados establecen sus propias reglas para sus programas de raíces confiables, que pueden diferir significativamente.

Mozilla Root Store Policy (sección 7.4) indica que Mozilla dejará de confiar en los certificados raíz 15 años después de la generación de la clave.

Las reglas de duración en Chrome Root Program Policy, versión 1.6 (15 de febrero de 2025), son más complejas. No hay un límite de validez estricto, pero "cualquier certificado raíz CA con material de clave correspondiente generado hace más de 15 años será eliminado gradualmente de Chrome Root Store". Los raíces que contengan claves creadas antes del 16 de abril de 2014 serán eliminados según un calendario anual establecido en la Política del Programa de Raíces.

Microsoft Trusted Root Program establece que "las autoridades de certificación raíz (Root CA) recién emitidas deben tener una validez mínima de ocho años y máxima de 25 años desde la fecha de presentación". La diferencia entre las políticas de Microsoft y otras se deriva de la diversidad de aplicaciones que Microsoft respalda en su PKI, que es significativamente más amplia que otros navegadores.

Una práctica reconocida como de sentido común es que el certificado raíz CA no debe expirar antes que cualquier certificado CA intermedio asociado a él.

Una mala gestión del ciclo de vida de los certificados raíz e intermedios CA puede tener consecuencias graves, como se demostró recientemente cuando un certificado CA intermedio aparentemente olvidado por Google expiró, dejando a muchos dispositivos Google Chromecast sin servicio.

Para casos comunes y simples, como servidores web y certificados TLS públicos, la automatización es gratuita para los clientes de CertCentral gracias a los ampliamente respaldados estándares Automated Certificate Management Environment (ACME) y ACME Renewal Information (ARI).

Por supuesto, no todos los certificados son públicos TLS y no todas las tecnologías admiten ACME. Para estos casos, DigiCert Trust Lifecycle Manager ofrece opciones avanzadas de automatización e integración.

La automatización con ACME no significa simplemente marcar una casilla. Se requieren ciertos cambios en el dispositivo o en la aplicación (generalmente en el servidor web) que necesita el certificado. Para la mayoría de los administradores, este proceso es sencillo y está bien documentado.

ACME es el Entorno de Gestión Automatizada de Certificados.
ARI es la Información de Renovación ACME.

ACME es un estándar respaldado por todas las grandes autoridades de certificación, mediante el cual el software cliente para certificados ( generalmenteservidor web) solicita un certificado a la autoridad de certificación e instalación en el cliente. (En este escenario, el servidor web es el cliente.)

El software del cliente también debe admitir ACME. El soporte está ampliamente extendido, pero no es universal. El programa cliente ACME generalmente se ejecuta en el sistema cliente de acuerdo con el horario de Linux cron o el Programador de tareas en Windows, pero existen otras soluciones que integran la programación en productos más grandes.

ARI es un estándar relacionado, por el cual el servidor puede recomendar un cronograma para que el cliente sepa que debe renovar el certificado antes de que expire. Si está configurado correctamente, ARI puede ordenar al cliente que renueve incluso si el certificado ha sido revocado, preveniendo un tiempo de inactividad.

Según las nuevas reglas para certificados TLS, a partir del 15 de marzo de 2026, solo será posible reutilizar la verificación de información de identidad del sujeto (Información de Identidad del Sujeto, SII) durante 398 días, en lugar de los 825 días actuales.

Esto significa que el principal impacto en sus certificados OV y EV será la necesidad de verificar nuevamente la información de identidad del sujeto ( SII) — la información del certificado que identifica su organización — anualmente, en lugar de una vez cada dos años.

Según los Requisitos Básicos de TLS, esto requiere una llamada telefónica anual con un representante de DigiCert, por lo que este proceso no se puede automatizar completamente.

A tener en cuenta: los certificados OV y EV también protegen nombres de dominio, por lo que su duración deberá actualizarse conforme al mismo cronograma de los certificados DV: 200 días en 2026, 100 días en 2027 y 47 días en 2029. Entonces, la necesidad de automatizar la gestión de estos certificados es igual de crítica que para los certificados DV.

El número de 47 días puede parecer arbitrario, pero se basa en una serie simple:

• 200 días = 6 meses máximos (184 días) + 1/2 de un mes de 30 días (15 días) + 1 día de margen
• 100 días = 3 meses máximos (92 días) + cerca de 1/4 de un mes de 30 días (7 días) + 1 día de margen
• 47 días = 1 mes máximo (31 días) + 1/2 de un mes de 30 días (15 días) + 1 día de margen

Este modelo de fijación de duraciones "inusuales" con un margen adicional ha sido durante mucho tiempo un estándar del CA/B Forum. El límite de 398 días se eligió como 1 año máximo (366 días) + 1 mes máximo (31 días) + 1 día de margen.

Sí, según las reglas es posible obtener otros 398 días si se renuevan los certificados antes del 15 de marzo de 2026. Sin embargo, es una extensión única y expirará — la duración máxima será de 100 días en la próxima renovación. Recuerde implementar la automatización a tiempo para estar preparado.

Si necesita volver a crear el certificado con una clave nueva (rekey) el 15 de marzo de 2026 o posteriormente, DigiCert - como cualquier otra autoridad de certificación pública - debe seguir las reglas vigentes en ese momento, lo que en el mejor de los casos le proporcionará un certificado con una validez de unos 200 días.

El mejor momento para automatizar la gestión de certificados es lo antes posible, asegurando que este proceso esté preparado sin riesgo de expiración de certificados o problemas similares.

El mercado de certificados TLS públicos está en gran parte orientado a los certificados utilizados en navegadores, generalmente instalados en algún servidor web, pero existen otros casos de uso. Un buen ejemplo son las puertas de enlace VPN y algunos dispositivos de Internet de las Cosas (IoT).

Estos dispositivos también deberán acelerar el ciclo de gestión del ciclo de vida de los certificados (CLM). Muchos de ellos admiten directamente ACME u otro protocolo de automatización, por lo que ajustar los parámetros puede no ser un problema sustancial. En otros casos, puede existir soporte para un mecanismo de automatización alternativo, o puede que no haya soporte en absoluto - en esos casos, el usuario debe asegurar la automatización programáticamente.

La adaptación al nuevo cronograma será un problema recurrente en estos dispositivos. Es importante crear un inventario completo de activos afectados, algo en lo que DigiCert puede ayudar.