Lista de verificación de infraestructura de redirección para la era del certificado de 45 días

Las duraciones de los certificados SSL están a punto de reducirse a la mitad. Let's Encrypt — que impulsa el 60% de todos los certificados web — pasa de 90 días a un máximo de 45 días. La propuesta del Google CA/Browser Forum sigue esta misma dirección. Toda la industria de certificados está empujando hacia duraciones más cortas como estándar de seguridad, y el calendario ya no es algo teórico.

Para los equipos que gestionan infraestructura de redirecciones en cientos o miles de dominios, esto no es un ajuste menor: es un multiplicador operativo. Lo que antes requería 4 ciclos de renovación por dominio al año, pronto requerirá 8. Los procesos manuales que apenas funcionaban con 90 días fallarán por completo con 45.

Esta lista de verificación está diseñada para ayudar a los equipos de infraestructura a evaluar su preparación en seis ámbitos críticos: automatización, supervisión, tiempos de renovación, alertas, estrategia con comodines y recuperación ante desastres. Cada sección incluye una pregunta de autoevaluación y un estado objetivo. Al final, tendrás una imagen clara de en qué punto está tu infraestructura y qué necesita cambiar antes de que llegue la era de 45 días.

1. Automatización: Ciclo de vida de certificados sin intervención#

La pregunta más importante de tu evaluación de preparación: ¿se emiten y renuevan todos los certificados sin intervención humana?

Si la respuesta es cualquier cosa que no sea un “sí” sin matices, tienes un problema. Con duraciones de 45 días, las operaciones manuales de certificados se vuelven insostenibles incluso en escalas sorprendentemente pequeñas. Un portafolio de solo 50 dominios requiere 400 operaciones de certificados al año: más de una por día, todos los días, incluidos fines de semana y festivos.

Autoevaluación del estado actual: ¿cómo gestiona tu equipo el aprovisionamiento de certificados hoy? Si la respuesta incluye recordatorios de calendario, hojas de cálculo, generación manual de CSR o “normalmente lo hace alguien”, estás en el nivel manual. Incluso si has automatizado partes del flujo, pregúntate si el script cubre todos los dominios, gestiona todos los casos límite y se recupera de cada fallo sin escalar a una persona.

Estado objetivo: Cada nombre de host en tu infraestructura de redirecciones aprovisiona SSL automáticamente vía ACME en cuanto se configura el DNS. La emisión, instalación y renovación de certificados ocurren sin ninguna acción humana. El sistema detecta nuevos dominios, valida la propiedad mediante el desafío DNS-01, solicita el certificado, lo instala en nodos perimetrales y programa la siguiente renovación — todo dentro de segundos desde que se agrega el nombre de host.

Una plataforma de redirecciones que gestiona SSL por nombre de host — en lugar de obligarte a gestionar certificados por servidor — elimina por completo la brecha de automatización. Cuando el DNS se delega en la plataforma, SSL se convierte en una propiedad de la infraestructura, no en una tarea más en la lista de pendientes de alguien.

2. Supervisión: Conoce el problema antes de que se rompa#

Pregúntate: ¿Tienes un monitoreo activo del vencimiento de certificados en todos los dominios?

El monitoreo es la red de seguridad que está debajo de la automatización. Incluso con la renovación basada en ACME, pueden salir mal las cosas: cambia un registro DNS, se activa un límite de velocidad, una CA sufre una caída. Sin monitoreo, descubres certificados vencidos de la misma forma que tus usuarios: mediante una advertencia del navegador.

Pero el monitoreo no se trata solo de comprobar fechas de vencimiento. Un monitoreo efectivo para la infraestructura de redirección implica comprobaciones de estado desde múltiples ubicaciones globales, porque un certificado que parece válido desde tu oficina podría fallar desde la ubicación de un usuario debido a retrasos de propagación en el borde o al almacenamiento en caché del CDN.

Autoevaluación del estado actual: ¿Tienes un panel o un sistema de alertas que muestre las fechas de vencimiento de los certificados para cada dominio? ¿Se actualiza en tiempo real cuando se renuevan los certificados? ¿Puedes ver de un vistazo qué dominios se están acercando al vencimiento y cuáles ya han fallado?

Estado objetivo: monitoreo continuo de la salud de los certificados desde múltiples ubicaciones de borde globales. El sistema realiza comprobaciones activas de enlace TLS, no solo búsquedas de fechas de vencimiento, para verificar que cada certificado sea válido, esté confiado y se esté sirviendo correctamente. El panel muestra el estado en tiempo real en todos los dominios. El monitoreo es automático: cuando se agrega un nuevo nombre de host, el monitoreo comienza sin configuración.

3. Momento de la renovación: la zona de amortiguación#

La pregunta: ¿Se intentan las renovaciones con suficiente antelación como para resistir cortes de varios días?

