El fin de los SSL anuales: prepárate para 2026

La gestión de la seguridad web está a las puertas de una transformación sin precedentes. La motivación principal detrás del cambio anunciado por Google es clara: acelerar la adopción de medidas criptográficas sólidas y reducir la ventana de oportunidad para los atacantes. Los certificados SSL/TLS públicos pasan de 398 días a tan solo 90 días de vigencia, un cambio que impactará de lleno a empresas en Lima, Perú y todo el mundo en 2026.

Esta guía está pensada para gerentes de TI, CTOs y empresarios peruanos que necesitan entender qué cambia con los nuevos certificados SSL de 90 días, qué riesgos implica para su empresa y cómo automatizar la renovación para no sufrir apagones de servicio que cuestan ventas y reputación.

El contexto del cambio: la iniciativa "Moving Forward, Together"

Todo comenzó con la iniciativa "Moving Forward, Together" impulsada por el equipo de Google Chrome Root Program. La intención es forzar a la industria a abandonar prácticas obsoletas y manuales en la gestión de infraestructuras de clave pública (PKI). Al reducir la validez de los certificados a 90 días, Google busca que las empresas asuman la automatización como un estándar innegociable, minimizando así las clásicas y catastróficas caídas de servicio causadas por el olvido humano en las fechas de renovación.

El cronograma oficial de Google Chrome contempla:

• 2024: los certificados SSL públicos pasaron de 398 a 200 días.
• 2026: reducción a 90 días para todos los certificados SSL públicos.
• 2027 (proyectado): propuesta de 47 días o menos.
• 2030 (a futuro): renovación cada pocos días con automatización completa.

Esto no es opcional ni reversible. Las empresas peruanas que no se adapten verán cómo sus webs aparecen como "No seguras" en Chrome, perdiendo clientes y posicionamiento SEO de un día para otro.

Por qué 90 días: los beneficios técnicos del cambio

La validación de identidad en internet depende de los certificados SSL, pero los de larga duración presentan un riesgo crítico: si un atacante compromete la clave privada de un servidor, tiene más de un año para interceptar tráfico antes de que el certificado expire. Las listas de revocación de certificados (CRL) y el protocolo OCSP suelen ser ineficientes en la práctica. Al acortar el ciclo de vida a 90 días (y proyectado hacia los 47 días), se logra lo siguiente:

Mitigación de exposición de claves comprometidas

Un certificado robado será inútil en un plazo de tiempo muy corto. Antes, una clave comprometida podía explotarse durante 13 meses. Ahora, máximo 3 meses.

Agilidad criptográfica para la era post-cuántica

Permite transicionar más velozmente a algoritmos post-cuánticos en toda la web cuando la criptografía tradicional sea vulnerada por computadores cuánticos. Todos los servidores se verán obligados a renovar sus certificados constantemente bajo nuevos esquemas.

Erradicación definitiva de la gestión manual

Un administrador de TI peruano no puede permitirse renovar certificados a mano 4 veces al año por cada subdominio de su infraestructura. La automatización deja de ser opcional.

Reducción de la ventana de ataque

Cualquier vulnerabilidad descubierta en un certificado existente se resuelve en máximo 90 días automáticamente al renovarse, sin esperar a que las CAs revoquen masivamente.

El riesgo operativo real para empresas peruanas en 2026

Las organizaciones peruanas que actualmente usan hojas de cálculo y alertas de calendario para gestionar sus renovaciones de SSL sufrirán apagones de servicio (downtime) frecuentes. Las consecuencias son severas:

• Bloqueo total de acceso para clientes: Chrome, Edge, Firefox y Safari muestran página completa de "Su conexión no es privada" cuando el certificado expira.
• Advertencias "Sitio no seguro": incluso si el certificado vence durante la noche, los clientes lo verán cuando intenten comprar al amanecer.
• Caída del posicionamiento SEO: Google penaliza inmediatamente sitios sin SSL válido en sus rankings.
• Pérdida de transacciones e-commerce: ningún cliente completa una compra cuando ve advertencias de seguridad.
• Bloqueo de APIs y servicios conectados: sistemas integrados (pasarelas de pago, ERPs, mobile apps) dejan de funcionar.
• Daño a la reputación corporativa: aparecer como "no seguro" mata la confianza B2B y B2C.
• Costos operativos: cada hora de downtime cuesta cientos o miles de soles según el negocio.

La única salida: protocolo ACME y automatización CLM

Para sobrevivir a este ecosistema agnóstico y acelerado, la respuesta tecnológica es contundente: implementar herramientas de Certificate Lifecycle Management (CLM) corporativas y habilitar infraestructuras compatibles con el estándar ACME (Automatic Certificate Management Environment). Este protocolo permite a los servidores web comunicarse directamente con la Autoridad Certificadora (CA) para validar, emitir e instalar los certificados de manera invisible, sin intervención humana y en cuestión de segundos.

