Errores SSL: qué son y cómo solucionarlos

Un error SSL es lo que muestra un navegador cuando no puede abrir una conexión cifrada de confianza con un sitio web. En lugar de la página que solicitaste, obtienes una pantalla de advertencia y un código breve en mayúsculas pequeñas, algo como NET::ERR_CERT_AUTHORITY_INVALID o SSL_ERROR_NO_CYPHER_OVERLAP.

Ese código es la parte útil, y la mayoría de las guías lo pasan por alto. «Error SSL» no es un término técnico, y ningún estándar define uno. Es el nombre coloquial de toda una familia de fallos diferentes, y por eso un consejo genérico como borrar la caché soluciona algunos y no hace absolutamente nada con el resto.

Qué es realmente un error SSL

Cuando cargas una dirección que empieza por https://, tu navegador y el servidor realizan una breve negociación llamada handshake TLS antes de que se transfiera ningún contenido de la página. El handshake acuerda una versión de protocolo y un conjunto de algoritmos de cifrado, y el servidor demuestra su identidad con un certificado. Si alguna parte de eso falla, el navegador se niega a continuar y muestra un error en lugar de la página.

Vale la pena diferenciar SSL de TLS aquí, porque la nomenclatura causa confusión real. SSL es el protocolo original, y cada versión de él ha quedado obsoleta desde hace años. Lo que tu navegador realmente utiliza es TLS. La palabra «SSL» sobrevive en nombres de productos, en directivas de configuración y en códigos de error, por eso todavía la ves en todas partes. Cuando una página o un navegador dice SSL, casi siempre se refiere a TLS.

Esto es importante para la resolución de problemas porque la definición popular de un error SSL es demasiado limitada. A menudo leerás que un error SSL significa que el navegador no pudo verificar el certificado del sitio. Eso es cierto para un grupo de estos errores y falso para el resto. Un servidor que responde en el puerto HTTPS con texto plano sin cifrar produce un error SSL y nunca envía ningún certificado. Dos máquinas que no logran ponerse de acuerdo en un conjunto de cifrado producen uno antes incluso de que se examine el certificado. Empezar por el certificado cuando el certificado nunca fue el problema es la razón más común por la que la gente pasa horas en una solución de cinco minutos.

Qué etapa de la conexión falló

Toda conexión HTTPS sigue la misma secuencia, y un error SSL es simplemente el punto en el que esa secuencia se detuvo. Determinar la etapa reduce de inmediato la causa, porque cada etapa tiene un conjunto de explicaciones completamente distinto.

1. La conexión nunca llegó a ser TLS. Tu navegador abrió una conexión y lo que recibió de vuelta no era TLS, o el otro extremo cerró la conexión antes de que terminara el handshake. No hay ningún certificado involucrado, y no hace falta sustituir ninguno.
2. El handshake falló durante la negociación. Ambos extremos hablaban TLS pero no pudieron acordar una versión de protocolo, un conjunto de cifrado, o qué sitio se estaba solicitando. El handshake se detiene antes de validar el certificado, y a menudo antes incluso de que se envíe.
3. El certificado se recibió y fue rechazado. Este es el grupo al que la gente se refiere cuando dice «error SSL». La caducidad, la cobertura del nombre de host, la cadena de confianza, la revocación y la fortaleza de la firma se encuentran aquí.
4. El handshake tuvo éxito y algo posterior falló. La conexión cifrada se estableció correctamente, y luego una capa posterior se rompió. El certificado ya se confirma como válido en este punto, así que sustituirlo no cambia nada.

No necesitas adivinar en qué etapa te encuentras. El código de error te lo indica, y la siguiente sección relaciona cada código con su etapa.

Encuentra tu error

Lee el código que aparece debajo del mensaje de advertencia. En Chrome y Edge se encuentra en mayúsculas pequeñas debajo de «Tu conexión no es privada». En Firefox puede que necesites abrir los detalles avanzados en la página de advertencia. Después búscalo a continuación.

Etapa 1: la conexión nunca llegó a ser TLS

• SSL_ERROR_RX_RECORD_TOO_LONG en Firefox significa que el servidor respondió a una solicitud HTTPS con algo que no es TLS, casi siempre HTTP plano servido en el puerto 443. Es un problema de configuración del servidor.
• PR_END_OF_FILE_ERROR en Firefox significa que el otro extremo cerró la conexión antes de que se completara el handshake. La causa suele estar entre tú y el servidor, en lugar de en cualquiera de los dos extremos.

