Cambiar de proveedor de hosting o mudar un sitio a un servidor nuevo tiene que ver sobre todo con archivos, bases de datos y DNS, y el certificado suele recordarse a último minuto. Entonces se hace el cambio de DNS y los visitantes ven una advertencia de certificado, o todo parece bien hasta que, unas semanas después, la renovación falla en silencio porque el servidor nuevo nunca se configuró para renovar. Saber cómo mover un certificado SSL a un servidor nuevo, y si hay que moverlo, mantiene HTTPS funcionando durante el cambio.

Dos formas de mover un certificado SSL a un servidor nuevo

Hay dos opciones, y para la mayoría de los sitios la primera es más sencilla.

  • Emitir un certificado nuevo en el servidor nuevo. Con una autoridad certificadora ACME como Let's Encrypt, el servidor nuevo solicita su propio certificado y configura su propia renovación. No se copia nada, y el certificado del servidor anterior simplemente vence.
  • Transferir un certificado SSL que ya tiene. Es el camino para un certificado de pago al que le queda tiempo, o cuando el servidor nuevo debe servir HTTPS antes de poder validar el dominio. Necesita tres piezas: el certificado, la cadena intermedia y la clave privada que les corresponde.

Un certificado está ligado a nombres de dominio, no a un servidor ni a una empresa de hosting, así que un certificado SSL al cambiar de hosting sigue siendo válido mientras su clave privada se mude con él. Sin la clave, el certificado es inútil, y ahí es donde fallan la mayoría de las transferencias: la clave se quedó en un servidor que ya se canceló. La mayoría de las autoridades certificadoras comerciales permiten reemitir con una clave nueva durante el período de validez, así que revise las condiciones de su autoridad si la clave anterior se perdió.

Manejo de la clave privada

Copie la clave por SSH o SFTP, nunca por correo electrónico ni chat, y déjela legible solo para root y el servidor web. En los servidores Windows, el certificado y la clave suelen viajar juntos en un archivo PFX protegido con contraseña, que solo puede exportarse si la clave se marcó como exportable al instalar el certificado.

El problema del cambio: validar antes de que se mueva el DNS

El desafío HTTP-01 de ACME demuestra el control de un dominio obteniendo un archivo por el puerto 80 desde el servidor al que el dominio apunta en ese momento. Antes del cambio de DNS ese sigue siendo el servidor anterior, así que el nuevo no puede obtener un certificado de esa forma. Hay tres soluciones limpias:

  • Validación DNS-01. El cliente demuestra el control creando un registro TXT, lo que funciona sin importar dónde esté alojado el sitio. La renovación automática necesita entonces acceso por API a su proveedor de DNS, y es la única manera de obtener un certificado comodín (wildcard) de Let's Encrypt.
  • Redirigir la ruta del desafío. La comprobación HTTP-01 de Let's Encrypt sigue las redirecciones, así que el servidor anterior puede reenviar al nuevo las solicitudes de /.well-known/acme-challenge/ durante la transición. La documentación de los tipos de desafío enumera las condiciones.
  • Cubrir el tramo con el certificado existente. Copie el certificado y la clave actuales al servidor nuevo durante los primeros días y cambie a la emisión automática cuando el DNS ya se haya movido.

Lista de verificación antes del cambio de DNS

  • Enumere todos los hostnames. El dominio principal, www, los subdominios de tienda o aplicación, el host de correo, la dirección del panel de control y cualquier endpoint de API. Todo nombre que el servidor nuevo atienda debe estar en un certificado.
  • Reduzca el TTL del DNS uno o dos días antes, para que el cambio se propague rápido y pueda revertirse rápido.
  • Revise el registro CAA. Un registro CAA en el DNS limita qué autoridades certificadoras pueden emitir para el dominio (RFC 8659). Si el nuevo hosting emite certificados mediante una autoridad distinta de la anterior, la emisión falla hasta que el registro lo permita.
  • Pruebe con una entrada en el archivo hosts. Apunte su propia computadora al servidor nuevo y cargue el sitio por HTTPS antes que nadie.
  • Sirva la cadena completa de certificados, no solo el certificado del sitio. Los navegadores a menudo toleran un intermedio ausente; las pasarelas de pago, los clientes de API y los dispositivos antiguos con frecuencia no.
  • Respete HSTS. Si el sitio anterior enviaba un encabezado HSTS, los navegadores que lo visitaron rechazarán HTTP sin cifrar y no dejarán que los visitantes pasen por alto los errores de certificado. El servidor nuevo debe servir HTTPS válido desde el primer minuto.
  • Deje las redirecciones en un solo salto desde cualquier variante http o www hasta la dirección HTTPS final.

