La renovación de certificados SSL es una de esas tareas que todo administrador web debe hacer periódicamente, pero que puede convertirse en dolor de cabeza si no se planea bien. He visto portales caer en pleno horario laboral por una renovación mal ejecutada, y créanme, no es algo que quieras explicarle a tu jefe o a la Oficina de Sistemas.
Lo primero que hay que entender es que los certificados SSL tienen fecha de vencimiento. Antes duraban dos años, luego pasaron a uno, y ahora la tendencia es hacia periodos más cortos. Esto significa que vamos a estar renovando con mayor frecuencia, así que mejor tener un proceso claro.
El calendario es tu mejor aliado
Empiezo siempre configurando alertas al menos 30 días antes del vencimiento. Algunos proveedores envían notificaciones automáticas, pero no te confíes. En el Archivo General de la Nación manejábamos varios dominios y subdominios, y más de una vez las notificaciones llegaban a correos de personas que ya no trabajaban allí.
Mi recomendación: lleva un calendario compartido con el equipo técnico donde estén marcadas todas las fechas de vencimiento. Incluye ahí también los datos del proveedor, el tipo de certificado (DV, OV, EV) y quién es el responsable de la renovación. Puede sonar básico, pero esta simple práctica me ha salvado varias veces.
Con 30 días de anticipación tienes margen para solicitar el certificado, validar el dominio, hacer pruebas y programar la instalación en un horario de bajo tráfico. Si esperas a la última semana, cualquier inconveniente con la validación del dominio o con el proveedor te va a dejar sin tiempo de maniobra.
El proceso técnico sin misterios
La renovación en sí tiene varios pasos que conviene hacer en orden. Primero, generas un nuevo CSR (Certificate Signing Request) en tu servidor. Algunos proveedores permiten reutilizar el anterior, pero yo prefiero generar uno nuevo con una llave privada fresca. Es más limpio.
Después viene la validación del dominio. Dependiendo del tipo de certificado, esto puede ser por correo, por archivo en el servidor o por registro DNS. La validación por DNS es la que más me gusta para portales institucionales porque no depende del servidor web y puedes hacerla con anticipación.
Una vez te entregan el certificado nuevo, lo ideal es probarlo primero en un ambiente de pruebas o en un servidor alterno. Si tu infraestructura no tiene ambiente de staging (cosa común en varias entidades), al menos revisa que el archivo del certificado esté completo, que incluya la cadena de certificados intermedios y que coincida con tu llave privada.
Aquí va un dato que aprendí a punta de errores: siempre descarga el certificado en formato correcto para tu servidor. Apache usa archivos .crt y .key separados, mientras que otros servidores como IIS prefieren .pfx. Tener el formato equivocado a las 10 de la noche cuando estás haciendo la instalación no es bacano.
La instalación sin tiempos muertos
Lo que me ha funcionado mejor es programar la instalación en horarios de bajo tráfico, típicamente entre 10 PM y 6 AM. Antes de tocar nada, hago backup completo de la configuración actual del servidor web. Guardo los certificados viejos, los archivos de configuración, todo.
El proceso de instalación varía según el servidor, pero la secuencia general es: detener el servicio web, reemplazar los archivos del certificado, verificar la configuración, reiniciar el servicio. En servidores con balanceador de carga, puedes hacerlo nodo por nodo sin afectar el servicio.
Después de reiniciar, lo primero es probar con herramientas como SSL Labs de Qualys. Te muestra si la cadena de certificados está completa, si hay problemas de configuración, qué versiones de TLS estás soportando. También pruebo desde diferentes navegadores y dispositivos, porque a veces hay inconsistencias.
Una duda que todavía tengo es si realmente vale la pena invertir en certificados EV (Extended Validation) para portales institucionales. Antes mostraban la barra verde con el nombre de la organización, pero los navegadores modernos ya no destacan esa diferencia visualmente. ¿Seguirá siendo relevante ese nivel de validación o es mejor invertir esos recursos en otras capas de seguridad?
Ojo con los certificados wildcard si manejas múltiples subdominios. Facilitan la administración, pero si se compromete la llave privada, todos los subdominios quedan expuestos. Es un balance entre comodidad y seguridad que cada organización debe evaluar.
Lo último: documenta todo el proceso. Qué hiciste, a qué hora, qué comandos usaste, qué problemas encontraste. La próxima renovación (que llegará más rápido de lo que crees) te lo va a agradecer. Y si rotas de cargo o llega alguien nuevo al equipo, esa documentación es oro puro.