Certificados de 90 días de Google: Transición rápida y eficaz a los certificados TLS/SSL de 90 días

Respuesta rápida: Los certificados TLS/SSL públicos no tienen un límite de validez de 90 días. Según la propuesta SC-081v3 del Foro de Autoridades de Certificación/Navegadores, la validez máxima de los certificados se reduce a 200 días en marzo de 2026, 100 días en marzo de 2027 y 47 días en marzo de 2029. Las organizaciones que aún emiten certificados anuales o de 398 días deben implementar un sistema automatizado de gestión del ciclo de vida de los certificados antes de la primera fecha límite.

Cuando Google propuso por primera vez un límite de 90 días para la validez de los certificados TLS/SSL públicos , se informó ampliamente que se convertiría en el estándar de la industria. Sin embargo, esa propuesta nunca se convirtió en una norma vinculante. En cambio, el Foro CA/Browser aprobó la propuesta SC-081v3, que establece un calendario de reducción gradual a lo largo de varios años que culmina en 47 días para 2029, en lugar de un salto directo a 90. Cualquier plan de gestión de certificados que aún se base en "90 días" está planificando con una fecha límite que ya no existe.

Puntos Clave

• El plazo de 90 días está desactualizado: la propuesta SC-081v3 del Foro CA/Browser (anunciada por Sectigo el 14 de abril de 2025) reemplazó cualquier propuesta única de 90 días con un cronograma por fases.

• Tres plazos, no uno: la validez máxima de los certificados TLS/SSL públicos se reduce a 200 días en marzo de 2026, a 100 días en marzo de 2027 y a 47 días en marzo de 2029.

• La renovación manual ya presenta fallos en estos intervalos: la encuesta Trust Pulse de DigiCert del 2 de julio de 2025 reveló que el 45 % de las organizaciones informaron de tiempos de inactividad relacionados con los certificados, y el 37.5 % atribuyeron las interrupciones directamente a certificados caducados.

• El seguimiento mediante hojas de cálculo no sobrevivirá a ciclos de 47 días: con aproximadamente 7 u 8 renovaciones por certificado al año, el seguimiento manual multiplica la carga de trabajo que ya provoca interrupciones en el servicio actualmente.

• La automatización es la solución práctica: una plataforma de gestión del ciclo de vida de los certificados (CLM, por sus siglas en inglés) como CertSecure Manager es la forma en que la mayoría de las empresas cumplen con cada plazo sin prisas de última hora.

Desde la propuesta de 90 días de Google hasta el calendario vinculante del Foro CA/B

Google planteó la idea de un período máximo de validez de 90 días para los certificados TLS públicos como parte de su estrategia a largo plazo para reducir la duración de los certificados y aumentar la automatización en todo el ecosistema PKI web. La propuesta generó un intenso debate: si bien una menor duración reduce el impacto de una clave comprometida, también incrementa la carga operativa para todas las organizaciones que aún emiten y renuevan certificados manualmente.

Ese debate se resolvió mediante el proceso de votación del Foro CA/Navegadores, y no por la propuesta de un solo proveedor de navegadores. La propuesta SC-081v3 fue aprobada y anunciada por Sectigo el 14 de abril de 2025, estableciendo una reducción gradual en lugar de un cambio abrupto a 90 o 47 días. El resultado es un calendario que todas las autoridades de certificación de confianza pública y todos los navegadores que dependen de él deben seguir: 200 días a partir de marzo de 2026, 100 días a partir de marzo de 2027 y 47 días a partir de marzo de 2029.

El contenido y la información que aún se centran en los "certificados de 90 días de Google" describen una propuesta que la historia ha superado. El documento clave es la votación del Foro CA/B, y el plazo que las empresas deberían considerar es de 47 días, implementados gradualmente a lo largo de aproximadamente tres años.

Fuentes oficiales de las políticas y fechas de entrada en vigor.

Periodo de validez del certificado TLS: 200 → 100 → 47 días