Con certificados de 90 días, renovar entre 7 y 14 días antes del vencimiento proporcionaba un margen cómodo. Con certificados de 45 días, el mismo margen consume entre el 15 y el 30% de la vida útil total utilizable del certificado. Las cuentas obligan a un compromiso: si renuevas demasiado pronto, estás cambiando certificados constantemente; si renuevas demasiado tarde, una caída temporal de la CA se convierte en un incidente en producción.

Los límites de velocidad de Let's Encrypt agregan otra dimensión. El límite de "certificado duplicado" permite 5 certificados por semana para el mismo conjunto de nombres de host, y el límite de "certificados por dominio registrado" se limita a 50 por semana. En ciclos de renovación de 45 días, los grandes portafolios de dominios pueden acercarse a estos límites más rápido de lo esperado, especialmente si también estás aprovisionando certificados para dominios nuevos.

Autoevaluación del estado actual: ¿Cuál es tu ventana de renovación? Si tu equipo renueva certificados manualmente, ¿las renovaciones se inician al menos 15 días antes del vencimiento? ¿Puedes resistir una caída de 5 días de la CA sin que venza ningún certificado? ¿Has probado qué sucede cuando falla un intento de renovación: el sistema reintenta automáticamente o espera intervención humana?

Estado objetivo: Las renovaciones automatizadas comienzan 30 días antes del vencimiento con una lógica de reintento de retroceso exponencial. Si el primer intento falla, el sistema reintenta en intervalos crecientes — 1 hora, 4 horas, 12 horas, 24 horas — hasta que la renovación tenga éxito. Los límites de tasa se rastrean y se respetan automáticamente. El sistema puede resistir una caída de la CA durante varios días sin que ningún dominio llegue a su fecha de vencimiento, porque las renovaciones se inician con suficiente antelación como para que siempre haya al menos 15 días de margen.

4. Alertas: Antes, no después#

La pregunta: ¿Se notifica a las personas adecuadas antes — no después — del vencimiento del certificado?

La capacidad de alertar es la diferencia entre un no-evento y un incidente. Cuando falla una renovación de certificado, deben ocurrir dos cosas: el sistema reintenta automáticamente (ver sección 3) y la persona adecuada se entera. Si tu monitorización detecta un certificado vencido sin alertar a nadie, sigues teniendo un vacío: solo te enteras antes.

Las alertas deben estar escalonadas según la severidad y la audiencia. Una renovación fallida que se reintenta y tiene éxito 30 minutos después no necesita una página a las 2 a. m.; pero debería aparecer en un resumen diario. Un certificado que se acerca a sus últimas 72 horas sin una renovación exitosa es una alerta crítica que debe llegar al ingeniero de guardia de inmediato.

Autoevaluación del estado actual: ¿A quién se notifica cuando un certificado está por vencer? ¿Existe un sistema de alertas escalonado con diferentes niveles de severidad? ¿Las alertas van a los canales correctos (Slack, correo electrónico, PagerDuty) según la urgencia? Si la persona principal de guardia no está disponible, ¿la alerta se escala?

Estado objetivo: Alertas en tres niveles: Información (se intentó la renovación, resumen diario), Advertencia (falló la renovación, ventana de 7 días, Slack/correo), Crítico (la renovación falló repetidamente, ventana de 72 horas, escalamiento en PagerDuty/guardia). Las alertas incluyen el nombre del dominio, la fecha de vencimiento del certificado, la hora del último intento de renovación y el motivo del fallo. Todos los dominios del portafolio están cubiertos — sin excepciones, sin “lo monitorearemos manualmente ese”.

5. Certificados comodín: Conveniencia vs. Riesgo#

La pregunta: ¿Los certificados comodín se gestionan correctamente o están creando puntos únicos de fallo?

Los certificados comodín son tentadores: un certificado para *.example.com cubre todos los subdominios. Una renovación. Una fecha de vencimiento. Una cosa que gestionar. Pero esa “cosa que gestionar” también es una única cosa que puede fallar — y cuando falla, todos los subdominios se apagan simultáneamente.

Para la infraestructura de redirección específicamente, los comodines crean otro problema: los desafíos DNS-01 para certificados comodín requieren acceso a la zona DNS del dominio raíz (apex). Si tus dominios de redirección están repartidos entre varios registradores y proveedores de DNS — algo común en carteras grandes — gestionar los desafíos DNS-01 para un único comodín se vuelve significativamente más complejo que gestionar certificados por nombre de host.

Autoevaluación del estado actual: ¿Estás usando certificados comodín para dominios de redirección? Si el certificado comodín falla al renovarse, ¿a cuántos dominios afecta? ¿Tienes un plan de reversión (rollback) probado? ¿Los comodines los gestiona el mismo equipo que gestiona los certificados por dominio, o son procesos separados con responsables distintos?

