Documentación

Entérese a tiempo de que un certificado va a caducar

Un certificado caducado deja una web tan fuera de servicio como un servidor caído: todos los navegadores rechazan la página y todos los clientes de API rechazan la conexión. Rara vez el error se comete ese mismo día: un proceso de renovación dejó de ejecutarse hace meses, un cambio de DNS rompió un desafío o el certificado nuevo llegó a un balanceador de carga y no al otro. Una comprobación TLS se lo dice mientras aún hay tiempo para arreglarlo.

Qué comprueba

En cada ejecución, la comprobación se conecta al host y al puerto que usted indique, completa un handshake TLS y evalúa lo que recibe:

Cuenta la caducidad más temprana de la cadena, no solo la del certificado del servidor: un intermedio que caduca antes deja la web caída en su propia fecha. La comprobación de confianza usa solo los certificados que envía el servidor. Los navegadores de escritorio a veces reparan un intermedio que falta desde su caché, pero los clientes de API, las herramientas de línea de comandos y los móviles antiguos no, y son precisamente los clientes cuyos fallos no le llegarían.

Un servidor puede tener dos certificados, normalmente uno ECDSA y otro RSA, y presenta el RSA solo a los clientes que no admiten ECDSA. La prueba diaria de configuración pide cada tipo, y cada certificado que recibe se comprueba como el principal: validez, confianza, nombre y caducidad, en cada ejecución. Un hallazgo sobre cualquiera de ellos indica de qué certificado se trata. Un servidor que solo habla TLS 1.3 cifra sus certificados, así que un segundo certificado queda oculto, y el resultado lo indica.

Cada resultado registra lo que presentó el servidor, también cuando una comprobación falla: sujeto, emisor, nombres, clave, fechas de caducidad y los pines de clave que una app puede usar para fijar el certificado.

Revocación, Certificate Transparency y CAA

La revocación se comprueba para el certificado del servidor, con una respuesta que el servidor grapa al handshake o, si no, con la lista de revocación o el respondedor OCSP de la CA. Solo cuenta una respuesta firmada por la CA emisora y vigente; cualquier otra se considera desconocida, y una respuesta desconocida nunca hace fallar una comprobación, porque que el servidor de una CA no responda no significa que su web esté caída.

Certificate Transparency sigue las reglas que aplica Chrome: un certificado de confianza pública debe llevar pruebas de logs públicos independientes. Los certificados de su propia autoridad están exentos, como en los navegadores.

Los registros CAA indican qué CA pueden emitir certificados para un dominio. Si ya no incluyen la CA del certificado actual, la comprobación avisa: el certificado sigue funcionando, pero su renovación será rechazada. Un nombre sin registros CAA se anota en el resultado sin cambiar su estado.

Fijación de claves para apps móviles

Una app que fija claves rechaza un servidor cuya cadena ya no lleva ninguna de ellas, mientras todos los navegadores siguen funcionando, y el fallo le llega por las reseñas de la app. Indique los mismos pines en la comprobación, en el formato de las apps (sha256/ y el hash de la clave), y una renovación que cambió la clave fallará aquí primero. Cada resultado muestra los pines de la cadena vista, listos para copiar.

Cuando cambia el certificado

Cada comprobación recuerda los certificados que se le sirvieron en los últimos 30 días. Cuando una ubicación recibe uno que la comprobación no ha visto en ese tiempo, registra el cambio y, por defecto, le avisa si parece inesperado: el nuevo certificado lo emitió otra organización, cubre menos nombres o tiene una clave más débil que el que sustituye, o la calificación con candados del servidor ha bajado con él. Una renovación habitual por la misma CA no genera aviso, salvo que usted elija recibir uno por cada certificado nuevo; también puede desactivar estos avisos. Comparar con los últimos 30 días y no con el último resultado evita que una CDN, cuyos nodos sirven certificados distintos, dé lugar a un aviso de cambio en cada ejecución.

El aviso llega a las suscripciones con el disparador «Certificado cambiado», por correo, webhook o en la app, e indica la ubicación y ambos certificados.

Los valores por defecto y por qué

Una comprobación TLS nueva avisa 14 días antes de la caducidad y falla 3 días antes. La renovación automática suele ocurrir con alrededor de un tercio de la vigencia por delante, así que a 14 días la renovación ya va con retraso, y 3 días en fallo dejan tiempo para hacerla a mano. Ambos valores son por comprobación, de modo que un certificado de una autoridad interna con ciclo anual puede tener los suyos.

La comprobación se ejecuta cada 6 horas y sus ubicaciones se turnan: con cuatro ubicaciones, cada una comprueba una vez al día. Lo que encuentra una comprobación TLS cambia en horas y días, no en segundos. Saber si la web está disponible es tarea de una comprobación HTTP cada pocos minutos, y conviene tener las dos.

Cuando el servidor no responde

Si tres intentos no obtienen respuesta, el resultado queda como desconocido, con el motivo. No evalúa el certificado y nunca convierte un fallo anterior en un resultado correcto: una ubicación que vio por última vez un certificado caducado sigue en fallo hasta que ve uno válido.

Otros puertos y certificados internos

Se puede comprobar cualquier puerto que empiece directamente en TLS, como el 465 o el 993 para correo. Si el host es una dirección IP o sirve varios nombres, indique como nombre del servidor el que debe cubrir el certificado. Para un certificado de su propia autoridad, desactive la verificación de la cadena: la caducidad y el nombre de host se siguen comprobando. Las comprobaciones HTTP descritas más abajo se ejecutan por defecto solo en el puerto 443; la configuración de la comprobación permite activarlas para HTTPS en otro puerto o desactivarlas.

Cabeceras HTTP

En el puerto 443, la prueba diaria de configuración también lee las cabeceras HTTP que protegen HTTPS: Strict-Transport-Security, la redirección desde el puerto 80 y el atributo Secure de las cookies. Un HSTS ausente o demasiado corto cuenta como desviación de las directrices de Mozilla, igual que cualquier otro hallazgo de configuración; los demás se registran y cuentan para el quinto candado de la calificación. Los valores de las cookies y los destinos de las redirecciones nunca se guardan.

Qué envían nuestras comprobaciones

Una comprobación TLS es una conexión de cliente corriente, como la de un navegador. Lee lo que presenta el servidor y cierra. Una vez al día por servidor y ubicación también prueba la configuración del servidor con hasta 60 conexiones de prueba breves y, en el puerto 443, pide la página de inicio una vez por HTTPS y otra por HTTP sin cifrar en el puerto 80; solo lee las cabeceras y no sigue ninguna redirección. Nuestra página para operadores de servidores indica las direcciones desde las que llegan las comprobaciones: https://pingsured.eu/bot