Etapa 2: el handshake falló durante la negociación

• ERR_SSL_PROTOCOL_ERROR es el código genérico de Chrome para un handshake que falló por una razón que no pudo identificar con precisión. Empieza por aquí si tu código es este, porque la primera tarea es acotarlo.
• SSL_ERROR_NO_CYPHER_OVERLAP es el equivalente de Firefox, e igualmente amplio: aparece ante cualquier fallo fatal de handshake que reporte el servidor, sea cual sea la razón real del servidor.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH es el código de Chrome para la misma clase de fallo, que se genera para una lista corta y específica de condiciones de negociación.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT significa que el servidor terminó el handshake a propósito porque el nombre de host solicitado no coincide con ningún sitio configurado en él. No se envía ningún certificado, así que el certificado no es el culpable.
• ERR_BAD_SSL_CLIENT_AUTH_CERT funciona en dirección contraria a todos los demás errores aquí: el sitio pidió a tu navegador un certificado y rechazó el que recibió, o no recibió ninguno. Este sí se soluciona en tu propia máquina.
• El error 525 de Cloudflare es un fallo de handshake en un tramo diferente del recorrido: entre Cloudflare y el servidor de origen detrás de él, no entre tu navegador y Cloudflare. Los visitantes no pueden hacer nada al respecto.

Etapa 3: el certificado se recibió y fue rechazado

Tu conexión no es privada es la pantalla de advertencia de Chrome para todo este grupo, más que una causa en sí misma, así que si eso es todo lo que tienes, lee primero el código que aparece debajo.

No se pudo construir la cadena de confianza. El navegador no pudo enlazar el certificado del sitio con una raíz en la que confía, generalmente porque el servidor envía su propio certificado y omite el certificado intermedio superior.

• NET::ERR_CERT_AUTHORITY_INVALID en Chrome y Edge.
• SEC_ERROR_UNKNOWN_ISSUER en Firefox, la misma condición con otro nombre.
• Un certificado intermedio caducado, donde la cadena existe pero un eslabón por encima de ti se ha agotado.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, donde no hay cadena porque el certificado se firmó a sí mismo.

Las fechas o el nombre no coinciden. El certificado es de confianza pero no se aplica a este momento o a este nombre de host.

• NET::ERR_CERT_DATE_INVALID, donde el certificado ha caducado o todavía no es válido. Vale la pena saber que un reloj incorrecto en tu propio dispositivo también produce esto.
• NET::ERR_CERT_COMMON_NAME_INVALID, donde el nombre de host no aparece en el certificado.
• DLG_FLAGS_SEC_CERT_CN_INVALID, el mismo problema de nombre de host reportado por software construido sobre la antigua pila web de Windows, principalmente el modo Internet Explorer en Edge y aplicaciones empresariales.

El certificado es de confianza y está vigente, pero no está permitido por otra razón.

• NET::ERR_CERT_REVOKED, donde la autoridad certificadora lo canceló antes de su fecha de caducidad.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, donde el certificado no llegó con suficiente prueba pública de emisión.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, donde algo en la cadena está firmado con SHA-1. Las versiones actuales de Chrome pueden reportar el mismo certificado bajo un código diferente, pero la condición y la solución no cambian.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, una colisión dentro del propio almacén de certificados de Firefox, más que un fallo en la conexión.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, que se aplica a un conjunto muy pequeño de dominios integrados en el navegador, así que un sitio web ordinario no puede producirlo.

El propio archivo del certificado está mal. Estos dos se encuentran en el servidor en lugar de en un navegador, y normalmente impiden por completo que un sitio sirva HTTPS.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, donde el navegador no pudo decodificar el certificado que envió el servidor.
• Un desajuste de módulo, donde el certificado instalado no pertenece a la clave privada instalada.

Etapa 4: el handshake tuvo éxito y algo posterior falló

Estos se clasifican como errores SSL por costumbre. En cada caso la conexión cifrada ya funcionaba, así que el certificado se ha validado con éxito y volver a emitirlo no ayudará.