Herramientas ACME open-source para empresas peruanas

• Certbot (Let's Encrypt): el estándar de facto. Gratuito, soportado por la mayoría de hostings.
• acme.sh: alternativa ligera, escrita en bash, muy popular en servidores Linux.
• Caddy: servidor web que automatiza SSL nativo sin configuración adicional.
• Traefik: reverse proxy moderno con ACME integrado, ideal para infraestructuras Docker.
• Nginx Proxy Manager (NPM): interfaz visual sobre nginx con renovación automática.

Soluciones CLM corporativas para empresas medianas y grandes

• Venafi TLS Protect: líder corporativo en gestión centralizada de certificados.
• DigiCert CertCentral: CA con plataforma de gestión incluida.
• Sectigo Certificate Manager: alternativa empresarial con soporte multi-CA.
• HashiCorp Vault: open-source para empresas con equipo DevOps maduro.

Plan de migración a SSL automatizado para empresas peruanas

Si tu empresa todavía gestiona SSL manualmente, este es el plan de acción para los próximos 60 días:

1. Inventario completo de certificados SSL. Lista todos los dominios, subdominios, APIs y servicios. La mayoría de empresas peruanas se sorprende de cuántos tienen olvidados.
2. Auditoría de fechas de vencimiento actuales. Identifica los que vencen en los próximos 6 meses.
3. Elige tu stack de automatización. Para PYMES: Caddy o Certbot + cron. Para empresas medianas: Nginx Proxy Manager. Para grandes: solución CLM corporativa.
4. Implementa en un dominio piloto. Antes de migrar todo, valida en un dominio menos crítico.
5. Despliega en el resto de la infraestructura. Por ola, no todo de golpe.
6. Configura monitoreo y alertas. Si la renovación falla por algún motivo, debes saberlo antes de que el certificado expire.
7. Documentación de proceso. Para que cualquier miembro del equipo pueda intervenir si algo falla.
8. Pruebas regulares de renovación forzada. Ejecutar la renovación manualmente cada mes para verificar que funciona.

Errores comunes al migrar a SSL automatizado en Perú

• Asumir que el hosting lo hace solo. Verifica explícitamente. Muchos hostings peruanos siguen dependiendo de renovación manual.
• No configurar alertas de fallo. Si la renovación falla y nadie se entera, el certificado vence igual.
• Olvidar subdominios. El SSL del dominio principal renueva, pero blog., shop., api. quedan colgados.
• Bloqueos de firewall que impiden la validación ACME. Verifica que los puertos 80 y 443 acepten la validación de Let's Encrypt.
• Certificados wildcard sin DNS-01. Wildcards (*.dominio.pe) requieren validación DNS, no HTTP. Hay que configurarlo aparte.

Casos típicos en empresas peruanas migrando a SSL automatizado

• E-commerce con 12 subdominios: migra de renovación manual anual a Caddy con renovación cada 30 días automática.
• Empresa con muchos sites WordPress: implementa Nginx Proxy Manager para gestionar todos los SSL desde una interfaz.
• Banca digital: adopta Venafi para certificados de aplicaciones internas, APIs y portales clientes.
• Startup SaaS: usa Traefik con Let's Encrypt en su infraestructura Kubernetes desde el día 1.

Conclusión: el SSL de 90 días no es una amenaza, es una oportunidad

El cambio a certificados SSL de 90 días que Google está empujando para 2026 no es un castigo a las empresas, sino un empujón hacia la madurez técnica. Las empresas peruanas que automaticen su gestión de certificados ahora ganarán seguridad, reducirán incidentes operativos y estarán preparadas para el siguiente paso (47 días en 2027).

Las que no se adapten sufrirán apagones recurrentes que costarán ventas, reputación y posicionamiento SEO. La automatización de SSL dejó de ser una capacidad técnica avanzada para convertirse en un requisito básico de operación digital.

Protege la infraestructura SSL de tu empresa con SentryOpen

Prepararse para este escenario requiere más que descargar un script. Involucra la reingeniería de los balanceadores de carga (Load Balancers), gateways de API, servidores de correo y aplicativos web. En SentryOpen abordamos este desafío mediante un enfoque holístico de DevSecOps: analizamos tu infraestructura de redes actual, diseñamos canalizaciones CI/CD seguras y automatizamos la rotación de secretos y certificados SSL en tiempo cero, garantizando alta disponibilidad. Si quieres adelantarte a la directiva de Google y fortalecer tu postura de seguridad perimetral, puedes contactarnos para una auditoría gratuita.