Qué se rompe cuando vence un certificado
Un certificado SSL vencido no espera un martes conveniente. Los navegadores muestran una advertencia intimidante, los clientes de API rechazan la conexión y los clientes de correo pueden dejar de confiar en su servidor—a menudo mientras la página de inicio “se ve bien” para quien nunca ve las alertas de HTTPS. Para pequeños negocios, la solución no es más jerga. Es un inventario, un dueño nombrado y recordatorios en el calendario a 30, 14 y 7 días.
Esta es una lista operativa que TwoQM recomienda—no un tratado de criptografía.
Cuando un certificado pasa su fecha Not After, la confianza falla en varios lugares a la vez:
Navegadores — Chrome, Safari, Edge y Firefox muestran avisos (“Su conexión no es privada”). Muchos visitantes se van.
API y clientes móviles — Apps e integraciones que validan TLS suelen fallar de golpe, sin una interfaz amable.
Correo — IMAP/SMTP/webmail sobre TLS pueden romperse o advertir cuando vence el certificado del hostname de correo.
Webhooks y monitoreo — Las llamadas HTTPS de socios se detienen; las herramientas de uptime se ponen en rojo.
Basta con un renovado omitido en un solo hostname.
Inventarie cada certificado—no solo la página de inicio
Empiece con una hoja compartida. Liste cada lugar donde se presenta un certificado:
Apex — example.com
www — www.example.com (a menudo un certificado aparte o una entrada SAN)
Correo — mail., webmail., o el hostname que realmente usa IMAP/SMTP
Staging / preview — staging., dev., URLs de vista previa del host
CDN / edge — Cloudflare u otros certificados de borde delante del origen
Balanceador / proxy inverso — LB en la nube, nginx, AutoSSL de cPanel, pestañas SSL del panel
Comodines — *.example.com (la renovación sigue teniendo fecha)
Subdominios olvidados — reservas, tienda, portal, VPN, mesa de ayuda
Por cada fila: hostname(s), emisor, Not After, ubicación (panel, Cloudflare, LB, ACM), auto-renovación sí/no y quién es dueño de la renovación. Reasigne si el dueño ya se fue.
Auto-renovación vs CA manual
La mayoría de los stacks de pequeños negocios caen en uno de estos grupos:
Let’s Encrypt vía panel / AutoSSL / Certbot — Suele auto-renovar si el desafío sigue funcionando (HTTP-01 o DNS-01). Se rompe cuando cambia el DNS, un WAF bloquea /.well-known/acme-challenge/ o el trabajo del panel está desactivado.
SSL de borde en Cloudflare (o similar) — Los certificados de borde se renuevan en el producto; los del origen son otro problema. No asuma que “la CDN está encendida” significa que el TLS de origen está sano.
SSL de un clic en el panel del host — Bien hasta que el trabajo de renovación falla en silencio tras un cambio de dominio o nameservers.
Balanceador / administrador de certificados en la nube — Automático solo si los registros de validación DNS siguen existiendo y los listeners apuntan al certificado correcto.
Compra manual a una CA — Los recordatorios por correo ayudan solo si el buzón de contacto aún existe. Ponga las fechas en su calendario de todos modos.
La auto-renovación es una función, no una garantía. Trátela como “suele funcionar” y aun así calendarice el vencimiento.
Recordatorios en el calendario: 30 / 14 / 7 días
Por cada certificado del inventario, cree tres eventos en un calendario compartido del equipo:
30 días — Confirme que la auto-renovación está activa y que la ruta del desafío sigue funcionando. Haga una prueba en seco si su herramienta lo permite.
14 días — Verifique la próxima ventana de renovación; corrija bloqueos de DNS/WAF/panel ahora, no el día del vencimiento.
7 días — Escale: el dueño nombrado confirma que la renovación se logró o agenda una reemisión manual. No espere capturas de clientes.
Ponga hostname, emisor e iniciales del dueño en el título del evento—los eventos vagos de “revisar SSL” se saltan.
Errores que matan el “configurar y olvidar”
Cerebro dividido — Apex en AutoSSL del host, www en Cloudflare, correo en un tercer panel. Tres relojes de vencimiento.
Staging con certificado de corta vida — Los enlaces de demo mueren a mitad del ciclo de ventas.
Cambio de DNS sin renovar ACME — Let’s Encrypt falla tras mover nameservers o bloquear el puerto 80.
CDN que oculta el vencimiento del origen — Los visitantes ven el certificado de borde mientras fallan las comprobaciones al origen.
HSTS ya activado — Tras el vencimiento, el HSTS recordado hace imposible “usar HTTP un minuto”. Renueve antes de apoyarse en HSTS.
Correo de contacto incorrecto en la CA — Los avisos de renovación van a un buzón muerto.
Documente cada ruta de renovación como documenta quién es dueño de los deploys de producción.
Comprobaciones rápidas después de renovar
Después de cada renovación (auto o manual), no cierre el ticket hasta:
Candado / HTTPS — Carga en incógnito de apex y www por https://; sin aviso, sin desajuste de nombre.
Coincidencia de hostname — Los SAN del certificado cubren los nombres que usted escribe (incluidas redirecciones).
Contenido mixto — Consola de DevTools limpia de assets http:// bloqueados en páginas clave.
HSTS — Si envía Strict-Transport-Security, confirme que HTTPS sigue funcionando de punta a punta.
Hostname de correo — Si el correo usa TLS en un host con nombre, revise ese certificado también—no solo el sitio.
API / webhook — Pruebe una ruta HTTPS de integración si socios le llaman.
Monitoreo — Confirme que los monitores SSL muestran el nuevo Not After.
Registre fecha, hostname, emisor, nuevo vencimiento e iniciales del dueño.
Lista de la misma semana
Hoja de cada hostname que presenta TLS
Emisor, Not After, ubicación, auto-renovación sí/no
Dueño nombrado para cada ruta de renovación
Eventos de calendario a 30 / 14 / 7 días (calendario compartido)
Ruta ACME / panel / Cloudflare / LB documentada
Desafíos WAF y DNS verificados para hosts Let’s Encrypt
Smoke post-renovación: candado, SAN, contenido mixto, HSTS, host de correo
Alertas de monitoreo actualizadas al nuevo vencimiento
Iniciales del dueño y marca de tiempo en el registro de cambios
Haga que el vencimiento sea aburrido
Los incidentes de SSL vencido se sienten dramáticos porque los clientes los ven primero—casi siempre son fallos de calendario, no de criptografía.
La postura de TwoQM es simple: inventarie cada certificado, nombre un dueño, ponga 30/14/7 en un calendario compartido y haga smoke test después de renovar. Los navegadores nunca deberían ser el primer sistema que le diga que un certificado murió.