Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
Los días de los certificados TLS de varios años han terminado. La industria se está moviendo rápidamente hacia períodos de validez más cortos, con certificados de 47 días en el horizonte. Este cambio transformará fundamentalmente la forma en que las organizaciones gestionan sus patrimonios de certificados.
Durante años, los certificados TLS podían ser válidos durante tres, cuatro o incluso cinco años. Los administradores solicitaban un certificado, lo instalaban y, en gran medida, lo olvidaban hasta que llegaba el próximo ciclo de renovación. Esa era está terminando.
La trayectoria es inequívoca: los períodos de validez de los certificados se han ido reduciendo de forma constante, y el ritmo se está acelerando. A partir de 2024, la validez máxima para los de confianza pública certificados TLS son 398 días (aproximadamente 13 meses). Para 2029, esa ventana se reducirá a solo 47 días. Esto significa que las organizaciones que antes renovaban un certificado una vez al año pronto tendrán que renovarlo aproximadamente ocho veces al año, por certificado.
El cambio no es arbitrario. Refleja un consenso creciente entre los proveedores de navegadores, investigadores de seguridad y organismos de estándares de que los períodos de vida más cortos reducen drásticamente el riesgo. Pero para los equipos de TI que aún dependen de procesos manuales o hojas de cálculo, las implicaciones operativas son enormes.
La historia de la validez de los certificados TLS es una historia de compresión constante. Cada reducción fue recibida con resistencia de la industria, seguida de adaptación, seguida de llamadas a períodos aún más cortos.
En los primeros días del TLS comercial, los certificados podían comprarse con períodos de validez de tres a cinco años. La renovación era poco frecuente, y la gestión de certificados era en gran parte un proceso manual y ad hoc manejado por un pequeño número de administradores.
El foro CA/Browser votó limitar la validez de los certificados TLS a 825 días (aproximadamente dos años). Esta fue la primera reducción importante y señaló la dirección de la industria's. Las organizaciones con grandes patrimonios de certificados comenzaron a sentir la presión operativa.
Apple anunció unilateralmente que Safari rechazaría los certificados con períodos de validez superiores a 398 días. Google y Mozilla siguieron su ejemplo. El foro CA/Browser había debatido este cambio pero no pudo alcanzar un consenso; los proveedores de navegadores forzaron el asunto. Esto se convirtió en el estándar que se mantiene hoy.
Google defendió públicamente un período máximo de validez de 90 días, citando el éxito de Let's Encrypt (que emite certificados de 90 días por defecto). La propuesta obtuvo amplio apoyo entre los proveedores de navegadores y los investigadores de seguridad, preparando el escenario para la próxima reducción formal.
Apple's ballot SC-081 fue adoptado por el foro CA/Browser, estableciendo una reducción por fases: 200 días para marzo de 2026, 100 días para marzo de 2027, y 47 días para marzo de 2029. La reutilización de la Validación de Control de Dominio (DCV) también se limitará a solo 10 días, lo que significa que todo el proceso de emisión debe estar automatizado de extremo a extremo.
El impulso hacia períodos de validez más cortos está impulsado por beneficios concretos de seguridad y operacionales. Comprender estas motivaciones es esencial para comunicar la urgencia a las partes interesadas dentro de su organización.
Si una clave privada se ve comprometida, el daño se limita a la validez restante del certificado. Un certificado de 47 días significa que un atacante puede explotar una clave robada durante semanas, no meses o años. Las vidas útiles más cortas hacen que la revocación sea menos crítica porque los certificados expiran naturalmente rápidamente.
Cada ciclo de renovación típicamente genera un par de claves nuevo. Renovaciones más frecuentes significan que las claves se rotan con mayor frecuencia, reduciendo la ventana en la que una única clave comprometida sigue siendo útil. Esto se alinea con los principios de confianza cero de verificación continua.
Cuando los datos de validación de dominio pueden reutilizarse durante un año, los cambios en la propiedad del dominio pueden pasar desapercibidos. Periodos de reutilización de DCV más cortos (hasta 10 días) garantizan que cada emisión refleje el estado actual del control del dominio, evitando que los certificados se emitan a partes que ya no poseen el dominio.
Cuando se descubre que un algoritmo criptográfico es débil, los certificados de corta duración hacen que el ecosistema cambie más rápido. En lugar de esperar años a que los certificados antiguos expiren, toda la flota puede migrarse en semanas. Esto es especialmente relevante ya que la industria se prepara para criptografía post-cuántica.
El Foro CA/Navegador es el organismo de la industria que establece las normas que rigen los certificados de confianza pública. Sus miembros incluyen Autoridades de Certificación (como DigiCert, Sectigo y Let's Encrypt) y proveedores de navegadores (Apple, Google, Mozilla, Microsoft). Las decisiones requieren consenso de ambas partes.
En 2024, Apple presentó Ballot SC-081, proponiendo una reducción gradual de la validez máxima de los certificados TLS. A diferencia de intentos anteriores que se estancaron en el comité, esta votación obtuvo amplio apoyo. Las disposiciones clave son claras: la validez máxima del certificado 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. Igualmente importante, el período máximo de reutilización de DCV disminuye en paralelo, alcanzando solo 10 días para 2029.
Google había propuesto por separado pasar a certificados de 90 días, reforzando la dirección. La convergencia de la votación de Apple's y la defensa de Google's dejó claro que los ciclos de vida más cortos no son una cuestión de "if" sino de "when." Las organizaciones que esperen hasta 2028 para comenzar a prepararse enfrentarán una transición dolorosa y apresurada.
Los beneficios de seguridad de los ciclos de vida más cortos son reales, pero también lo son los desafíos operacionales. Para las organizaciones que aún gestionan certificados manualmente, el impacto será severo.
Una organización con 10,000 certificados que se renuevan anualmente necesitará procesar aproximadamente 80,000 renovaciones al año bajo un régimen de 47 días. Eso representa un aumento de 8 veces en el volumen operativo. Sin automatización, esta carga de trabajo es insostenible.
La gestión manual de certificados (hojas de cálculo, recordatorios por correo electrónico, flujos de trabajo basados en tickets) simplemente no puede seguir el ritmo de los ciclos de 47 días. Gestión automatizada de certificados mediante protocolos como ACME, EST y SCEP ya no es un lujo; es un requisito para la supervivencia operativa.
Más ciclos de renovación significan más oportunidades de que algo salga mal. Una renovación perdida, una implementación fallida, un servidor mal configurado: cada uno de estos conduce a interrupciones de certificados. El margen de error se reduce con cada disminución del período de validez.
No puedes automatizar lo que no puedes ver. Las organizaciones deben primero lograr una completa ciclo de vida del certificado visibilidad antes de que puedan automatizar de manera fiable las renovaciones. El descubrimiento y el inventario son prerrequisitos, no extras opcionales.
La transición a ciclos de vida más cortos no ocurre de la noche a la mañana, pero la preparación debe comenzar ahora. Aquí hay una hoja de ruta práctica para adelantarse al cambio.
Comience con un descubrimiento completo de todos los certificados en su infraestructura: servidores, balanceadores de carga, entornos en la nube, CDNs, dispositivos IoT y servicios internos. Necesita saber exactamente cuántos certificados gestiona y dónde se encuentran.
Para cada certificado, determine si el proceso de renovación e implementación puede automatizarse. Los certificados en sistemas heredados, dispositivos sin soporte ACME, o infraestructura gestionada manualmente requerirán atención especial y posiblemente integraciones personalizadas.
Implementar ACME, EST, o SCEP en su entorno. Priorice los sistemas de alto volumen primero (servidores web, balanceadores de carga, clústeres de Kubernetes) y trabaje hacia los casos límite. Pruebe los flujos de trabajo de renovación exhaustivamente antes de que se cumplan los plazos.
No espere los mandatos. Comience a emitir certificados de 90 días ahora, siempre que sea posible, para probar a fondo sus canalizaciones de automatización y flujos de trabajo operativos. Las organizaciones que ya han adoptado certificados de corta duración a través de Let's Encrypt o CAs internos están bien posicionadas para lo que sigue.
Incluso con automatización, las cosas fallan. Implemente monitoreo en tiempo real del estado del certificado, las tasas de éxito de renovación y la salud del despliegue. Configure alertas con suficiente antelación a la expiración para que los fallos sean detectados y resueltos antes de que causen interrupciones.
Descubrimiento de toda la infraestructura: Evertrust CLM escanea toda su infraestructura de forma continua, identificando cada certificado sin importar el emisor, la ubicación o el propietario. Obtiene una única fuente de verdad antes de comenzar a automatizar.
Automatización nativa de protocolos: Evertrust PKI soporta ACME, EST, SCEP y CMP de forma nativa, permitiendo una inscripción, renovación y despliegue totalmente automatizados sin intervención manual. Ya sea que necesite renovar cada 90 días o cada 47 días, el proceso es el mismo.
Alerta proactiva: Políticas de alerta configurables notifican a los equipos correctos en el momento adecuado, ya sea que eso's 30 días, 14 días o 7 días antes de la expiración. Las rutas de escalada garantizan que ninguna renovación se pierda.
Paneles de preparación: Vea de un vistazo qué certificados ya están automatizados, cuáles aún requieren intervención manual y dónde están sus brechas. Siga su progreso hacia una preparación completa de 47 días en toda la organización.
