Una instalación de certificado SSL suele parecer terminada en cuanto aparece el candado en su propio navegador. Después, un cliente con un teléfono más viejo ve una advertencia, un proveedor de pagos rechaza un webhook o el certificado vence silenciosamente tres meses más tarde. La mayoría de estos problemas provienen de unos pocos errores repetibles. Esta guía explica cómo diagnosticar y corregir cada uno, ya sea que su sitio funcione en un VPS, en un panel de control o detrás de una CDN.

Cadena intermedia incompleta

Una autoridad de certificación firma su certificado con un certificado intermedio, que a su vez está firmado por una raíz de confianza. El servidor debe enviar su certificado junto con el intermedio. Si envía solo su certificado, los navegadores de escritorio suelen funcionar porque guardan en caché o descargan la pieza que falta, mientras que las aplicaciones móviles, los clientes de API y los dispositivos más viejos fallan.

Cómo diagnosticarlo

Use un verificador de SSL en línea o ejecute openssl s_client -connect example.com:443 -showcerts y cuente los certificados devueltos. Una cadena de certificados incompleta normalmente muestra un solo certificado o informa que no se pudo verificar al emisor.

Cómo corregirlo

  • En Nginx, apunte la directiva del certificado al archivo de la cadena completa, no al certificado individual.
  • En Apache, use el archivo de la cadena completa o configure la directiva del archivo de cadena en versiones más antiguas.
  • En un panel de control, pegue el paquete de la CA en el campo separado del intermedio.

Nombre no coincidente

Un error de nombre no coincidente significa que el nombre de host de la barra de direcciones no figura en el certificado. Las causas comunes son un certificado emitido para example.com pero no para www.example.com, un subdominio nuevo agregado después de emitir el certificado, o un servidor que envía el certificado predeterminado porque al host virtual de su dominio le falta una configuración SSL.

Revise los nombres alternativos del sujeto (Subject Alternative Names) del certificado y compárelos con todos los nombres de host que usa. Vuelva a emitir el certificado con todos los nombres incluidos y asegúrese de que cada host virtual HTTPS tenga definido su propio nombre de servidor, para que el servidor pueda elegir el certificado correcto mediante SNI.

Contenido mixto después de pasar a HTTPS

El contenido mixto ocurre cuando una página HTTPS carga imágenes, scripts u hojas de estilo por HTTP simple. Los navegadores bloquean por completo los scripts inseguros y pueden mostrar un candado roto por las imágenes. Los síntomas van desde un candado ausente hasta menús rotos y páginas de pago dañadas.

  • Abra la consola de desarrollador del navegador; allí aparece cada recurso bloqueado o inseguro.
  • Actualice la configuración de URL del sitio en su CMS para que los enlaces nuevos se generen con HTTPS.
  • Busque en la base de datos enlaces http:// escritos directamente en el contenido, la configuración del tema y los widgets, y reemplácelos con cuidado después de hacer una copia de seguridad.
  • Revise los elementos incrustados de terceros, las fuentes y los scripts de seguimiento, que a veces todavía hacen referencia a direcciones HTTP.

Un encabezado Content-Security-Policy con upgrade-insecure-requests puede cubrir los casos restantes, pero corrija las fuentes en lugar de depender solo de él.

Fallas en la renovación automática ACME

Los certificados gratuitos de Let's Encrypt duran 90 días y dependen de la renovación automática ACME. Cuando la renovación falla, nadie lo nota hasta que el sitio muestra una advertencia de vencimiento. Las causas típicas incluyen:

  • Desafío HTTP bloqueado: una regla de redirección, un firewall o una CDN impide que el servidor de validación llegue al archivo de desafío en /.well-known/acme-challenge/.
  • Cambios de DNS: el dominio ahora apunta a otro servidor o CDN, así que el desafío llega a otro lado.
  • Tarea de renovación dañada: la tarea de cron o el temporizador de systemd se eliminó durante una actualización del servidor, o el cliente se ejecuta pero el servidor web nunca se recarga.
  • Límites de frecuencia: los intentos fallidos repetidos durante las pruebas pueden bloquear temporalmente nuevas emisiones.

Ejecute una renovación de prueba para ver el error exacto, confirme que la ruta del desafío es accesible por HTTP simple y agregue un gancho de recarga para que el servidor web tome el nuevo certificado. Para los dominios detrás de una CDN, un desafío DNS suele ser más confiable. Configure un monitor de vencimiento para recibir un aviso semanas antes de que un certificado caduque.

Bucles de redirección detrás de proxies y CDN

Un bucle de redirección suele aparecer justo después de habilitar HTTPS en un sitio detrás de un proxy inverso, un balanceador de carga o una CDN. La CDN se conecta a su servidor por HTTP, el servidor redirige a HTTPS, la CDN reenvía la solicitud otra vez por HTTP y el ciclo se repite.

Cómo resolver el bucle

  • Configure la CDN para que se conecte al origen por HTTPS con un certificado válido en el servidor, en lugar del modo flexible.
  • Si el proxy termina el TLS, haga que la aplicación confíe en el encabezado X-Forwarded-Proto para que sepa que la solicitud original ya era segura.
  • Mantenga las redirecciones en un solo lugar. Tener una redirección en la CDN, otra en el servidor web y una tercera en el CMS invita a los bucles.

Una breve lista de verificación posterior a la instalación

  • Pruebe con un verificador de SSL externo, no solo con su navegador.
  • Verifique cada nombre de host, incluidos www y los nombres relacionados con el correo que utilice.
  • Escanee las páginas clave en busca de contenido mixto, sobre todo el proceso de pago y los formularios de contacto.
  • Ejecute una renovación de prueba y confirme que el monitoreo está activo.
  • Compruebe que HTTP redirige a HTTPS en un solo salto.

Si prefiere que nos encarguemos de esto, nuestro servicio de instalación y configuración de certificados SSL cubre certificados, cadenas, redirecciones y configuración de la renovación para sitios web de empresas en Long Beach y el condado de Los Ángeles.

Preguntas frecuentes sobre errores de SSL

¿Por qué mi sitio funciona en la computadora pero muestra un error de SSL en los teléfonos?

Es la señal clásica de que falta un certificado intermedio. Los navegadores de escritorio pueden llenar el vacío, mientras que los dispositivos móviles y las aplicaciones no. Instale la cadena completa.

¿Debo reinstalar el certificado después de la renovación?

No, si la renovación está bien automatizada. El cliente reemplaza los archivos y un gancho de recarga le indica al servidor web que los use. Si después de la renovación se sigue sirviendo el certificado viejo, falta el paso de recarga.

¿Es suficiente el SSL flexible en una CDN?

Solo cifra la conexión entre el visitante y la CDN. El tráfico hacia su servidor queda sin cifrar y los bucles de redirección son comunes, así que use cifrado completo con un certificado de origen válido.