TLS y PKI:

qué pasa realmente cuando ves el candado del navegador

Privacidad y seguridad web  |  unfantasmaenelsistema.com

El candado de la barra de direcciones es probablemente el icono de seguridad más visto y peor entendido de internet. Mucha gente cree que significa «esta web es de fiar»; en realidad no dice nada sobre las intenciones de quien está detrás. Otros creen que el certificado «cifra la conexión»; tampoco es exacto, porque el cifrado real lo hacen unas claves de sesión que se negocian en milisegundos y que el certificado solo ayuda a autenticar. Y casi nadie sabe que, cada vez que abres una web, tu navegador consulta una jerarquía de autoridades, listas públicas de transparencia y —a veces— servicios de revocación, todo antes de pintar la primera letra de la página.

Este artículo desmonta esa caja negra. Vamos a ver qué ocurre en el handshake de TLS 1.3, qué es una PKI y cómo se encadena la confianza desde una raíz hasta el certificado de una web, qué añaden Let’s Encrypt y el protocolo ACME, por qué los certificados caducan cada vez antes, cómo funciona (mal) la revocación, y qué te está diciendo realmente cada error NET::ERR_CERT_* del navegador. Al final tendrás comandos de openssl para inspeccionar cualquier certificado tú mismo.

1. Qué garantiza (y qué no) el candado

El candado indica una sola cosa: que la conexión entre tu navegador y el servidor está autenticada y cifrada mediante TLS, y que el certificado presentado por el servidor es válido, no ha caducado y lo emitió una autoridad de certificación (CA) en la que tu sistema confía. Nada más.

• No dice que el sitio sea legítimo en el sentido de honrado: una web de phishing montada esta mañana tiene su candado igual que tu banco, porque obtener un certificado para un dominio que controlas es gratis y automático
• No dice que el servidor esté bien configurado ni libre de vulnerabilidades en la aplicación
• Sí dice que nadie en la red entre tú y el servidor (tu operador, el wifi de la cafetería, un atacante en la misma LAN) puede leer ni modificar el tráfico sin que se note
• Sí dice que estás hablando con quien controla la clave privada asociada a ese certificado para ese nombre de dominio concreto

Esa última parte es la clave: TLS resuelve el problema de «estoy hablando con el servidor correcto y nadie escucha», no el de «este servicio merece mi dinero».

2. El handshake de TLS 1.3, sin humo

Un error muy extendido es pensar que el tráfico se cifra «con el certificado». El cifrado en masa de los datos lo hace un algoritmo simétrico rápido (AES-GCM o ChaCha20-Poly1305) con una clave de sesión que solo existe durante esa conexión. El certificado y su clave pública sirven para otra cosa: autenticar al servidor y proteger el intercambio que genera esa clave de sesión.

2.1 Los pasos, resumidos

• ClientHello: el navegador envía las versiones de TLS que soporta, la lista de cifrados, el nombre del dominio que quiere (extensión SNI) y —aquí está la novedad de TLS 1.3— ya una propuesta de material de clave efímero (key share) usando Diffie-Hellman de curva elíptica
• ServerHello: el servidor elige parámetros, manda su propia key share y, cifrado ya a partir de ese punto, su cadena de certificados
• Autenticación: el servidor firma con su clave privada un resumen de todo el handshake. El navegador verifica esa firma con la clave pública del certificado. Solo quien posee la clave privada puede haber producido esa firma
• Verificación de la cadena: el navegador comprueba que el certificado de la web está firmado por una intermedia, que la intermedia está firmada por una raíz, y que esa raíz está en su almacén de confianza (sección 3)
• Finished: ambos derivan las mismas claves de sesión a partir del secreto compartido de Diffie-Hellman. A partir de aquí todo va cifrado con criptografía simétrica

TLS 1.3 (RFC 8446, de 2018) reduce esto a un solo viaje de ida y vuelta (1-RTT), elimina los algoritmos de intercambio de clave sin forward secrecy, retira RSA como método de key exchange, y borra de la lista cifrados heredados rotos como RC4, 3DES o los modos CBC problemáticos. El resultado es más rápido y con menos superficie de ataque que TLS 1.2.

3. PKI: la cadena de confianza

