Proteger web con SSL y backups suena a dos tareas separadas que se resuelven en paneles distintos. El problema aparece cuando las juntas y el backup contiene la clave privada del certificado. Un lector del foro de soporte de un hosting compartido lo describió con claridad: restauró un sitio desde una copia de seguridad y, al terminar, el navegador mostraba un aviso de certificado caducado. La copia había capturado el archivo del certificado, pero no su clave privada. El SSL nunca volvió a funcionar.
Ese es el punto exacto que separa una restauración limpia de un fin de semana perdido. Cifrar el tráfico y guardar copias no basta si la copia no es coherente con lo que se sirve después. Esta pieza va de ese fallo concreto y de cómo evitarlo sin depender de la suerte.
Por qué el backup rompe el SSL al restaurar
Un certificado SSL es un par de archivos: el público (el .crt o .pem que comparten los navegadores) y la clave privada (.key) que nunca debe salir del servidor. El primer archivo es inofensivo; el segundo es el que firma el handshake. Muchos scripts de backup incluyen el directorio de certificados completo sin distinguir entre ambos, y es ahí donde empieza el problema cuando se restaura en otro servidor o con otra configuración.
Hay dos escenarios típicos. En el primero, la copia incluye la clave privada y la restauración la sobrescribe con una versión antigua, de modo que el certificado renovado ya no coincide con la clave y el servidor devuelve errores de handshake. En el segundo, la copia excluye la clave privada por seguridad y, tras la restauración, el servidor arranca sin ella: el SSL falla y el sitio queda accesible solo por HTTP.
Proteger web con SSL y backups exige tratar el par de archivos como una unidad atómica. Si el backup no respeta esa unidad, la restauración es una lotería.
Qué debe contener una copia que respete el certificado
La copia debe capturar el certificado, la clave privada, la cadena intermedia y la configuración del servidor que indica dónde se cargan. En Apache es el bloque SSLCertificateFile y SSLCertificateKeyFile; en Nginx, las directivas ssl_certificate y ssl_certificate_key. Si el backup incluye los archivos pero no la configuración, restaurar en un servidor nuevo puede dejar el SSL apuntando a rutas que ya no existen.
La clave privada merece un trato aparte. Guardarla en el mismo backup que los archivos públicos multiplica el riesgo si esa copia acaba en un almacenamiento compartido. Una opción razonable es cifrar el backup con una contraseña que viva fuera del servidor, y documentar esa contraseña en un gestor de secretos. Otra es separar el backup de datos del backup de certificados, cada uno con su propio ciclo de vida.
Esto no funciona para certificados emitidos por Let’s Encrypt con renovación automática perpetua: si la copia restaura una clave privada antigua, el cliente de renovación puede fallar al intentar reemplazarla y dejar el sitio caído hasta la siguiente ejecución manual. En esos casos conviene excluir el directorio de Let’s Encrypt del backup y regenerar el certificado tras la restauración.
El orden de restauración importa más de lo que parece
Restaurar primero los archivos y luego el SSL es el orden habitual, y suele funcionar. Pero si la base de datos contiene URLs absolutas con https y el certificado aún no está activo, el sitio puede entrar en un bucle de redirecciones. En un caso real, un negocio local restauró su WordPress desde una copia nocturna y pasó dos horas depurando un bucle 301 que en realidad era el SSL sin activar. La solución fue restaurar el certificado antes de tocar la base de datos.
La recomendación práctica: verificar el estado del SSL con una comprobación externa antes de apuntar el dominio al servidor restaurado. Si el certificado no carga, no hay nada que probar en el CMS.
Checklist mínima antes de dar por buena una copia
Una copia que permita proteger web con SSL y backups sin sorpresas debería superar estas comprobaciones:
- El backup incluye certificado, clave privada y cadena intermedia en un único conjunto coherente.
- La configuración del servidor web está en la copia o versionada aparte.
- La restauración en un entorno de pruebas arranca el SSL sin errores de handshake.
- La fecha de caducidad del certificado restaurado no está vencida.
- La contraseña del backup cifrado está accesible fuera del servidor.
Ninguna de estas comprobaciones garantiza que el sitio esté a salvo de un ataque, pero evitan el fallo más común: descubrir que el SSL no funciona justo cuando el sitio ya está en producción.
Lo que el SSL no resuelve
Cifrar el tráfico no protege frente a una inyección SQL, un plugin vulnerable o un backup público en un bucket abierto. El SSL garantiza que la conexión entre el navegador y el servidor no se lee por el camino, y nada más. Los backups protegen frente a la pérdida de datos, no frente a la corrupción silenciosa si se copian datos ya dañados.
La combinación tiene sentido cuando cada pieza cumple su función y se prueba. El error no está en usar SSL o backups, sino en asumir que funcionan sin haber restaurado nunca.
Si gestionas un sitio pequeño, una prueba de restauración trimestral en un subdominio de staging vale más que cualquier panel de seguridad. Si gestionas varios sitios, automatiza esa prueba. Y si el backup no incluye la clave privada de forma coherente, no es un backup de SSL: es solo un montón de archivos con buena reputación.
Perfiles verificables: Sitio web
Publicado el 31 de October de 2026. Última revisión: 31 de October de 2026.