Inspector de certificados TLS

Para qué sirve un certificado

Cuando tu navegador se conecta a https://example.com, algo responde. Que ese algo pertenezca a example.com es otra cuestión. Cualquiera situado en la red por el camino podría haber contestado en su lugar.

Por eso el servidor tiene que mostrar su identificación. Un certificado es un archivo pequeño que contiene una clave pública, la lista de nombres de host en nombre de los cuales puede hablar esa clave, una fecha de inicio, una fecha de fin y la firma de una autoridad de certificación (CA) que comprobó quién controla esos nombres. El navegador repasa su lista. El nombre de la barra de direcciones debe estar en el certificado. La fecha de hoy debe caer entre las dos fechas. La firma debe llevar a una autoridad en la que el dispositivo ya confía. Y el servidor debe demostrar que tiene la clave privada correspondiente. Si falla cualquiera de esas comprobaciones, el visitante ve la advertencia a pantalla completa.

El cifrado solo empieza cuando todo eso se ha verificado. El candado significa que el servidor demostró quién es, y el cifrado se apoya en esa prueba.

Qué comprueba el inspector

Se conecta dos veces al puerto 443. La primera acepta cualquier cosa, para poder leer el certificado sea cual sea su estado. La segunda lo verifica todo contra una lista estándar de raíces de confianza, como lo haría un cliente estricto.

Después pide las cuatro formas de la dirección (http y https, con y sin www) y muestra dónde termina cada una y si el sitio envía una cabecera HSTS. Si quieres ver esa parte salto a salto, el rastreo de redirecciones lo hace.

Funciona en Chrome y falla en todo lo demás

Las autoridades no firman tu certificado con su clave raíz. Lo firman con un certificado intermedio, que a su vez firmó la raíz. Los dispositivos solo guardan raíces, así que tu servidor tiene que enviar el intermedio junto con su propio certificado. Los dos juntos forman la cadena.

Cuando un servidor envía solo su propio certificado, Chrome y Edge de escritorio lo perdonan. Suelen descargar el intermedio que falta o reutilizar uno que vieron en otro sitio. Firefox con un perfil nuevo, los móviles Android antiguos, curl, los webhooks de pago, los servidores de correo y la mayoría de las bibliotecas de programación no te harán ese favor. Así acabas con un sitio que a su dueño le parece perfecto y que falla para un cliente de API. El inspector lo llama Cadena incompleta y lo indica cuando la verificación falla y se envió un solo certificado.

Cómo arreglar los fallos habituales

• Caducado. Los certificados automáticos se renuevan unos 30 días antes del final, así que si el tuyo caducó, la tarea de renovación lleva semanas fallando. Con Certbot, ejecuta certbot renew --dry-run y lee el error. Suele ser un registro DNS que cambió, un cortafuegos que cierra el puerto 80 o una redirección que se traga /.well-known/acme-challenge/.
• Nombre no cubierto. Solicita el certificado otra vez e incluye todos los nombres de host: certbot -d example.com -d www.example.com. Un comodín *.example.com cubre un nivel de subdominios. No cubre example.com en sí, algo con lo que tropieza mucha gente.
• Cadena incompleta. Indica al servidor el archivo de cadena completa. En nginx: ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;. En Apache 2.4.8 y posteriores, SSLCertificateFile acepta el mismo archivo.
• Autofirmado. Cámbialo por un certificado de una autoridad pública. Let’s Encrypt, ZeroSSL y Google Trust Services los entregan gratis.
• Protocolo antiguo. Activa TLS 1.2 y 1.3. En nginx: ssl_protocols TLSv1.2 TLSv1.3;

Puedes ver lo mismo desde una terminal con openssl s_client -connect example.com:443 -servername example.com.