PKI (Public Key Infrastructure, infraestructura de clave pública) es el conjunto de autoridades, políticas y formatos que permite que tu navegador confíe en el certificado de una web que nunca ha visto antes. La idea es delegar la confianza en cadena.

3.1 Raíz, intermedia y hoja

• Certificado raíz (root CA): una clave con un certificado autofirmado. Hay unos cientos en el mundo que importan. Sus claves privadas se guardan en módulos de hardware (HSM) desconectados, en instalaciones con control de acceso físico y ceremonias grabadas. Una raíz puede durar 20-25 años
• Certificado intermedio (issuing CA): firmado por la raíz. Es el que de verdad emite los certificados del día a día. Si una intermedia se ve comprometida, se revoca y se emite otra sin tocar la raíz —por eso las raíces casi nunca firman directamente certificados de servidor
• Certificado de hoja (leaf / end-entity): el de la web concreta. Contiene el dominio o dominios (campo Subject Alternative Name), la clave pública del servidor, las fechas de validez y la firma de la intermedia

Cuando tu navegador recibe la cadena, verifica hoja <- intermedia <- raíz. El ancla de confianza es la raíz: si está en el almacén del sistema, toda la cadena es válida. El servidor debe enviar la hoja y las intermedias; la raíz ya la tiene el cliente y no hace falta mandarla. Olvidar incluir la intermedia es la causa número uno de «funciona en mi navegador pero falla en el móvil de un cliente».

3.2 El almacén de CA raíz

Cada sistema operativo y algunos navegadores mantienen su propia lista de raíces de confianza, con programas de auditoría que las CA deben superar cada año (criterios WebTrust / ETSI, y las políticas de cada programa).

Que Mozilla y Chrome lleven su propia lista tiene una consecuencia práctica: una CA puede ser «expulsada» de esos programas por mala conducta (emisiones indebidas, fallos de auditoría) y quedar inservible para la web aunque siga en algún SO. Ha pasado varias veces.

4. Niveles de validación: DV, OV y EV

Todos los certificados cifran igual de bien. La diferencia entre niveles está solo en qué comprobó la CA antes de emitir.

Hasta 2019 los certificados EV pintaban el nombre de la empresa en verde junto a la barra. Chrome y Firefox lo retiraron porque los estudios de usabilidad demostraron que los usuarios no se fijaban en ese indicador y que su ausencia no cambiaba el comportamiento, mientras que sí se podía abusar registrando empresas con nombres parecidos. Resultado: hoy EV es, a efectos visuales, indistinguible de DV, y su cuota de mercado ha caído mucho.

5. Let’s Encrypt y el protocolo ACME

Let’s Encrypt (2015, de la organización sin ánimo de lucro ISRG) cambió la web: certificados DV gratis, emitidos en segundos por una API estandarizada. Hoy asegura cientos de millones de dominios y ha arrastrado a todo el sector hacia la automatización.

5.1 Cómo funciona ACME

ACME (Automatic Certificate Management Environment, RFC 8555) es el protocolo que habla tu cliente (certbot, acme.sh, o el integrado en Caddy, Traefik, nginx, paneles de hosting…) con la CA. El flujo, resumido:

• El cliente crea una cuenta y solicita un certificado para uno o varios dominios
• La CA responde con un reto (challenge): demuestra que controlas el dominio publicando un registro TXT en el DNS (dns-01) o sirviendo un fichero en una ruta concreta por HTTP (http-01)
• El cliente cumple el reto y avisa; la CA lo verifica desde varios puntos de la red
• El cliente envía una CSR (Certificate Signing Request) y la CA devuelve el certificado firmado
• Un temporizador (systemd, cron) repite todo el proceso mucho antes de la caducidad, sin intervención humana

# Emitir y configurar un certificado para un dominio propio con certbot + nginx
sudo certbot --nginx -d ejemplo.com -d www.ejemplo.com
 
# Ver los certificados gestionados y su fecha de caducidad
sudo certbot certificates
 
# Simular la renovacion sin tocar nada (util para comprobar el automatismo)
sudo certbot renew --dry-run

5.2 Por qué la caducidad corta es buena

Los certificados de Let’s Encrypt duran 90 días, y el sector avanza hacia periodos aún más cortos (el CA/Browser Forum ha aprobado bajar el máximo a 47 días de aquí a 2029). Suena incómodo, pero es una mejora de seguridad:

