Un error de certificado SSL significa que el navegador no ha podido establecer una conexión segura de confianza, así que se detiene y muestra un aviso en lugar de tu web. Las causas más habituales son un certificado caducado (NET::ERR_CERT_DATE_INVALID), un certificado que no cubre el nombre de dominio (ERR_CERT_COMMON_NAME_INVALID), un certificado en el que el navegador no confía (ERR_CERT_AUTHORITY_INVALID) y un servidor que envía una cadena de certificados incompleta o usa una configuración TLS obsoleta. Casi todos se solucionan en el servidor, y el más frecuente, la caducidad, se puede evitar por completo.
Esta guía repasa los errores que ven realmente los visitantes, qué provoca cada uno y cómo solucionarlo, con comandos que puedes ejecutar para comprobar tu propia web.
Por qué los navegadores bloquean la página
Cuando un navegador se conecta por HTTPS, el servidor presenta un certificado. Antes de enviar nada, el navegador comprueba tres cosas: que el certificado está dentro de sus fechas de validez, que se emitió para el nombre de host exacto de la barra de direcciones y que su cadena lleva hasta una autoridad de certificación en la que el navegador confía. Si falla alguna, el navegador muestra un aviso a pantalla completa, como «La conexión no es privada». La mayoría de los visitantes se van en ese momento. Los clientes de API y las apps ni siquiera muestran un aviso: rechazan la conexión y tu integración deja de funcionar.
Cada navegador llama de forma distinta a los mismos problemas. Así se corresponden los errores habituales:
ProblemaChrome y EdgeFirefoxCaducado o todavía no válidoNET::ERR_CERT_DATE_INVALIDSEC_ERROR_EXPIRED_CERTIFICATENombre de host incorrectoNET::ERR_CERT_COMMON_NAME_INVALIDSSL_ERROR_BAD_CERT_DOMAINEmisor no fiable o autofirmadoNET::ERR_CERT_AUTHORITY_INVALIDSEC_ERROR_UNKNOWN_ISSUERProblema de protocolo o de cifradoERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCHSSL_ERROR_NO_CYPHER_OVERLAP
Safari muestra «Esta conexión no es privada» en la mayoría de estos casos, con los detalles en «Mostrar detalles».
Primero, revisa tú mismo el certificado
Antes de corregir nada, comprueba qué envía realmente el servidor. Este comando muestra las fechas de validez del certificado, el sujeto y los nombres de host que cubre:
echo | openssl s_client -connect northwind.shop:443 -servername northwind.shop 2>/dev/null \
| openssl x509 -noout -dates -subject -issuer -ext subjectAltName
La opción -servername es importante. Los servidores que alojan varias webs eligen el certificado según el nombre que pide el cliente, y sin ella puedes ver el que no es. Para ver la cadena completa que envía el servidor, añade -showcerts al primer comando.
NET::ERR_CERT_DATE_INVALID
El certificado está fuera de su periodo de validez. Casi siempre significa que ha caducado. Con menos frecuencia, el reloj del ordenador del visitante está mal, lo que hace que un certificado válido parezca caducado o todavía no válido.
Causas típicas en el lado del servidor:
La renovación automática dejó de funcionar tras una migración de servidor, un cambio de servidor web o un cambio de DNS que rompió la validación del dominio.
El certificado se renovó, pero el servidor web nunca se recargó, así que sigue sirviendo el antiguo desde la memoria.
El certificado se emitió a mano hace un año para un subdominio del que todos se olvidaron.
Un balanceador de carga, una CDN o un segundo servidor siguen teniendo el certificado antiguo mientras el servidor principal tiene el nuevo.
Solución: renueva el certificado, instálalo en todos los sitios donde se sirve y recarga el servicio. Con Certbot, una prueba en seco te dice si la renovación funciona antes de que importe:
sudo certbot renew –dry-run
sudo systemctl reload nginx
Después, vuelve a comprobar el certificado servido con el comando openssl de arriba. Lo que ven los visitantes no es el archivo del disco, sino el certificado servido.
Si solo un visitante informa del error y el certificado es válido, pídele que compruebe la fecha y la hora de su dispositivo.
NET::ERR_CERT_COMMON_NAME_INVALID
El certificado es válido, pero no para este nombre de host. Los navegadores comparan la barra de direcciones con los nombres que figuran en el campo Subject Alternative Name del certificado.
Causas habituales:
El certificado cubre northwind.shop pero no www.northwind.shop, o al revés.
Se usa un certificado wildcard para *.northwind.shop en shop.eu.northwind.shop. Un wildcard solo cubre un nivel.
Un subdominio nuevo se apuntó a un servidor que sirve un certificado por defecto de otra web.
Un registro DNS apunta al servidor equivocado, por ejemplo un hosting antiguo o una CDN que no tiene certificado para tu dominio.
Solución: emite un certificado que incluya todos los nombres de host que sirves, o uno distinto para cada nombre, y comprueba que cada bloque server o host virtual usa el correcto. Si el nombre de host no debería servirse, elimina su registro DNS.
NET::ERR_CERT_AUTHORITY_INVALID
El navegador no confía en quien firmó el certificado. Causas:
Un certificado autofirmado, a menudo un resto del entorno de staging o de la instalación por defecto de un panel de control.
Un certificado de una autoridad de certificación privada o interna usado en una web pública.
Una cadena incompleta en algunos clientes (ver más abajo).
Algo entre el visitante y el servidor que intercepta la conexión, como un proxy corporativo o un antivirus. En ese caso, solo algunos visitantes ven el error.
Solución: en las webs públicas, sustituye los certificados autofirmados e internos por uno de una autoridad de certificación de confianza pública. Los certificados gratuitos de Let’s Encrypt y servicios similares son de confianza en todos los navegadores principales.
Cadena de certificados incompleta
Tu certificado está firmado por un certificado intermedio, que a su vez está firmado por una raíz en la que confía el navegador. El servidor debe enviar tu certificado y el intermedio. Si solo envía el tuyo, el resultado depende del cliente: algunos navegadores de escritorio descargan por su cuenta el intermedio que falta y no muestran ningún error, mientras que otros navegadores, las apps móviles, curl y los clientes de API fallan. Por eso este problema suele aparecer como «a mí me funciona, pero los webhooks del proveedor de pagos fallan».
curl lo indica así:
curl: (60) SSL certificate problem: unable to get local issuer certificate
Solución: configura el servidor con el archivo de la cadena completa. Con Certbot en nginx, eso significa fullchain.pem, no cert.pem:
ssl_certificate /etc/letsencrypt/live/northwind.shop/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/northwind.shop/privkey.pem;
ERR_SSL_PROTOCOL_ERROR y discrepancias de cifrado
Estos errores significan que el navegador y el servidor no han podido ponerse de acuerdo sobre cómo comunicarse de forma segura, antes incluso de comprobar el certificado. Entre las causas: un servidor que solo ofrece versiones antiguas del protocolo, como TLS 1.0 y 1.1, que los navegadores actuales ya no aceptan; un puerto mal configurado que habla HTTP sin cifrar en el 443; una configuración TLS rota tras una actualización, o un firewall o proxy que interfiere en el handshake.
Solución: activa TLS 1.2 y TLS 1.3, usa los cifrados modernos por defecto de tu servidor web o de un generador de configuración de confianza y comprueba que el puerto 443 sirve realmente TLS. Puedes probar una versión concreta del protocolo con openssl:
openssl s_client -connect northwind.shop:443 -servername northwind.shop -tls1_2
Contenido mixto
El contenido mixto no es un error de certificado, pero los visitantes a menudo lo perciben como tal. La página se carga por HTTPS, pero algunos recursos, como scripts, imágenes, hojas de estilo o iframes, se piden por HTTP sin cifrar. Los navegadores bloquean directamente los scripts y frames inseguros, lo que puede romper el diseño o el funcionamiento, y pueden mostrar la página sin el indicador de seguridad habitual.
Solución: cambia las URL http:// escritas a mano en tus plantillas, base de datos y ajustes por https:// o por URL relativas. En WordPress, el contenido mixto suele venir de URL antiguas guardadas en el contenido de las entradas tras pasar a HTTPS. Como red de seguridad, la cabecera Content-Security-Policy: upgrade-insecure-requests indica a los navegadores que pidan esos recursos por HTTPS.
Para encontrar el contenido mixto antes que los visitantes, la monitorización de enlaces rotos de Uptimecheck rastrea tu web y su sitemap cada día e informa del contenido mixto y los enlaces rotos página por página.
Cómo evitar los errores de certificado
La mayoría de los errores de certificado son fallos de configuración que se corrigen una vez. La caducidad es distinta: vuelve cada vez que un certificado llega al final de su vida útil, y suele aparecer cuando la persona que configuró la renovación ya no está. La prevención es una rutina, no un arreglo puntual:
Mantén un inventario. Haz una lista de todos los nombres de host que sirven HTTPS, incluidas las API, los paneles de administración, el staging y las webs de clientes.
Automatiza la renovación siempre que puedas y ten claro dónde sigue siendo manual.
Comprueba el certificado servido después de cada cambio. Las migraciones de servidor, los nuevos balanceadores de carga y los cambios de DNS son los momentos en que fallan las renovaciones.
Monitoriza las fechas de caducidad para recibir un recordatorio semanas antes de que caduque un certificado, cuando aún hay tiempo para arreglar con calma una renovación que falla.
Vigila también el dominio y sus registros. Un dominio caducado o un registro DNS modificado rompen la validación y, con ella, la web.
La monitorización SSL de Uptimecheck controla la fecha de caducidad del certificado servido en cada dominio y subdominio que monitorizas por HTTPS y envía recordatorios a tus canales de alerta antes de que caduque. Está incluida en todos los planes. Combínala con la monitorización de la caducidad de dominios y la monitorización DNS, porque un certificado solo es tan fiable como el dominio y los registros que hay detrás. Nuestra guía sobre la monitorización de la caducidad de certificados SSL incluye una lista completa para la renovación, y si el navegador ni siquiera encuentra tu web, lee sobre DNS_PROBE_FINISHED_NXDOMAIN.
Resumen
Todo error SSL es el navegador negándose a confiar en una conexión: porque el certificado está caducado, se emitió para otro nombre, lo firmó alguien a quien no conoce, se envió sin su cadena o se ofrece con un protocolo que ya no acepta. Comprueba el certificado servido con openssl, corrige la configuración, recarga el servidor y vuelve a comprobarlo. Después, convierte la caducidad en un recordatorio en lugar de en un incidente.
Uptimecheck te avisa antes de que caduquen los certificados y los dominios, y te alerta cuando tu web deja de responder. Pruébalo gratis durante 14 días, sin tarjeta de crédito.