Un proceso fiable de renovación de SSL sin interrupciones
Publicado el 18 de octubre de 2026
El proceso de renovación de SSL debe comenzar con suficiente antelación al vencimiento del certificado, tras comprobar el inventario de certificados, el acceso al DNS y la ruta de implementación. La renovación de un certificado suele ser un trámite rutinario. Las interrupciones ocurren a su alrededor: un subdominio olvidado, un registro de validación añadido a la zona DNS equivocada o un certificado nuevo instalado en un servidor mientras el tráfico sigue llegando a otro.
En un sitio web de producción, trata la renovación como un pequeño cambio de mantenimiento con un plan de reversión. Genera o solicita el certificado de reemplazo, completa la validación, instala la cadena completa de certificados, recarga el servicio web correspondiente y verifica lo que reciben realmente los visitantes externos. Si se hace de esta manera, el servicio sigue funcionando con normalidad y los navegadores no tienen motivos para mostrar advertencias.
Qué se renueva realmente en el proceso de renovación de SSL
Un certificado SSL es el documento de identidad que presenta tu servidor durante una conexión HTTPS. Confirma que los visitantes han llegado al dominio previsto y establece una comunicación cifrada entre su navegador y tu sitio.
Por lo general, la renovación no implica cambiar tu sitio web, aplicación ni dirección IP del servidor. Consiste en reemplazar el certificado existente por uno recién emitido antes de que venza el anterior. Los certificados TLS de confianza pública tienen periodos de validez limitados, a menudo de no más de unos 398 días, y muchas organizaciones optan por plazos más cortos o por la emisión automatizada. La fecha del certificado no es una sugerencia del navegador. Una vez vencido, los visitantes pueden ver una advertencia de caducidad aunque el sitio funcione perfectamente.
El método de renovación depende del tipo de certificado y de la entidad emisora. Un certificado de pago con validación de organización puede requerir una confirmación mediante un correo electrónico de aprobación, un registro DNS o un archivo colocado en el sitio web. Los certificados automatizados suelen utilizar la validación ACME mediante HTTP o DNS. El objetivo operativo es el mismo: demostrar el control del dominio, recibir el certificado e implementarlo correctamente.
Empieza con un inventario, no con el correo de vencimiento
La primera tarea es localizar todos los puntos de conexión que utilizan el certificado. Una misma empresa puede tener certificados distintos para su sitio principal, la versión www, el portal de clientes, la API, el servidor de correo, el entorno de pruebas y el balanceador de carga. Un aviso de vencimiento para un nombre de host no demuestra que todos los demás estén cubiertos.
Comprueba los nombres alternativos del sujeto del certificado, normalmente llamados SAN. Estos indican los dominios y subdominios incluidos en el certificado. Si `www.example.com` no está incluido, un certificado solo para `example.com` no lo protegerá. Los certificados comodín cubren subdominios de primer nivel, como `shop.example.com`, pero no cubren automáticamente el dominio raíz ni nombres de niveles más profundos, como `eu.shop.example.com`.
Identifica también dónde termina TLS. En un VPS sencillo, el certificado puede estar directamente en NGINX, Apache, Caddy o un panel de control de alojamiento. En una infraestructura más grande, el certificado podría estar instalado en un proxy inverso, una CDN, un balanceador de carga en la nube, un controlador de entrada de Kubernetes o varios nodos detrás de un balanceador de tráfico. Renovar el certificado en el servidor de aplicaciones no sirve de nada si el proxy que está delante sigue presentando el anterior. A veces, la configuración DNS no es la más sencilla, pero se puede controlar una vez trazada la ruta del tráfico.
Programa recordatorios internos para antes de la fecha de vencimiento pública. Treinta días es un plazo razonable para un certificado sencillo, mientras que entre 45 y 60 días ofrece más margen cuando participan varios equipos, proveedores DNS externos o la validación de la empresa. La supervisión debería generar alertas en más de un momento, por ejemplo, cuando queden 30, 14, 7 y 3 días. Un único recordatorio por correo electrónico puede acabar filtrado, ser ignorado o enviarse a alguien que dejó la empresa la primavera pasada.
Elige un método de validación adecuado para tu infraestructura
La validación del control del dominio es donde se atascan muchas renovaciones. La entidad de certificación necesita pruebas de que controlas el dominio solicitado. El mejor método es aquel que tu equipo puede repetir de forma segura.
La validación HTTP coloca un archivo específico en una URL pública determinada. Es práctica cuando se puede acceder directamente al servidor web por el puerto 80 y este sirve el host virtual correcto. Puede fallar si el tráfico se redirige de forma inusual, el sitio está detrás de un proxy restrictivo o un cortafuegos bloquea la solicitud de validación.
La validación DNS requiere un registro TXT en el proveedor DNS del dominio. Suele ser la mejor opción para certificados comodín y sistemas que no pueden exponer una ruta de validación HTTP. También funciona bien con infraestructuras distribuidas, pero hay que dejar tiempo para la propagación del DNS. Algunos cambios de DNS se propagan en segundos; otros tardan más debido a los valores TTL, el comportamiento del proveedor y las cachés de los servidores de resolución. No elimines un registro de validación hasta que se confirme la emisión.
La validación por correo electrónico puede funcionar en entornos pequeños y estables, pero depende más del acceso al buzón y de las direcciones aprobadas. Si los datos de contacto del registro del dominio están desactualizados o ya nadie supervisa un buzón de función, la renovación se detiene ahí. Para los servicios críticos para el negocio, la validación DNS o ACME automatizada suele reducir los cuellos de botella humanos.
Genera el certificado con cuidado
Para los certificados gestionados manualmente, genera una solicitud de firma de certificado, o CSR, en el sistema donde se almacenará la clave privada. La CSR contiene la clave pública y los datos del dominio. La clave privada debe mantenerse privada. No la envíes por correo electrónico, no la pegues en tickets ni la guardes en un documento compartido llamado `final-final-use-this-one`.
Puedes reutilizar una clave existente al renovar, pero generar una nueva clave privada suele ser la opción operativa más segura. La rotación de claves limita el impacto si alguien expuso una clave antigua sin que nadie se diera cuenta. La contrapartida es sencilla: una clave nueva requiere una implementación cuidadosa en todos los lugares donde se utilice el certificado. En la mayoría de las instalaciones con un solo servidor, ese trabajo adicional es mínimo y vale la pena.
Después de la emisión, descarga el certificado del servidor y la cadena de certificados intermedios proporcionada por la entidad de certificación. Los servidores web modernos suelen necesitar un archivo de cadena completa que contenga el certificado del dominio y los certificados intermedios. La falta de certificados intermedios es una causa clásica de errores de confianza en los navegadores, especialmente en dispositivos antiguos o clientes menos comunes.
Los clientes ACME automatizados pueden gestionar la generación de claves, la validación, la renovación y los ganchos de instalación. Se recomienda encarecidamente automatizar los certificados que lo permitan, pero aun así es necesario supervisarlos. Una tarea de renovación automática que no puede acceder al DNS, escribir en el directorio de certificados o recargar NGINX solo es automática en el sentido más optimista de la palabra.
Implementa los cambios sin interrumpir a los visitantes
Antes de reemplazar nada, copia el certificado y la configuración actuales en una ubicación de respaldo protegida. Conserva el certificado anterior, la referencia a la clave y la configuración que sabes que funciona hasta verificar la nueva instalación. Así, tu equipo tendrá una vía rápida de reversión si hay un problema con el archivo de cadena, los permisos o algún detalle de sintaxis.
Instala el certificado nuevo y la clave privada correspondiente en la ubicación prevista. Confirma que el proceso del servidor web pueda leer los archivos sin dejar la clave privada accesible para cualquiera. En Linux, son importantes las restricciones de propiedad y permisos. Por diseño, un certificado es público; su clave privada no lo es.
Valida la configuración del servidor web antes de recargarlo. Para NGINX, Apache, HAProxy y servicios similares, ejecuta primero el comando de prueba de configuración del producto. Después, cuando sea posible, recarga el servicio en lugar de reiniciarlo. La recarga aplica la actualización del certificado y permite que los procesos de trabajo existentes y las conexiones activas terminen correctamente. Un reinicio completo puede ser aceptable durante una ventana de mantenimiento, pero no es necesario en muchas configuraciones habituales.
Si el servicio se ejecuta en varios servidores, implementa el cambio de forma coherente en todos los nodos antes de la rotación controlada o durante ella. Los balanceadores de carga pueden enviar solicitudes consecutivas del navegador a distintos servidores de backend. Si solo un nodo tiene el certificado nuevo, pueden aparecer advertencias intermitentes; es un problema especialmente molesto porque parece imaginario hasta que deja de serlo.
Verifica el certificado desde fuera del servidor
No des el proceso por terminado cuando el panel de control indique que la instalación se completó correctamente. Verifica el certificado desde una red externa y comprueba el nombre de host que utilizan los visitantes. Confirma el nombre común o la cobertura SAN, la entidad emisora, la fecha de vencimiento y la cadena de certificados. Comprueba los nombres de host raíz y www si ambos son públicos.
Usa un navegador como uno de los puntos de verificación, pero no confíes únicamente en él. Es posible que almacene en caché sesiones o información de la cadena. Haz la prueba con un cliente TLS o una comprobación de supervisión externa que indique qué certificado se sirve en la dirección IP pública. En entornos avanzados, confirma que se devuelva el certificado correcto mediante la indicación del nombre del servidor, o SNI, para cada dominio alojado.
Después, comprueba el comportamiento de la aplicación: inicia sesión, envía un formulario, llama a un endpoint de la API e inspecciona las URL de devolución de llamada de terceros que usen HTTPS. La renovación del certificado no debería cambiar el comportamiento de la aplicación, pero la validación y las reglas del proxy a veces sacan a la luz problemas de configuración no relacionados. Ahora los registros cuentan la misma historia cuando tanto la comprobación externa del certificado como las comprobaciones de la aplicación se completan correctamente.
Haz que la próxima renovación sea rutinaria
El mejor proceso de renovación de SSL es aquel que nadie tiene que apresurarse a completar. Documenta quién es responsable del certificado, el método de renovación, el proveedor DNS, la ubicación del servicio, los nombres de host afectados y los pasos de reversión. Guarda esta información en un lugar al que pueda acceder el equipo de operaciones, no solo en la memoria de una persona.
En los servidores gestionados, la supervisión de certificados debería acompañar a las comprobaciones de disponibilidad, disco, copias de seguridad y servicios. Una fecha de vencimiento próxima es una señal operativa, no solo una tarea administrativa. En kodu.cloud, este tipo de mantenimiento recurrente encaja de forma natural con el soporte y la supervisión gestionados: identifica el punto de conexión con antelación, renueva con el método de validación adecuado y, después, confirma el estado del servicio activo.
Si tu certificado está a punto de vencer, empieza por comprobar qué se está sirviendo al público y luego revisa, desde fuera hacia dentro, el DNS, la validación y la configuración del servidor. Por lo general, hay una solución clara. Dedica tiempo suficiente a la renovación, verifícala desde fuera y tus visitantes solo notarán que el sitio sigue funcionando como debe.
Andres Saar, ingeniero de atención al cliente