• ERR_SSL_BAD_RECORD_MAC_ALERT significa que el servidor recibió datos cifrados que no pudo verificar, algo que ocurre después del handshake bajo las claves de sesión. Algo en la ruta está corrompiendo o reescribiendo el tráfico.
• ERR_QUIC_PROTOCOL_ERROR es un fallo de QUIC, el transporte que subyace a HTTP/3. No es un problema de certificado, y la causa habitual es un firewall o VPN filtrando UDP.
• ERR_SPDY_PROTOCOL_ERROR es un fallo en la capa HTTP/2, que se sitúa por encima de un handshake TLS ya completado.
• El contenido mixto es la excepción: la página se cargó perfectamente por HTTPS, y después solicitó un recurso por HTTP plano. No produce ninguna página de error, solo un candado degradado y scripts o imágenes que faltan.

Errores que llevan el nombre de un dispositivo en lugar de una etapa

Dos plataformas producen suficientes peculiaridades propias como para tratarlas por separado, porque la misma condición subyacente se comporta de forma diferente en ellas.

• Errores SSL en iPhone y iPad, incluido el mensaje «Se ha producido un error SSL y no se puede establecer una conexión segura con el servidor». La configuración de fecha y hora es lo primero que hay que revisar.
• Errores de conexión SSL en Android, donde Chrome y otras aplicaciones consultan almacenes de confianza diferentes, y un certificado intermedio ausente causa más problemas que en un escritorio.

Códigos que ya no aparecen

Tres códigos todavía se documentan ampliamente pero se han eliminado de los navegadores que los producían, así que si estás leyendo consejos sobre uno de ellos, revisa la fecha. Las condiciones detrás de dos de ellos todavía existen bajo otros nombres.

• NET::ERR_CERT_SYMANTEC_LEGACY se eliminó en Chrome 136, publicado en abril de 2025.
• ERR_SSL_VERSION_INTERFERENCE se eliminó en Chrome 76 en 2019, aunque la interferencia que describía todavía ocurre y ahora se manifiesta de otra manera.
• ERR_SPDY_PROTOCOL_ERROR se renombró como ERR_HTTP2_PROTOCOL_ERROR en Chrome 77, también en 2019. El fallo que describe sigue vigente, por eso se incluye en la etapa cuatro anterior.

Si estás visitando el sitio

La mayoría de los errores SSL son responsabilidad del sitio web, y ninguna cantidad de trabajo en tu propio dispositivo los cambiará. Hay una lista corta de excepciones genuinas, y vale la pena revisarla antes de concluir que el sitio está roto.

• Revisa tu reloj. La validación de certificados compara las fechas del certificado con la hora propia de tu dispositivo. Un reloj que está desajustado por meses o años hace que todos los certificados parezcan inválidos, y esta es la causa más común del lado del visitante.
• Prueba una segunda red. Cambiar de Wi-Fi a datos móviles, o viceversa, te dice en segundos si algo en la red está interceptando el tráfico. El Wi-Fi público y de hoteles son culpables frecuentes.
• Desactiva temporalmente el escaneo de HTTPS. Los productos antivirus y los proxies corporativos inspeccionan el tráfico cifrado sustituyendo sus propios certificados. Cuando lo hacen mal, obtienes un error SSL en sitios que funcionan bien en otros lugares.
• Prueba una ventana privada y otro navegador. Si el error aparece en un navegador y no en otro, la causa suele ser local, en una extensión o en datos almacenados. Si aparece en todos, es el sitio.

Si nada de eso ayuda, el problema está en el servidor y la respuesta honesta es que no puedes solucionarlo. Eso se aplica por completo al error 525 de Cloudflare, donde el fallo ocurre en una conexión de la que tu navegador no forma parte.

Los navegadores sí ofrecen una forma de continuar más allá de la mayoría de las advertencias de certificado, y vale la pena tener claro qué cuesta eso. Continuar le indica al navegador que acepte una conexión cuya identidad no pudo verificar, lo que significa que no tienes ninguna garantía de estar hablando con el sitio que escribiste en lugar de con algo intermedio. Eso es un intercambio aceptable en un servidor de pruebas que controlas. No es aceptable en nada donde vayas a introducir una contraseña o un dato de pago. Algunos errores no ofrecen ninguna forma de continuar, y eso es deliberado, no un fallo.

Si administras el sitio web

Diagnostica antes de cambiar nada. Reinstalar un certificado que nunca fue el problema es la forma habitual en que una hora se convierte en una tarde.

Empieza con una comprobación externa

