"Tu conexión no es privada": cuál de las cinco es, y de quién es el equipo que falla

Una sola pantalla roja de advertencia cubre al menos cinco fallos que no tienen nada que ver entre sí. Esa es toda la dificultad de “Tu conexión no es privada”: la página que ve el usuario es idéntica tanto si su certificado caducó anoche, como si el portátil de esa persona cree que estamos en 2019, o si su empresa está leyendo su tráfico.

La pantalla oculta lo único que permite distinguirlos, y está detrás del enlace Avanzado: un código que empieza por NET::ERR_CERT_. Todo lo útil está en ese código, y casi ningún reporte de errores lo incluye.

Qué hace el navegador en realidad

Antes de que salga cualquier solicitud, el navegador comprueba el certificado que presentó el servidor. Tres de esas comprobaciones fallan con la frecuencia suficiente como para tener su propio código de error, y la propia lista de errores de red de Chromium describe cada uno en una línea.

ERR_CERT_COMMON_NAME_INVALID es, en palabras de Chromium, “El servidor respondió con un certificado cuyo nombre común no coincidía con el nombre de host”. El certificado es real y válido, pero para otro nombre. Alguien accedió a www.example.com cuando el certificado cubre example.com, o una dirección IP sin más, o un host de staging que nunca se añadió a la lista de nombres.

ERR_CERT_DATE_INVALID es el interesante, y merece leerse dos veces: “El servidor respondió con un certificado que, según nuestro reloj, parece no ser válido todavía o haber caducado”.

Según nuestro reloj. El navegador compara las fechas del certificado con el reloj del equipo en el que se ejecuta. Un certificado perfectamente válido puede fallar esta comprobación en un dispositivo cuyo reloj esté mal, y un dispositivo con el reloj mal ajustado no es algo raro: un portátil que vuelve de meses guardado en un cajón, un teléfono que perdió la sincronización horaria, una máquina virtual reanudada desde una instantánea, un equipo de escritorio en el que alguien puso la fecha a mano. La misma página carga para usted y se rechaza para esa persona, y nada en el error indica de quién es el reloj equivocado.

ERR_CERT_AUTHORITY_INVALID es “El servidor respondió con un certificado firmado por una autoridad en la que no confiamos”. Tres situaciones muy distintas lo producen, y merece la pena diferenciarlas, algo que hacemos a continuación.

ERR_CERT_REVOKED es “El servidor respondió con un certificado que ha sido revocado”. Alguien lo retiró antes de su caducidad, normalmente porque se filtró una clave. Este caso sí es responsabilidad suya, y además urgente.

Los números también son estables, por si termina leyendo registros en vez de pantallas: -200, -201, -202 y -206 respectivamente.

Tres de las cinco causas no son de su servidor

Esta es la parte que convierte un error de certificado en un problema de reportes de errores más que en un problema operativo.

El reloj. Ya lo hemos visto. Su certificado está bien. El dispositivo de esa persona no está de acuerdo sobre qué día es. Usted no puede reproducir esto, no puede arreglarlo desde su lado, y ninguna cantidad de redespliegues lo va a cambiar.

La red está leyendo su tráfico. Un proxy corporativo, algunos productos antivirus y la mayoría de los portales cautivos de wifi pública funcionan presentando su propio certificado para cada sitio y firmándolo con una raíz que instalan en el equipo. Cuando eso funciona, el usuario no ve nada. Cuando la raíz no está instalada, o el dispositivo no es de la empresa, todos los sitios de esa red muestran ERR_CERT_AUTHORITY_INVALID. La señal reveladora es que el fallo sigue a la red y no al sitio: la misma persona con datos móviles no tiene problema.

El intermedio que falta. Un certificado se confía a través de una cadena: el suyo está firmado por un intermedio, que a su vez está firmado por una raíz en la que el navegador ya confía. Se supone que su servidor debe enviar el intermedio junto con su propio certificado. Si no lo hace, algunos visitantes no notan nada de todos modos, porque su navegador ya tiene ese intermedio de otra parte o lo obtiene al momento, y otros visitantes reciben ERR_CERT_AUTHORITY_INVALID.

Este último merece una frase aparte, porque es el problema de configuración peor diagnosticado de la web: una cadena a la que le falta el intermedio funciona en el equipo de la persona que la configuró, y falla para una fracción de desconocidos. Es, de verdad, culpa de su servidor, y su propio navegador es el peor instrumento posible para detectarlo.

Débil

Un cliente dice que el sitio no es seguro. Comprobado en Chrome y Safari aquí, el candado está bien. Le dijimos que borrara la caché.

Mejor