Estado objetivo: Los certificados por nombre de host son la opción predeterminada. Cada dominio obtiene su propio certificado, aprovisionado y renovado de forma independiente. Esto proporciona aislamiento: un fallo de renovación en un dominio no afecta a ningún otro. Los comodines se usan solo cuando se necesitan explícitamente (p. ej., servicios internos detrás de un subdominio compartido), con supervisión y alertas separadas — y un procedimiento de recuperación documentado y probado.

6. Recuperación ante desastres: Cuando la CA se cae#

La pregunta: Si tu Autoridad de Certificación (CA) no está disponible durante 5 días, ¿tus certificados sobreviven?

Let’s Encrypt ha experimentado interrupciones de varias horas en el pasado. Con duraciones de certificados de 90 días, una interrupción de 2-3 días era manejable: los certificados tenían suficiente validez restante para resistirla. Con 45 días, la misma interrupción puede empujar los certificados más allá de su ventana de renovación antes de que la CA vuelva a estar en línea.

La recuperación ante desastres para SSL no se trata solo de la CA. Se trata de DNS: si tu proveedor de DNS tiene una interrupción durante una ventana de desafío DNS-01, el desafío falla y la renovación queda bloqueada. Se trata de la propagación en el borde (edge): si un certificado renovado no se propaga a todos los nodos de borde antes de que expire el anterior, algunos usuarios ven errores. Y se trata del propio pipeline de renovación: si tu plataforma de automatización tiene una interrupción, ¿las renovaciones se encolan o se pierden?

Autoevaluación del estado actual: ¿Has modelado qué sucede durante una interrupción de 5 días de la CA? ¿Cuál es tu ventana más corta de validez de certificado en toda la cartera? ¿Tienes configurada una CA alternativa (fallback), o todos los certificados dependen de un único proveedor? ¿Puede tu infraestructura DNS resistir una interrupción durante una ventana de desafío?

Estado objetivo: Los certificados se renuevan con suficiente antelación como para que cada dominio mantenga al menos 15 días de margen — lo bastante para resistir una interrupción realista de la CA. El pipeline de renovación es resiliente: si una renovación falla debido a la indisponibilidad de la CA, el sistema reintenta automáticamente cuando la CA se recupera. La supervisión cubre toda la cadena de dependencias (DNS, CA, propagación en el borde), no solo las fechas de caducidad de los certificados. Las CA alternativas se configuran para dominios críticos, y el equipo tiene un runbook documentado y probado para aprovisionar certificados manualmente durante interrupciones prolongadas de la CA.

Autoevaluación: Califica tu nivel de preparación#

Califica tu infraestructura en cada uno de los seis ámbitos a continuación. Sé honesto: una puntuación baja no es un fracaso; es una hoja de ruta.

Puntuación: 1 = Manual / Sin capacidad, 2 = Parcialmente automatizado / Hay brechas, 3 = Mayormente automatizado / Brechas menores, 4 = Totalmente automatizado / Sin brechas, 5 = Totalmente automatizado + probado / Resiliente

Interpretando tu total:

24-30: Estás listo. Tu infraestructura está automatizada, monitorizada y es resiliente. Enfócate en mantener este estado y probar regularmente tus procedimientos de recuperación.

18-23: Tienes bases sólidas, pero aún hay brechas. Prioriza primero los dominios «Críticos»: la automatización y el momento de renovación son las mejoras con mayor ROI. Un plazo de 45 días pondrá a prueba tu configuración actual.

12-17: Tu infraestructura no está lista para certificados de 45 días. Los procesos manuales que funcionan a 90 días se romperán a 45. Empieza con la automatización (dominio ①): si solo corriges una cosa, haz que el aprovisionamiento y la renovación de certificados sean automáticos.

6-11: Estás en alto riesgo. Cada dominio de tu cartera es vulnerable a un solo recordatorio de calendario omitido o a una caída de la CA. Considera pasar a una plataforma de redirección que gestione la automatización de SSL como infraestructura — no como una tarea — para cerrar la brecha rápidamente.

La brecha solo se hace más grande#

La era de los certificados de 45 días no es una posibilidad futura: es una trayectoria de la industria con un calendario definido. Let's Encrypt, que emite certificados para más de 360 millones de dominios, está liderando el cambio. La propuesta del CA/Browser Forum de Google sigue la misma dirección. El estándar se está moviendo, y la brecha entre la infraestructura automatizada y la manual solo se amplía a medida que se reducen las vigencias de los certificados.

Los equipos que automatizan ahora no sentirán el cambio. Verán que sus paneles muestran renovaciones completándose a tiempo: 30 días antes, cada vez, en cada dominio, mientras que otros se apresuran para actualizar hojas de cálculo. La lista de verificación anterior no es solo una herramienta de evaluación. Es una hoja de ruta hacia una infraestructura preparada para cualquier vigencia de certificado en la que se asiente la industria: 45 días, 30 días o menos.

Evalúa tu infraestructura. Cierra las brechas. La era de los certificados de 45 días ya viene: tus dominios de redirección deberían ser lo último que te preocupe.