Cada paso que se describe a continuación es vinculante para todas las autoridades de certificación de confianza pública y lo aplican todos los navegadores principales que dependen de ellas. Utilice esta tabla para alinear su ciclo de renovación, la implementación de la automatización y la evidencia de auditoría con los plazos reales.

Nota de implementación: valide las fechas de vigencia de esta tabla con el texto actual de la votación del Foro CA/B antes de cada ciclo de renovación, ya que los períodos de validación y reutilización están sujetos a votaciones posteriores y deben volver a comprobarse, no asumirse como estáticos.

Por qué los ciclos de vida de los certificados más cortos son importantes para la gestión del ciclo de vida de los certificados empresariales.

La reducción de la validez de los certificados es una respuesta directa a un problema que las empresas ya tienen, no a uno nuevo. La encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las organizaciones reportaron interrupciones del servicio relacionadas con certificados, y el 37.5 % atribuyó una interrupción directamente a un certificado caducado. Estas cifras describen la situación actual con certificados de 398 días. El cambio a certificados de 47 días no soluciona por sí solo esta deficiencia; simplemente elimina la opción de gestionar los certificados manualmente sin problemas.

Ventajas de los certificados de menor validez

• Seguridad mejorada

  Si una clave privada se ve comprometida, un período de validez más corto reduce el tiempo que un atacante puede utilizarla. Un vencimiento más rápido y la rotación obligatoria de claves limitan los daños incluso cuando una vulneración pasa desapercibida durante un tiempo.

• Postura de cumplimiento más firme

  La renovación frecuente y obligatoria mantiene actualizados los parámetros criptográficos de acuerdo con los requisitos básicos en constante evolución del Foro CA/B, lo que reduce la posibilidad de que una auditoría encuentre un certificado emitido bajo una política obsoleta.

• Adaptabilidad más rápida

  Las organizaciones no están sujetas a compromisos de certificación a largo plazo, por lo que un nuevo requisito de algoritmo o la revocación de una CA no deja los certificados sin uso durante un año o más.

• Ventana de uso indebido inferior

  Un certificado robado o emitido incorrectamente tiene menos tiempo para ser utilizado antes de que caduque automáticamente, además de cualquier acción de revocación.

• Gestión de claves más estricta

  Las renovaciones más frecuentes obligan a una rotación de llaves más frecuente, que es uno de los controles más efectivos y menos llamativos en la gestión de llaves.

• Gestión del ciclo de vida del cliente a largo plazo más sencilla

  Una vez implementada la automatización, los certificados de corta duración son en realidad más fáciles de gestionar que los de larga duración: la emisión, la renovación y la revocación se realizan con la misma cadencia predecible y automatizada.

Riesgos de la gestión manual de certificados en ciclos de vida más cortos

Un certificado caducado provoca hoy los mismos fallos que siempre; los ciclos más cortos simplemente implican que ocurre con mayor frecuencia, a menos que la renovación sea automática.

• Incumplimiento de datos

  Cuando un certificado SSL caduca, la conexión segura que protegía se interrumpe con él, y los atacantes pueden interceptar todo lo que se haya cifrado previamente durante la transmisión.

• Interrupción del servicio

  Los certificados caducados dejan los sitios web y servicios fuera de línea. Las advertencias del navegador ahuyentan a los usuarios incluso antes de que vean el contenido, lo que repercute directamente en los ingresos y en las solicitudes de soporte.

• Sanciones de motores de búsqueda

  Los certificados SSL caducados pueden perjudicar la visibilidad en los motores de búsqueda, ya que los principales buscadores dan menor prioridad a los sitios que no tienen un certificado HTTPS válido.

• Daño a la reputación

  Una interrupción del servicio causada por algo tan evitable como un certificado caducado erosiona la confianza del cliente de una manera que lleva mucho más tiempo recuperar que lo que habría llevado la propia renovación.

Automatización de certificados: Reducción del riesgo de interrupciones

La automatización aborda directamente la cifra del 37.5 % de interrupciones por certificados caducados, según la encuesta de DigiCert. Elimina los dos factores que causan la mayoría de las interrupciones por certificados: que un empleado olvide la fecha y que el proceso de renovación sea demasiado lento para finalizar antes de la fecha de vencimiento.