Ejecuta el dominio a través de nuestro SSL Checker. Informa lo que el servidor realmente está enviando al exterior, que con frecuencia no coincide con lo que está en el archivo de configuración. Una cadena que parece completa en el disco pero que llega incompleta al navegador es el hallazgo más común, y es la causa detrás tanto de NET::ERR_CERT_AUTHORITY_INVALID como de SEC_ERROR_UNKNOWN_ISSUER.

Puedes ver lo mismo desde la línea de comandos. Esto imprime todos los certificados que ofrece el servidor, en el orden en que los ofrece:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Lee la lista de certificados de esa salida, no la línea Verify return code del final. Esa línea es mucho menos informativa de lo que parece: solo informa del veredicto de OpenSSL sobre la cadena, ignora el nombre de host a menos que solicites explícitamente esa comprobación, e imprime 0 (ok) incluso cuando el servidor no envió ningún certificado porque el handshake se abortó. Si la salida dice no peer certificate available en lugar de mostrar una línea subject=, no se verificó nada y el fallo ocurrió antes.

Revisa las fechas y el nombre de host

Estos dos representan una gran parte de los rechazos de certificados. Para leer la ventana de validez del certificado que el servidor está sirviendo:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Los navegadores comparan el nombre de host con la extensión subjectAltName e ignoran por completo el Common Name, así que ese es el campo a inspeccionar en un archivo de certificado local:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Para que OpenSSL aplique la misma comprobación de nombre de host que aplica un navegador, añade el indicador en lugar de asumir que un resultado limpio ya lo cubre:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

En macOS estos comandos requieren atención. El openssl que viene con macOS es LibreSSL, y rechaza -verify_hostname directamente e informa de un resultado saludable en algunas cadenas realmente rotas. Instala OpenSSL a través de Homebrew, y luego ejecuta openssl version de nuevo para confirmar qué binario estás llamando realmente. Si sigue reportando LibreSSL, tu PATH está encontrando primero la copia del sistema, así que llama a /opt/homebrew/bin/openssl por su ruta completa.

Luego soluciona y verifica

Lo que hay que cambiar depende de la etapa, y las guías individuales enlazadas anteriormente contienen los pasos específicos de cada plataforma. Tres soluciones cubren la mayoría de los casos:

• Sirve la cadena completa. Concatena tu certificado y los certificados intermedios que suministró tu autoridad certificadora en el archivo al que apunta tu servidor. No pongas la clave privada en ese archivo.
• Renueva antes de la caducidad, y automatízalo. Los tiempos de vida de los certificados se están reduciendo, así que cualquier cosa renovada manualmente terminará renovándose tarde en algún momento. La automatización con ACME elimina esa fecha límite.
• Cubre cada nombre de host que realmente sirves. Un certificado para un dominio no cubre sus subdominios a menos que sea un comodín o los incluya explícitamente.

Prueba siempre la configuración antes de reiniciar el servicio, y vuelve a ejecutar el verificador después desde fuera de tu propia red. Una solución confirmada solo en el navegador con el que has estado probando no está realmente confirmada, porque ese navegador puede estar reteniendo un resultado en caché.

Cómo prevenir los errores SSL

Casi todos los errores SSL en un sitio web que funciona provienen de una de tres cosas: un certificado que caducó, una cadena que nunca estuvo completa, o una configuración que se fue desviando. Las tres son evitables.

• Automatiza la renovación. Los tiempos de vida máximos de los certificados se están reduciendo en etapas durante los próximos años, y la renovación manual deja de ser práctica bastante antes del final de ese proceso. Automatiza ahora en lugar de cuando se rompa.
• Supervisa la caducidad de forma independiente. Un recordatorio de calendario falla cuando la persona se va. Una comprobación externa que te avisa con semanas de antelación no falla.
• Vuelve a comprobar después de cada cambio. Las migraciones de servidor, los cambios de CDN y las actualizaciones del panel de control reescriben silenciosamente la configuración del certificado. Verifica desde fuera después de cualquiera de ellos.
• Prueba en un teléfono, no solo en un escritorio. Las plataformas móviles son más estrictas con las cadenas incompletas, así que un problema de cadena a menudo se muestra en un teléfono mientras el escritorio parece estar bien.
• Instala correctamente desde el principio. Nuestros tutoriales de instalación cubren los pasos de cadena y vinculación por plataforma, y la mayoría de los errores de cadena se originan en el momento de la instalación.

Preguntas frecuentes