• Un certificado robado o una clave comprometida tiene una ventana de abuso mucho menor
• La revocación funciona mal (sección 6); si los certificados caducan pronto, se depende menos de ella
• Obliga a automatizar. Un proceso automático que se ejecuta cada 60 días se detecta cuando falla; uno manual cada 2 años se olvida y tumba el servicio un domingo por la noche

6. Revocación: el problema que nadie ha resuelto del todo

Si una clave privada se filtra o un certificado se emitió por error, hay que invalidarlo antes de su caducidad. Existen varios mecanismos y todos tienen pegas.

El fondo del asunto: históricamente, si la comprobación de revocación no obtenía respuesta, el navegador asumía que el certificado era válido (soft-fail), porque bloquear rompería demasiadas webs. Un atacante que pueda interceptar la red también puede bloquear la consulta OCSP. Por eso la industria ha preferido atacar el problema por el otro lado: certificados de vida corta, donde la caducidad hace casi todo el trabajo. De hecho, Let’s Encrypt anunció el fin de su servicio OCSP en 2025 en favor exclusivamente de CRL.

7. Certificate Transparency y crt.sh

Certificate Transparency (CT) es la respuesta a una pregunta incómoda: ¿cómo te enteras de que una CA ha emitido un certificado para tu dominio sin tu permiso? Desde 2018, los navegadores exigen que todo certificado nuevo aparezca en varios registros públicos de solo-añadir (append-only logs), criptográficamente verificables. La CA obtiene un recibo (SCT) que incrusta en el certificado; sin SCTs suficientes, Chrome y Safari lo rechazan.

Para un administrador esto es una herramienta de inventario y detección buenísima y gratuita:

• crt.sh (de Sectigo) es un buscador web sobre esos registros: escribe tu dominio y ves todos los certificados emitidos para él, por quién y cuándo
• Sirve para descubrir subdominios olvidados, certificados emitidos por un proveedor que ya no usas, o —la señal de alarma— uno que tú no pediste
• Servicios de monitorización (incluido el propio crt.sh vía RSS, o herramientas como Certspotter) te avisan por correo de cada emisión nueva para tus dominios

# Consultar la API JSON de crt.sh para un dominio y listar los nombres emitidos
curl -s 'https://crt.sh/?q=%25.ejemplo.com&output=json' | \
  python3 -c 'import sys,json;[print(c["name_value"]) for c in json.load(sys.stdin)]' | sort -u

8. Errores del navegador: qué significa cada NET::ERR_CERT_*

9. Inspeccionar un certificado con openssl

openssl s_client es la navaja suiza para ver exactamente qué presenta un servidor. Todos estos ejemplos son consultas de solo lectura contra servicios web normales.

# Ver la cadena completa y los datos del certificado de un dominio
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -text
 
# Solo lo esencial: emisor, fechas de validez y nombres cubiertos (SAN)
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName
 
# Comprobar que el servidor envia las intermedias (mira 'Certificate chain')
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com -showcerts < /dev/null
 
# Ver que version de TLS y que cifrado se negocia
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com < /dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher'
 
# Inspeccionar un fichero .pem o .crt local sin conectarse a ningun sitio
openssl x509 -in certificado.pem -noout -text

Para un chequeo más completo y con puntuación (configuración de cifrados, forward secrecy, cadena, vulnerabilidades conocidas) están SSL Labs (ssllabs.com/ssltest) en web y testssl.sh como script de línea de comandos que puedes correr contra tus propios servidores.

Conclusión

El candado no es un sello de honradez: es la prueba de que la conversación entre tu navegador y un servidor concreto está cifrada y autenticada, y de que una cadena de autoridades en las que tu sistema ha decidido confiar respalda la identidad de ese servidor para ese dominio. El cifrado real lo hacen claves de sesión efímeras negociadas en el handshake de TLS 1.3; el certificado solo sirve para autenticar ese intercambio.

Todo lo demás —la jerarquía raíz/intermedia/hoja, los niveles DV/OV/EV, ACME y la caducidad corta, la revocación que funciona a medias, y los registros públicos de Certificate Transparency— es andamiaje para que ese modelo de confianza escale a millones de sitios sin que tengas que decidir manualmente en quién confías. Saber leerlo con openssl y crt.sh convierte un icono opaco en información que puedes verificar tú mismo.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)