1. Ahorro de tiempo y costes

   La automatización de certificados elimina las transferencias manuales entre sistemas, lo que permite a los equipos de TI y seguridad trabajar en tareas de mayor valor en lugar de estar pendientes de las fechas de renovación.

2. Menos errores humanos

   Un simple error de configuración manual o una renovación no realizada pueden provocar una interrupción del servicio. La automatización aplica el mismo proceso validado en cada ocasión, independientemente del número de certificados.

3. No se admiten renovaciones de última hora.

   Con una validez de 47 días, la estrategia de «renovarlo la semana que viene» no es viable. La renovación automática se activa mucho antes de la fecha de vencimiento, en cada ciclo, sin depender de que alguien se acuerde.

4. Postura de seguridad más fuerte

   Los certificados que se renuevan automáticamente y según lo programado solucionan el problema exacto (certificados caducados o vencidos) que tanto la encuesta de DigiCert como la lista de riesgos de este artículo señalan como la principal causa de incidentes relacionados con certificados.

Impacto por función y fecha: ¿Quién debe actuar y cuándo?

El calendario de 47 días afecta a más personas que solo al equipo que hace clic en "renovar". Utilice esta matriz para definir la responsabilidad antes de la fecha límite de marzo de 2026, no después.

Equipos de seguridad y PKI

Los equipos de seguridad y de infraestructura de clave pública (PKI) son responsables de las decisiones políticas: periodos de validez, tamaños de clave, acuerdos de nivel de servicio (SLA) de revocación y autoridades de certificación aprobadas. Según el cronograma por fases, estos equipos deben considerar la detección de certificados como el primer resultado, no como algo secundario, ya que no se puede automatizar la renovación de certificados cuya existencia se desconoce.

Equipos de plataforma y DevOps

Los equipos de DevOps consumen la mayor parte de los certificados en la mayoría de las organizaciones, especialmente en los pipelines de CI/CD . La emisión mediante API a través de protocolos como ACME, EST o SCEP permite que los certificados se aprovisionen automáticamente durante el despliegue, en lugar de hacerlo mediante una cola de tickets que no puede gestionar las renovaciones cada 47 días.

Equipos de cumplimiento

Los equipos de cumplimiento necesitan un inventario de certificados y evidencia de renovación que se mantenga actualizado entre auditorías, no una hoja de cálculo creada justo antes de una. Una plataforma CLM que genera informes bajo demanda convierte un proceso de preparación de auditorías de varias semanas en una consulta sobre datos en tiempo real.

Lista de verificación de preparación y hoja de ruta de migración

Lista de verificación de preparación rápida

• Realice un inventario completo de certificados, incluidos los certificados autofirmados y los certificados espejo fuera de la CA administrada.

• Confirme que cada certificado tenga un propietario identificado, y no solo un contacto técnico que haya quedado del proceso de aprovisionamiento.

• Seleccionar y poner a prueba una plataforma CLM capaz de emitir certificados ACME, EST y SCEP antes de marzo de 2026.

• Configure la automatización de renovación para que se active con suficiente antelación como para sobrevivir a un primer intento fallido.

• Elabore un mapa de los períodos de validez actuales y los marcos de cumplimiento para que la evidencia de auditoría esté lista antes del paso de los 100 días.

• Confirme que las canalizaciones de CI/CD y DevOps solicitan certificados a través de la API, no mediante envío manual.

Hoja de ruta de migración

Un despliegue de CLM que cumple con el plazo de 47 días sin contratiempos generalmente sigue la misma secuencia:

1. Inventario

   Cree un inventario completo de todos los certificados del entorno, incluidos aquellos que actualmente no pertenecen a nadie. Este es el paso que suelen omitir las migraciones retrasadas.

2. Descubrimiento de certificados

   Realice análisis de detección activa y pasiva para descubrir certificados ocultos y autofirmados que nunca pasaron por un proceso de emisión formal; estos son frecuentemente los que causan interrupciones inesperadas del servicio.