NET::ERR_CERT_AUTHORITY_INVALID, solo en su wifi de oficina, funciona con datos móviles. Aquí la misma página va bien. Proxy o intermedio faltante, comprobamos la cadena desde fuera antes de culpar a su red.

Distinguirlos en un minuto

El código lo reduce a una de tres causas. Tres preguntas terminan el trabajo.

¿Qué hora cree el dispositivo que es? Pida la hora, no la fecha. En algunas cosas los minutos importan; en esta, ir desfasado un año es el caso habitual y resulta evidente en cuanto se mira. Si el reloj está mal, ERR_CERT_DATE_INVALID queda explicado y no hace falta investigar nada más. Un reloj de dispositivo que va mal por meses sin que nadie lo note también explica por qué “se rompió sobre las tres” puede llevarle a la hora equivocada de sus registros, así que conviene tenerlo presente más allá de este error. La guía de reportes de errores incluye el entorno en la plantilla por el mismo motivo.

¿Sigue a la red o al sitio? Una sola pregunta: ¿ocurre con datos móviles? Un problema de certificado que desaparece en cuanto el usuario sale de la wifi es la red presentando su propio certificado, y la solución está de su lado o del departamento de informática correspondiente.

¿Ocurre para alguien fuera de su oficina? Compruebe la cadena desde un equipo que nunca haya visitado su sitio, que es justo lo que hace un verificador SSL externo: se conecta desde cero e informa de lo que su servidor envía realmente, en lugar de lo que su navegador ha aprendido a rellenar por su cuenta. Si informa de un intermedio faltante, el problema está en su despliegue, y probablemente lleva roto para una parte de los visitantes desde la última renovación del certificado.

La renovación que funcionó a medias

Merece la pena conocer este patrón, porque produce la versión más confusa de todo esto.

Hoy en día los certificados se renuevan de forma automática, y una renovación que instala el certificado nuevo pero no el intermedio nuevo, o que recarga un proceso y no otro, deja un servidor que es correcto desde algunos ángulos y erróneo desde otros. Los usuarios que pasan por un balanceador de carga llegan al azar al nodo corregido o al desactualizado. La mitad de los reportes dicen que está roto, la otra mitad dice que va bien, y las dos mitades dicen la verdad: se pierde una hora buscando un patrón en los usuarios cuando el patrón está en los servidores.

La salida es dejar de probar desde un navegador que puede estar ayudándole sin que se dé cuenta. Pruebe el endpoint desde fuera, repetidamente.

Lo que quien reporta puede enviarle en realidad

Este es el límite honesto, y nos afecta tanto a nosotros como a cualquiera. Una advertencia de certificado significa que la página nunca llegó a cargar. No hay consola, no hay registro de red, y no hay nada que una herramienta de captura pueda registrar, porque el navegador se negó antes de que su sitio llegara a ejecutarse. Lo que normalmente usa para ver un fallo con los ojos de otra persona no está disponible en este caso.

Así que todo se reduce a preguntar, y a preguntar por las tres cosas correctas:

• El código, el que está detrás de Avanzado, completo. NET::ERR_CERT_AUTHORITY_INVALID, no “una advertencia de seguridad”.
• La fecha y la hora en su dispositivo, leídas directamente de su propio reloj.
• La red, y si los datos móviles se comportan de otra manera.

Con esas tres respuestas, la causa suele quedar resuelta antes de que nadie haya mirado un servidor. Es una tasa de acierto mejor que la que ofrecen la mayoría de los errores, y solo está disponible porque el navegador ya hizo el diagnóstico y lo dejó detrás de un enlace que nadie pulsa.

Una cosa que no debe decirles: que hagan clic para saltarse la advertencia. Es el reflejo, el botón está justo ahí, y en una interceptación real eso entrega el tráfico a quien esté interceptándolo. Si la causa es el reloj, arreglar el reloj lleva los mismos treinta segundos y deja la comprobación funcionando para el siguiente sitio.

Qué sacar de todo esto

La pantalla roja es una categoría, no un diagnóstico. El código bajo Avanzado es el diagnóstico, y viene gratis con cada aparición.

Tres de las causas viven en el equipo del usuario o en su red, así que reproducirlas en el suyo es imposible por construcción, y la única que es de verdad culpa suya, el intermedio faltante, es la que menos probable es que su propio navegador le muestre. Las dos mitades de eso apuntan en la misma dirección: ante errores de certificado, pida el código y pruebe desde fuera, en ese orden.

La propia lista de estos errores de Chromium, con la definición de una línea de cada uno, es net_error_list.h. Es la fuente a partir de la cual se generan las páginas de error, y zanja discusiones más rápido de lo que puede hacerlo cualquier artículo.