Certificados SSL más cortos: cómo prepararse para renovaciones de 47 días
Los certificados SSL/TLS públicos reducirán su vigencia máxima hasta 47 días en 2029. Conoce el calendario oficial, los riesgos operativos y cómo preparar renovación automatizada.
Los certificados SSL/TLS públicos están entrando en una etapa de ciclos de vida mucho más cortos. El cambio ya forma parte de los requisitos de la industria: desde el 15 de marzo de 2026 el máximo permitido bajó a 200 días, desde el 15 de marzo de 2027 bajará a 100 días y desde el 15 de marzo de 2029 bajará a 47 días.
Para una empresa, la conclusión práctica es clara: la renovación manual de certificados deja de ser una tarea ocasional y se convierte en un riesgo operativo. Quien dependa de recordatorios en calendario, archivos compartidos o renovaciones hechas a mano estará más expuesto a caídas por certificados vencidos, errores de validación de dominio y ventanas de mantenimiento improvisadas.
Resumen ejecutivo
- El cambio aplica a certificados TLS públicamente confiables, es decir, los que usan sitios, APIs y servicios accesibles por navegadores o clientes que confían en autoridades certificadoras públicas.
- No acorta automáticamente certificados ya emitidos. La regla afecta la vigencia máxima de certificados nuevos emitidos en cada etapa.
- El reto principal no es comprar certificados con más frecuencia, sino automatizar emisión, validación, instalación, pruebas y monitoreo.
- La validación de dominio también se acorta. El periodo máximo de reutilización de validación de dominio e IP baja hasta 10 días en 2029.
- Las empresas deben preparar inventario, responsables, monitoreo y renovación automatizada antes de que la operación diaria dependa de ciclos de 47 días.
Qué está cambiando exactamente
El CA/Browser Forum aprobó el Ballot SC-081v3 para reducir gradualmente la vigencia máxima de certificados TLS de servidor y los periodos en los que las autoridades certificadoras pueden reutilizar datos de validación. En términos operativos, el calendario queda así:
- Antes del 15 de marzo de 2026: hasta 398 días de vigencia máxima.
- Del 15 de marzo de 2026 al 14 de marzo de 2027: hasta 200 días.
- Del 15 de marzo de 2027 al 14 de marzo de 2029: hasta 100 días.
- A partir del 15 de marzo de 2029: hasta 47 días.
Los requisitos base también recomiendan apuntar a un día menos que el máximo para evitar errores por horas exactas de emisión, zonas horarias o cálculos de vigencia entre sistemas. Por eso es normal que algunos proveedores manejen límites comerciales de 199, 99 o 46 días aunque el máximo normativo sea 200, 100 o 47.
Por qué se reduce la vigencia
La reducción busca disminuir el tiempo durante el cual un certificado o una llave comprometida puede seguir siendo útil, acelerar la adopción de mejoras criptográficas y obligar a que la administración de certificados sea más automatizada. También reduce el impacto de datos desactualizados o cambios de control sobre dominios, porque la información validada se reutiliza por menos tiempo.
La tendencia no es nueva. La industria ha pasado de certificados de varios años a ciclos cada vez más cortos. El salto a 47 días debe verse como la continuación de esa tendencia: la confianza digital depende cada vez más de inventario preciso, automatización confiable y monitoreo permanente.
A quién afecta
El cambio afecta a cualquier organización que use certificados públicamente confiables para sitios web, APIs, portales de clientes, paneles administrativos, tiendas en línea, servicios de correo, gateways, balanceadores, CDNs, endpoints de integración o aplicaciones móviles que consumen servicios HTTPS.
También impacta a equipos que no siempre se ven como responsables directos de certificados:
- TI e infraestructura: servidores, balanceadores, proxies, firewalls, appliances, DNS y redes.
- Desarrollo y DevOps: pipelines, APIs, entornos cloud, Kubernetes, contenedores y despliegues automatizados.
- Operaciones y soporte: monitoreo, alertas, ventanas de mantenimiento y respuesta ante incidentes.
- Compras y administración: renovaciones, proveedores, aprobaciones y políticas internas.
- Seguridad: control de llaves privadas, cumplimiento, rotación, auditoría y gestión de riesgos.
Lo que puede fallar si se sigue renovando manualmente
Con certificados de 398 días, una empresa podía sobrevivir con recordatorios anuales, aunque no fuera lo recomendable. Con ciclos de 47 días, ese enfoque se vuelve frágil. El margen real para detectar, aprobar, emitir, validar, instalar, probar y corregir errores será mucho menor.
Los fallos más comunes serán:
- Certificados vencidos: el sitio o API deja de ser confiable para navegadores y clientes, provocando errores visibles para usuarios.
- Renovaciones incompletas: el certificado se emite, pero no se instala en todos los servidores, nodos, contenedores o balanceadores.
- Validaciones de dominio fallidas: cambios de DNS, CAA, DNSSEC, CDN o firewall impiden que la autoridad certificadora compruebe control del dominio.
- Dependencias olvidadas: se renueva el dominio principal, pero queda vencido un subdominio, API, panel interno expuesto o servicio de terceros.
- Ausencia de monitoreo externo: el equipo se entera del problema por clientes, no por alertas internas.
La validación de dominio también cambia
El calendario no solo reduce la vigencia del certificado. También reduce el periodo durante el cual puede reutilizarse la validación de nombre de dominio o dirección IP. Según los requisitos base del CA/Browser Forum, ese periodo queda en 200 días desde el 15 de marzo de 2026, 100 días desde el 15 de marzo de 2027 y 10 días desde el 15 de marzo de 2029.
Esto significa que no basta con programar una descarga periódica del certificado. El proceso completo debe poder demostrar control del dominio con frecuencia. Si la validación depende de que una persona copie un archivo, responda un correo, cambie un TXT de DNS o autorice algo manualmente, el riesgo operativo crece.
Automatizar la renovación SSL/TLS reduce el riesgo de caídas cuando los ciclos de vigencia se vuelven más cortos.Cómo prepararse sin esperar a 2029
La preparación debe empezar por inventario y automatización gradual. El objetivo no es cambiar todo el mismo día, sino quitar puntos manuales antes de que los plazos obliguen a hacerlo bajo presión.
1. Hacer inventario real de certificados
El primer paso es saber qué certificados existen y dónde viven. No basta con revisar el dominio principal. Hay que incluir dominios, subdominios, APIs, balanceadores, CDNs, firewalls, servicios de correo, paneles administrativos, ambientes de prueba y certificados administrados por terceros.
2. Identificar responsable, proveedor y método de validación
Cada certificado o grupo de certificados debe tener propietario, proveedor, autoridad certificadora, método de renovación, método de validación y canal de alerta. Muchos incidentes no ocurren por falta de conocimiento técnico, sino por falta de responsabilidad clara.
3. Moverse hacia ACME y renovación automatizada
ACME, definido en RFC 8555, es el estándar que permite automatizar verificación, emisión y renovación de certificados. Herramientas como Certbot y clientes ACME equivalentes pueden renovar certificados de forma programada, usar hooks para recargar servicios y reducir intervención humana.
En servidores Linux tradicionales, esto puede significar revisar Certbot, timers de systemd, cron, hooks de despliegue y recarga de Nginx o Apache. En infraestructura cloud o Kubernetes, puede implicar administradores de certificados, integración con DNS, secretos, balanceadores administrados y pipelines.
4. Probar renovaciones antes del vencimiento
Una automatización que nunca se prueba es solo una suposición. Cada servicio crítico debe tener una prueba controlada de renovación o, al menos, una validación de que el cliente ACME puede renovar, instalar y recargar sin romper tráfico.
5. Monitorear desde fuera del servidor
El monitoreo debe revisar la fecha de expiración desde la perspectiva del usuario final, no solo el estado del archivo local. Es posible tener el certificado correcto en disco y que el balanceador, CDN o contenedor siga entregando uno anterior. Las alertas deben avisar con anticipación y también detectar errores de cadena, nombre de dominio, SNI o configuración TLS.
6. Revisar DNS, CAA y DNSSEC
La validación de dominio depende cada vez más de DNS sano y predecible. Es conveniente revisar registros CAA, delegaciones DNS, proveedores con permisos para automatizar desafíos DNS-01, configuración DNSSEC cuando aplique y procesos para cambios de proveedor.
Buenas prácticas para pymes y equipos pequeños
Las pymes no necesitan construir una plataforma compleja desde el primer día, pero sí necesitan eliminar dependencias manuales peligrosas. Una ruta razonable es:
- Listar todos los dominios y subdominios públicos.
- Detectar certificados que vencen en los próximos 90 días.
- Separar servicios críticos de servicios secundarios.
- Automatizar primero el sitio principal, APIs de venta, portales de clientes y correo.
- Configurar alertas externas de expiración.
- Documentar el procedimiento de recuperación si una renovación falla.
- Revisar mensualmente que la automatización siga funcionando.
El peor escenario es pensar que el proveedor se encargará de todo sin confirmarlo. Algunos servicios administrados renuevan automáticamente, otros requieren configuración, validación de dominio o aprobaciones. Conviene pedir evidencia concreta: fecha de expiración, método de renovación, responsable y alerta.
Preguntas frecuentes
¿Entonces SSL desaparece?
No. En lenguaje común se sigue diciendo certificado SSL, pero técnicamente hoy hablamos de TLS. El cambio es sobre certificados TLS públicamente confiables usados para autenticar servidores.
¿Mis certificados actuales se acortan automáticamente?
No en condiciones normales. Un certificado emitido antes de una fecha límite mantiene su expiración original. La reducción aplica a certificados nuevos emitidos dentro de cada etapa del calendario.
¿Let's Encrypt también cambia?
Sí. Let's Encrypt anunció una reducción gradual de sus certificados de 90 a 45 días antes de 2028, alineada con la dirección de la industria. Para usuarios con renovación automática bien configurada, el cambio debería ser manejable, pero aun así se recomienda verificar compatibilidad, frecuencia de ejecución y monitoreo.
¿Puedo seguir renovando manualmente?
Técnicamente puede ser posible en algunos casos, pero operacionalmente será cada vez menos recomendable. Cuando la vigencia llegue a 47 días y la reutilización de validación de dominio llegue a 10 días, el margen para errores humanos será demasiado pequeño para servicios importantes.
¿Esto aplica a certificados internos o privados?
El calendario del CA/Browser Forum aplica a certificados públicamente confiables. Las PKI privadas pueden tener sus propias políticas, aunque muchas organizaciones terminarán adoptando ciclos más cortos también en entornos internos por consistencia operativa y seguridad.
Checklist de preparación
- Inventario completo de certificados, dominios y subdominios.
- Propietario asignado para cada servicio.
- Proveedor y autoridad certificadora documentados.
- Método de validación de dominio identificado.
- Renovación automatizada con ACME u otro mecanismo confiable.
- Hooks o despliegue automático que recargan Nginx, Apache, balanceador, contenedor o servicio correspondiente.
- Alertas externas de expiración y errores TLS.
- Prueba de renovación y rollback documentados.
- Control de acceso sobre llaves privadas y credenciales DNS.
- Revisión periódica de CAA, DNSSEC, subdominios y servicios olvidados.
Cómo puede ayudar Acinsoft
Acinsoft puede apoyar a empresas que necesitan ordenar su administración de certificados antes de que los ciclos cortos se vuelvan urgentes. El trabajo recomendable empieza con un diagnóstico: inventario de dominios, revisión de servidores, estado de renovaciones, monitoreo, DNS y dependencias públicas.
A partir de ahí se puede definir un plan por prioridad: automatizar los servicios más críticos, documentar responsables, configurar alertas, probar renovaciones y dejar un procedimiento de respuesta para fallos. El objetivo no es solo cumplir con una fecha, sino reducir el riesgo de interrupciones por certificados vencidos.
Fuentes consultadas