3. Monitoreo e Informes

   Implementar un sistema de monitoreo continuo para que las anomalías en la emisión o renovación se detecten de inmediato, y no se descubran cuando falle un servicio.

4. Automatización

   Automatice la renovación de principio a fin. Con ciclos de 47 días, el seguimiento manual con los propietarios de certificados durante días o semanas por certificado ya no es viable operativamente.

5. Flujos de trabajo y políticas

   Centralizar la aplicación de las políticas para que cada nueva solicitud de certificado se valide con respecto a los períodos de validez aprobados, los tamaños de clave y las autoridades de certificación emisoras antes de su emisión.

6. Integración de DevOps

   Conecte la plataforma CLM a las herramientas de CI/CD mediante API para que los certificados se aprovisionen automáticamente como parte del despliegue, adaptándose al ritmo que exigen los periodos de validez más cortos.

CertSecure Manager: Automatización de la gestión del ciclo de vida de los certificados para la era de los 47 días.

CertSecure Manager abarca la gestión integral del ciclo de vida de los certificados (descubrimiento, inventario, emisión, implementación, renovación, revocación e informes) mediante la automatización, en lugar de la gestión manual. Las alertas integradas avisan con suficiente antelación sobre las próximas caducidads para poder actuar, y los informes están diseñados para cumplir con los requisitos de NIST , HIPAA , GDPR y CA/B Forum sin necesidad de recopilar pruebas manualmente antes de cada auditoría.

Las organizaciones que utilizan CertSecure Manager están preparadas para avanzar por cada etapa del cronograma por fases (200 días, luego 100 y luego 47) mediante el mismo proceso automatizado, en lugar de rediseñar la gestión de certificados cada vez que cambien los requisitos del Foro CA/B.

Conectando la automatización de certificados con la criptoagilidad y la preparación para PQC

La automatización de certificados no es solo una respuesta a un plazo de validez más corto; es la misma capacidad operativa de la que depende la migración post-cuántica. Una organización que puede renovar, reemitir y rotar certificados automáticamente ya cuenta con la base para la agilidad criptográfica: la capacidad de cambiar las primitivas criptográficas con rapidez y confianza a medida que cambian los estándares.

Esta conexión es fundamental para los equipos que ya realizan un seguimiento de los plazos de la criptografía postcuántica . Los programas de preparación para la criptografía postcuántica (PQC) y la plataforma CBOM Secure de Encryption Consulting se basan en el mismo trabajo de descubrimiento e inventario descrito anteriormente: un inventario de certificados completo y actualizado es también el punto de partida para una lista de materiales criptográficos (CBOM). Los equipos que ya han automatizado la gestión del ciclo de vida de los certificados no parten de cero cuando comienza la planificación de la migración a PQC.

Para obtener una visión más detallada de cómo convertir ese inventario en un sistema de registro práctico y mantenido continuamente, consulte cómo una lista de materiales criptográfica convierte el inventario en información útil.

Qué hacer a continuación

• Equipos de PKI: finalicen el descubrimiento y el inventario de certificados, y confirmen que cada certificado tenga un propietario identificado antes de marzo de 2026.

• Equipos de seguridad: definan ahora la validez, el tamaño de la clave y la política de revocación para que no se establezcan de forma improvisada bajo la presión de los plazos de entrega más adelante.

• Equipos de plataforma: trasladen las solicitudes de certificados en las canalizaciones de CI/CD a la emisión mediante API antes de que se cumpla el plazo de 100 días.

• Equipos de cumplimiento: confirmen que los informes de CLM se ajustan a sus marcos de auditoría existentes mucho antes de que el plazo de 47 días haga que la recopilación manual de pruebas resulte impracticable.

Conclusión

La industria de los certificados no está adoptando la validez de 90 días porque Google lo propusiera. Está pasando a 200, luego a 100 y finalmente a 47 días porque el Foro de Autoridades de Certificación/Navegadores aprobó un calendario vinculante. Esta distinción es importante porque el cronograma, los plazos y las obligaciones de cumplimiento son diferentes de lo que aún describe el contenido de los "certificados de 90 días".