Correo, paneles y el servidor anterior

Los sitios web se llevan la atención, pero los servidores de correo también necesitan certificados válidos para SMTP e IMAP, y un host de correo migrado con un certificado autofirmado o que no coincide dispara advertencias en todas las aplicaciones de correo. Lo mismo vale para la página de inicio de sesión de un panel de hosting y para los webhooks que los proveedores de pagos o envíos mandan a su sitio: llaman a una dirección HTTPS y se rinden si el certificado no se valida.

Cuando termine la mudanza, elimine las claves privadas del servidor anterior y detenga sus tareas de renovación, que de otro modo seguirán intentando y fallando. Si el hosting anterior fue comprometido, o ya no lo controla, revoque el certificado anterior y emita uno nuevo con una clave nueva. El resto de la mudanza, de los archivos a las bases de datos y los buzones, lo cubre nuestro servicio de migración de hosting y bases de datos.

Confirme la renovación en el servidor nuevo

El último paso previene la próxima caída. Ejecute una renovación de prueba, por ejemplo certbot renew --dry-run con Certbot, confirme que existe el temporizador o la tarea cron programados y asegúrese de que una renovación fallida genere una alerta. Los certificados públicos están ahora limitados a un máximo de 200 días y el límite sigue reduciéndose, como explica nuestra guía de certificados SSL, así que la renovación ocurre varias veces al año y no debe depender de que alguien se acuerde. Si contrata un servicio de instalación de SSL o un servicio de configuración de SSL para la mudanza, pida que esta prueba forme parte de la entrega. En nuestro trabajo de instalación de certificados SSL, la renovación se configura y se prueba, con una alerta si alguna vez falla.

Preguntas frecuentes: mover un certificado SSL a un servidor nuevo

¿Puede el mismo certificado SSL funcionar en dos servidores a la vez?

Sí. Durante una migración es normal que el servidor anterior y el nuevo usen el mismo certificado y la misma clave, y con certificados automatizados cada servidor puede tener también el suyo. Evite solicitar certificados idénticos en bucle durante las pruebas: Let's Encrypt permite cinco certificados para exactamente el mismo conjunto de nombres cada siete días, y su entorno de pruebas (staging) existe para los experimentos.

¿Debo comprar un certificado nuevo cuando cambio de empresa de hosting?

No, siempre que pueda llevar la clave privada o que su autoridad certificadora le permita reemitir. Muchos hostings también emiten certificados automatizados para los sitios que alojan, en cuyo caso un certificado de pago quizá ni siquiera necesite renovarse cuando venza.

¿Por qué el sitio muestra un error de certificado solo en algunos dispositivos después de la mudanza?

Normalmente el servidor nuevo envía el certificado del sitio sin su cadena intermedia, o el certificado no incluye uno de los hostnames que la gente realmente usa, como www. Un verificador TLS externo muestra ambos problemas en un minuto.

¿Va a mover un sitio web, un servidor de correo o una cuenta de hosting completa? Nuestro servicio de instalación y configuración de certificados SSL revisa la configuración actual, instala y configura certificados en Apache, Nginx, HAProxy, paneles de hosting y servidores de correo, limpia las redirecciones y el contenido mixto, y verifica el resultado, para clientes en Long Beach y Los Ángeles y de forma remota en cualquier lugar. Envíenos su nombre de dominio y la fecha prevista de la mudanza.