Las organizaciones que consideren esto como un cambio puntual en la frecuencia de renovación tendrán dificultades en cada etapa. Las organizaciones que lo vean como el detonante para automatizar finalmente la gestión del ciclo de vida de los certificados y desarrollar la criptoagilidad que permite la automatización, cumplirán con los plazos de marzo de 2026, marzo de 2027 y marzo de 2029 en la misma plataforma, sin tener que rediseñar su estrategia tres veces.

Preguntas frecuentes

¿Cuál es la principal conclusión del informe de Google "Certificados de 90 días: Transición rápida y eficaz a certificados TLS/SSL de 90 días"?

La propuesta original de Google de 90 días fue reemplazada por la votación SC-081v3 del Foro CA/Browser, que establece un calendario por fases: la validez máxima de los certificados TLS/SSL públicos se reduce a 200 días en marzo de 2026, 100 días en marzo de 2027 y 47 días en marzo de 2029. Los planes deben ajustarse a este calendario, no a una cifra fija de 90 días.

¿Por qué es importante esto para la gestión del ciclo de vida de los certificados empresariales?

Los periodos de validez más cortos multiplican la frecuencia con la que deben renovarse los certificados públicos. Las empresas que gestionan los certificados manualmente verán cómo la frecuencia de renovación se duplica aproximadamente a los 200 días y vuelve a aumentar en cada renovación posterior, convirtiendo una tarea ocasional en una carga operativa constante sin automatización.

¿Qué equipos son responsables de poner en práctica estas directrices?

Los equipos de PKI y certificados son responsables del inventario, el descubrimiento y las políticas. Los equipos de seguridad establecen la validez, el tamaño de las claves y las reglas de revocación. Los equipos de plataforma y DevOps integran la emisión en los flujos de trabajo de CI/CD. Los equipos de cumplimiento confirman que la renovación y la generación de informes de inventario cumplen con los marcos de auditoría existentes durante toda la transición.

¿Qué riesgos aumentan si este tema se aborda manualmente?

La encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las organizaciones reportaron tiempos de inactividad relacionados con certificados, y el 37.5 % atribuyó las interrupciones directamente a certificados caducados, debido a los períodos de validez más prolongados actuales. El seguimiento manual en ciclos de 47 días aumenta la frecuencia de los mismos modos de falla: interrupciones, exposición de datos, penalizaciones en las búsquedas y daños a la reputación.

¿Cómo reduce la automatización el riesgo de interrupción de los certificados?

La renovación automatizada elimina las dos principales causas de interrupción de certificados: que una persona olvide la fecha de renovación y que un proceso manual sea demasiado lento para completarse antes de la fecha de vencimiento. Una plataforma CLM activa la renovación según un calendario fijo con tiempo suficiente para recuperarse de un primer intento fallido, independientemente del número de certificados.

¿Qué métricas deberían monitorizar los equipos tras la implementación?

Realizar un seguimiento de la exhaustividad del inventario de certificados (incluidos los certificados autofirmados y los certificados espejo), el porcentaje de certificados en renovación automática, la tasa de fallos en la renovación, el tiempo medio de reemisión tras un fallo y el número de certificados que aún requieren intervención manual en cada fase del calendario.

¿Cómo se relaciona esto con el plazo de 47 días para la obtención del certificado TLS?

El requisito de 47 días, vigente desde marzo de 2029, es el paso final del mismo cronograma del Foro CA/B que se analiza en este artículo. El trabajo de descubrimiento, inventario y automatización necesario para los pasos de 200 y 100 días constituye la misma base que requiere la preparación para la certificación en 47 días; no es necesario desarrollar un proyecto aparte posteriormente.

¿Cómo debería gestionarse esto en entornos PKI híbridos o multinube?

Los entornos multinube e híbridos requieren un único inventario de certificados y una plataforma CLM que abarque todos los proveedores de nube y las CA locales, en lugar de un seguimiento independiente para cada entorno. El descubrimiento de certificados debe cubrir todos los entornos, ya que es más probable que aparezcan certificados fantasma cuando la infraestructura está distribuida entre varios proveedores.