Capítulo 7: SSL/TLS — Cómo Internet protege la información¶
Diagramas del capítulo¶
D-033 - Handshake TLS
D-034 - Cadena de confianza
D-035 - Certificado digital
D-036 - HTTPS completo
D-037 - Cloudflare SSL
D-038 - Let's Encrypt
D-039 - Tipos de certificados
D-040 - Flujo HTTPS
Objetivos del capítulo¶
Al finalizar este capítulo serás capaz de:
- Explicar qué problema resuelve TLS y por qué HTTP sin cifrar es inaceptable en cualquier contexto moderno.
- Describir la evolución histórica de SSL hasta TLS 1.3, entendiendo qué vulnerabilidades empujaron cada salto de versión.
- Comprender los fundamentos criptográficos detrás de TLS — cifrado simétrico y asimétrico, ECDHE, forward secrecy, hashes y firmas digitales — sin necesitar matemáticas avanzadas.
- Distinguir los tipos de certificados (DV, OV, EV, wildcard, multi-dominio) y saber cuál corresponde a cada situación, incluyendo entender la cadena de confianza de las Autoridades Certificadoras.
- Configurar HTTPS profesional en Cloudflare eligiendo el modo SSL correcto (Full Strict), activando HSTS de forma gradual y segura, y generando un Origin Certificate.
- Diagnosticar y resolver los errores SSL más comunes usando SSL Labs, OpenSSL y las herramientas del navegador.
Introducción¶
En el Capítulo 6 aprendiste que HTTPS no es otra cosa que HTTP con TLS encima: el protocolo de transporte es el mismo, pero antes de que tu navegador y el servidor intercambien una sola línea de HTML, establecen un canal cifrado que hace que todos los datos viajen dentro de un tubo opaco e inviolable. Dijimos entonces que TLS era la "capa de seguridad" de HTTPS. Ahora vamos a abrir esa capa y entender exactamente qué hay dentro.
Piensa en TLS como el sobre sellado que protege una carta importante. Cuando envías una carta sin sobre, cualquier cartero, cualquier vecino entrometido, cualquier persona que maneje ese papel puede leer lo que escribiste. Con un sobre sellado ocurre algo interesante: cualquiera puede ver la dirección del destinatario y el remitente (eso es como el dominio visible en la URL), pero el contenido es completamente ilegible sin abrir el sobre. TLS hace eso mismo con los bytes que viajan entre tu navegador y un servidor, pero añade dos garantías adicionales que el sobre físico no puede dar: una firma que asegura que nadie ha manipulado el contenido en el camino, y un pasaporte que prueba que el destinatario es realmente quien dice ser y no un impostor.
Ese pequeño candado que ves en la barra de direcciones de tu navegador junto a https://elprofe.org es TLS. No es decorativo. Es la prueba visible de que se completó un proceso criptográfico sofisticado que tardó menos de 100 milisegundos y que ahora protege todo lo que envíes y recibas. En este capítulo vas a entender exactamente cómo funciona ese proceso, desde los fundamentos matemáticos explicados sin ecuaciones hasta la configuración práctica paso a paso en Cloudflare.
El recorrido que haremos: comenzaremos entendiendo el problema que TLS resuelve (porque sin entender el problema, la solución no tiene sentido). Luego haremos un viaje histórico desde los años 90 hasta hoy para ver cómo cada versión de SSL y TLS fue derrotada y mejorada. Exploraremos la criptografía que hace todo esto posible con analogías y sin fórmulas. Diseccionaremos los certificados digitales y las Autoridades Certificadoras. Veremos el handshake TLS en cámara lenta. Y terminaremos con configuración práctica, diagnóstico de errores y un proyecto completo para dejar elprofe.org con una calificación A+ en SSL Labs.
7.1 El problema que TLS resuelve¶
La carta postal sin sobre¶
Antes de que existiera HTTPS, toda la web funcionaba en texto plano. Cuando escribías tu contraseña en un formulario y hacías clic en "Iniciar sesión", esos bytes viajaban por la red exactamente como los escribiste: sin ningún tipo de protección. Era como enviar una carta con tus datos bancarios escrita directamente en una postal, sin sobre, sin codificación, lista para que cualquiera que la manejara la leyera.
¿Qué significa "cualquiera en la red"? Más personas de las que crees. Entre tu computadora y el servidor de destino, los datos pasan por decenas de nodos: el router de tu casa, el del café donde trabajas, el proveedor de internet (ISP), múltiples routers de tránsito, el proveedor de alojamiento del servidor... En cualquiera de esos puntos, alguien con el software adecuado puede simplemente leer el tráfico que pasa. Es como escuchar una conversación en voz alta en un tren lleno de gente: técnicamente no te dirigiste a ellos, pero cualquiera puede oír.
Los tres ataques clásicos sin TLS¶
Sin TLS — El atacante en el medio lo ve todo:
┌──────────┐ ┌──────────────┐ ┌──────────┐
│Navegador │────────▶│ Atacante │────────▶│Servidor │
│ usuario │◀────────│ (MITM) │◀────────│ │
└──────────┘ texto └──────────────┘ texto └──────────┘
plano Ve y modifica plano
TODO el tráfico
GET /login HTTP/1.1
user=admin&pass=secreto123
← ¡Legible completamente! →
Los tres ataques fundamentales que HTTP sin cifrar permite son:
1. Eavesdropping (escucha pasiva): El atacante simplemente observa el tráfico sin modificarlo. Lee contraseñas, tokens de sesión, datos personales, mensajes privados. El usuario no nota nada raro porque la comunicación llega íntegra.
2. Tampering (modificación en tránsito): El atacante intercepta el tráfico y lo modifica antes de reenviarlo. Puede cambiar el contenido de una página web, insertar publicidad maliciosa o malware, cambiar números de cuenta bancaria, o alterar instrucciones de pago. La víctima recibe contenido diferente al original sin saberlo.
3. Suplantación (impersonation): ¿Cómo sabes que el servidor al que te conectas es realmente elprofe.org y no un servidor malicioso que copió la página? Sin autenticación criptográfica, no puedes saberlo. Un atacante puede interceptar la conexión y responder haciéndose pasar por el servidor legítimo.
Los tres problemas que TLS resuelve¶
TLS fue diseñado específicamente para atacar estos tres problemas:
| Problema | Ataque que permite | Solución TLS |
|---|---|---|
| Sin confidencialidad | Eavesdropping | Cifrado simétrico (AES-256-GCM) |
| Sin integridad | Tampering | HMAC / AEAD (detecta modificaciones) |
| Sin autenticación | Suplantación | Certificados digitales + cadena de confianza |
Confidencialidad: Los datos viajan cifrados. Aunque el atacante capture cada byte, lo único que ve es ruido estadístico ilegible sin la clave de descifrado.
Integridad: Cada mensaje incluye un código de autenticación criptográfico (MAC). Si alguien modifica un solo bit del mensaje en tránsito, el MAC no coincide y el receptor descarta el mensaje inmediatamente. No hay forma de modificar el mensaje sin ser detectado.
Autenticación: El servidor presenta un certificado digital firmado por una Autoridad Certificadora (CA) de confianza, que tu navegador ya conoce. Es como el lacre con el sello oficial en una carta: puedes verificar que es auténtico y que nadie la abrió.
La analogía completa: sobre sellado + firma + lacre¶
Imagina que recibes una carta muy importante:
- Sin TLS: tarjeta postal abierta — todos leen el contenido.
- Con cifrado pero sin autenticación: carta en sobre sellado, pero ¿quién la envió realmente? Podría ser un impostor.
- Con TLS completo: carta en sobre sellado (confidencialidad), con firma notarial verificable (autenticación), y con cinta inviolable que si alguien la tocó lo deja visible (integridad).
Esos tres elementos juntos son lo que hace que el candado verde de tu navegador signifique algo real.
7.2 Historia: del texto plano a TLS 1.3¶
La historia de SSL/TLS es fascinante porque es la historia de la criptografía aplicada a Internet bajo presión real: cada versión fue derrotada por investigadores y atacantes, y cada derrota produjo una versión mejor.
La línea temporal¶
┌─────────────────────────────────────────────────────────────────────────┐
│ EVOLUCIÓN SSL/TLS (1994 - 2026) │
├────────┬────────────────────────┬────────────────────────────────────────┤
│ Año │ Versión │ Destino │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 1994 │ SSL 1.0 (Netscape) │ Nunca publicado — vulnerabilidades │
│ │ │ graves descubiertas internamente │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 1995 │ SSL 2.0 (Netscape) │ Primer intento público — DROWN (2016) │
│ │ │ lo terminó. Deprecado RFC 6176. │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 1996 │ SSL 3.0 (Netscape) │ POODLE (2014) lo mató oficialmente. │
│ │ │ RFC 7568 lo deprecó (2015). │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 1999 │ TLS 1.0 (IETF) │ BEAST (2011), POODLE-TLS. │
│ │ RFC 2246 │ RFC 8996 lo deprecó (marzo 2021). │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 2006 │ TLS 1.1 │ RFC 8996 lo deprecó (marzo 2021). │
│ │ RFC 4346 │ Browsers lo bloquearon en 2020. │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 2008 │ TLS 1.2 │ Vigente. Base del web 2008-2018. │
│ │ RFC 5246 │ AES-GCM, SHA-256. Sigue soportado. │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 2018 │ TLS 1.3 │ El estándar actual. RFC 8446 │
│ │ RFC 8446 (ago 2018) │ 1-RTT, forward secrecy obligatorio, │
│ │ │ eliminación de todo lo débil. │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 2021 │ TLS 1.0/1.1 │ RFC 8996 (marzo 2021): deprecated. │
│ │ deprecados │ Chrome, Firefox, Safari los bloquean. │
├────────┼────────────────────────┼────────────────────────────────────────┤
│ 2026 │ TLS 1.3 │ >90% del tráfico HTTPS global. │
│ │ dominante │ TLS 1.2 sigue como fallback. │
└────────┴────────────────────────┴────────────────────────────────────────┘
1994-1996: El laboratorio de Netscape¶
En 1994, Netscape Communications estaba construyendo lo que se convertiría en el primer navegador popular de la historia, Netscape Navigator. Su equipo de ingeniería se dio cuenta de que si querían que la gente comprara cosas en línea y usara la banca por internet, HTTP plano era completamente inaceptable. Diseñaron SSL 1.0, pero las revisiones internas encontraron vulnerabilidades tan graves que nunca lo publicaron. Nadie fuera de Netscape lo vio jamás.
En 1995 publicaron SSL 2.0, el primer protocolo de seguridad web que el público pudo usar. Tenía problemas serios: el mecanismo de intercambio de claves era débil, no protegía contra ataques de truncamiento de conexión, y usaba MD5 para la integridad de mensajes. Pero fue el primer paso.
SSL 3.0 en 1996 fue un rediseño completo, mucho más sólido. Se convirtió en el estándar de facto de la seguridad web durante años. Pero en 2014, los investigadores de Google publicaron el ataque POODLE (Padding Oracle On Downgraded Legacy Encryption): explotaba una debilidad fundamental en cómo SSL 3.0 usaba el modo CBC para el cifrado de bloques. Fin del camino para SSL 3.0.
1999: IETF toma el control y nace TLS¶
Cuando el IETF (Internet Engineering Task Force) estandarizó el protocolo, tomaron SSL 3.0 como base y lo refinaron. El resultado fue TLS 1.0 (RFC 2246, 1999). Las diferencias técnicas con SSL 3.0 eran menores, pero el nombre cambió por razones políticas: era el IETF, no Netscape, quien ahora era el custodio del protocolo. Por eso hasta hoy la gente dice "SSL" pero lo que realmente usa es "TLS".
TLS 1.0 tuvo su propia vida útil de poco más de dos décadas, pero fue atacado con éxito por BEAST (2011) y otras variantes del ataque POODLE. En 2021, RFC 8996 lo deprecó oficialmente junto con TLS 1.1.
2008: TLS 1.2 — la base del web moderno¶
TLS 1.2 (RFC 5246, 2008) fue el primer salto cualitativo real. Introdujo: - AES-GCM: un modo de cifrado autenticado (AEAD) que es simultáneamente rápido y seguro. - SHA-256: hash criptográfico mucho más robusto que SHA-1 y MD5. - Flexibilidad para elegir algoritmos criptográficos más modernos.
TLS 1.2 fue el estándar durante una década. Hoy, en 2026, sigue siendo soportado como fallback, pero ya no es el líder.
2018: TLS 1.3 — el rediseño radical¶
TLS 1.3 (RFC 8446, agosto 2018) no es una actualización incremental: es prácticamente un nuevo protocolo. El equipo que lo diseñó se hizo una pregunta brutal: ¿qué pasaría si empezáramos de cero sabiendo todo lo que sabemos sobre ataques criptográficos?
El resultado fue drástico: - Handshake reducido a 1 RTT (frente a los 2 RTT de TLS 1.2): las conexiones son ~50-100ms más rápidas. - Eliminación quirúrgica de todo lo débil: RSA key exchange estático, CBC, RC4, MD5, SHA-1, DSA, EXPORT ciphers — todo fuera. - Forward secrecy obligatorio: ya no es opcional, ECDHE es el único mecanismo de intercambio de claves permitido. - El certificado viaja cifrado: en TLS 1.2, el certificado iba en texto claro; en TLS 1.3 va cifrado desde el primer mensaje del servidor. - Solo 5 cipher suites: en vez de las docenas confusas y a veces peligrosas de TLS 1.2.
En 2026, más del 90% de las conexiones HTTPS usan TLS 1.3. TLS 1.0 y 1.1 están bloqueados en todos los navegadores modernos.
7.3 Criptografía sin matemáticas¶
Para entender TLS no necesitas saber álgebra de curvas elípticas ni teoría de números. Lo que sí necesitas son buenas analogías. Esta sección te da exactamente eso.
Criptografía simétrica: la misma llave para todo¶
Imagina una caja fuerte con una combinación. Si tú y tu amigo conocen la misma combinación, ambos pueden abrir y cerrar la caja. Eso es criptografía simétrica: una sola clave que tanto cifra como descifra.
El algoritmo más usado hoy es AES-256-GCM (Advanced Encryption Standard, 256 bits, modo Galois/Counter). Es extraordinariamente rápido — puede cifrar gigabytes por segundo en hardware moderno — y matemáticamente muy sólido.
El gran problema de la criptografía simétrica es el problema de la distribución de claves: si necesitas pasarle la combinación de la caja fuerte a alguien, ¿cómo se la dices sin que nadie la intercepte? Si lo dices por teléfono, alguien podría estar escuchando. Si la escribes en un papel y lo envías por correo, alguien podría abrir el sobre.
TLS resuelve exactamente este problema. El objetivo del handshake es que tú y el servidor acordéis una clave simétrica secreta sin que nadie que esté escuchando en la red pueda conocerla.
Criptografía asimétrica: el buzón con ranura¶
Imagina un buzón en la calle con una ranura en la tapa. Cualquier persona puede pasar, meter una carta por la ranura, y el sobre cae dentro del buzón. Pero solo el dueño del buzón tiene la llave para abrir la puerta trasera y sacar las cartas.
Así funciona la criptografía asimétrica. Cada parte tiene dos claves matemáticamente emparejadas: - Clave pública: como la ranura del buzón. Se publica libremente. Cualquiera puede usarla para cifrar un mensaje dirigido a ti. - Clave privada: como la llave de la puerta trasera. Nunca sale del servidor. Es el secreto máximo.
Lo que cifras con la clave pública, solo la clave privada puede descifrarlo. Y viceversa: lo que "cifras" (firmas) con la clave privada, cualquiera con la clave pública puede verificarlo.
┌─────────────────────────────────────────────────────────┐
│ Criptografía Asimétrica │
│ │
│ Clave Pública Clave Privada │
│ (distribución libre) (secreto absoluto) │
│ │
│ Navegador Servidor elprofe.org │
│ ┌─────────┐ ┌─────────────────┐ │
│ │Cifra con│────────────▶│Descifra con │ │
│ │clave │ │clave privada │ │
│ │pública │ │ │ │
│ └─────────┘ └─────────────────┘ │
│ │
│ La clave pública está en el certificado digital │
│ La clave privada está en el servidor, punto. │
└─────────────────────────────────────────────────────────┘
La criptografía asimétrica es mucho más lenta que la simétrica. Por eso TLS la usa solo para el intercambio inicial de claves — el apretón de manos — y luego usa cifrado simétrico (AES) para todo el resto de la comunicación.
ECDHE: el intercambio mágico de claves¶
ECDHE son las siglas de Elliptic Curve Diffie-Hellman Ephemeral. Es el mecanismo que permite a dos partes acordar una clave secreta compartida a través de un canal completamente público y potencialmente vigilado, sin que esa clave secreta se transmita jamás.
Suena a magia. La mejor analogía que existe es la de los colores:
La analogía del intercambio de colores:
Alice Bob
│ │
│ 1. Eligen un color PÚBLICO ──────│
│ amarillo (conocido por todos) │
│ │
│ 2. Cada uno elige un color │
│ SECRETO privado │
│ Alice: rojo Bob: azul │
│ │
│ 3. Cada uno mezcla: │
│ Alice: amarillo+rojo = naranja │
│ Bob: amarillo+azul = verde │
│ │
│ 4. Intercambian su mezcla │
│ Alice ─────naranja────▶ Bob │
│ Alice ◀────verde────── Bob │
│ │
│ 5. Cada uno mezcla con su secreto│
│ Alice: verde + rojo = marrón │
│ Bob: naranja + azul = marrón │
│ │
│ ¡Ambos llegaron al mismo color! │
│ Y nadie que observó puede │
│ reconstituirlo sin conocer los │
│ colores secretos individuales. │
En ECDHE real, los "colores" son números en una curva elíptica, y la "mezcla" es una operación matemática que es irreversible. El resultado es una clave secreta compartida que ninguno de los dos tuvo que transmitir.
La E de Ephemeral (efímero) es crucial: se genera un nuevo par de claves para cada sesión. Cada vez que abres elprofe.org, se genera un intercambio ECDHE completamente nuevo con claves nuevas. Eso lleva al siguiente concepto.
Forward Secrecy: las sesiones de ayer son inviolables¶
Imagina que alguien graba todo tu tráfico HTTPS cifrado durante años. Un día, logran robar la clave privada del servidor. Con un sistema sin forward secrecy, podrían descifrar retroactivamente todos esos años de tráfico capturado.
Forward Secrecy (confidencialidad directa) hace que eso sea imposible. Porque con ECDHE, cada sesión usa claves efímeras únicas que no se almacenan en el servidor. Una vez que la sesión termina, esas claves desaparecen para siempre. No hay manera de descifrar el tráfico pasado aunque alguien robe la clave privada del servidor en el futuro.
TLS 1.3 hace forward secrecy obligatorio: solo se permite ECDHE para el intercambio de claves. En TLS 1.2 era opcional, lo que llevó a muchos servidores a usar RSA estático (sin forward secrecy) por años.
Hash: la huella dactilar de los datos¶
Una función hash criptográfica toma cualquier cantidad de datos — un archivo, un mensaje, un certificado completo — y produce una cadena de longitud fija: el digest o resumen. SHA-256 produce siempre 64 caracteres hexadecimales.
Las propiedades clave: - Determinista: el mismo input siempre produce el mismo hash. - Avalancha: cambiar un solo bit del input cambia completamente el hash. - Irreversible: no puedes reconstruir el mensaje original a partir del hash. - Libre de colisiones: prácticamente imposible encontrar dos mensajes distintos con el mismo hash.
SHA-256 en acción:
"elprofe.org" → SHA-256 → a7f3d9c1e4b8... (64 chars hex)
"elProfe.org" → SHA-256 → 2c9b4f71a3e0... (completamente diferente)
En TLS, los hashes se usan para verificar la integridad de los mensajes del handshake: cualquier manipulación en tránsito cambiaría el hash y sería detectada inmediatamente.
Firma digital: el notario criptográfico¶
Una firma digital es el mecanismo que permite al servidor demostrar que posee la clave privada correspondiente al certificado, sin revelar esa clave privada. Funciona así:
- El servidor calcula el hash SHA-256 de un mensaje.
- Cifra ese hash con su clave privada → eso es la firma.
- Envía el mensaje + la firma.
- El receptor descifra la firma con la clave pública del servidor → obtiene el hash.
- Calcula independientemente el hash del mensaje recibido.
- Si ambos hashes coinciden: el mensaje es auténtico (vino de quien tiene la clave privada) e íntegro (no fue modificado).
Es el equivalente digital del sello notarial: cualquiera puede verificar la autenticidad, pero solo el notario pudo crear el sello original.
7.4 Certificados digitales: el pasaporte del servidor¶
¿Qué es un certificado digital?¶
Un certificado digital es un documento electrónico que enlaza una clave pública con una identidad. En el contexto de TLS, esa identidad es un nombre de dominio: elprofe.org.
La analogía perfecta es el pasaporte. Tu pasaporte contiene:
- Tu foto (en el certificado: la clave pública del servidor)
- Tu nombre (en el certificado: el dominio)
- Quién lo emitió (en el certificado: la Autoridad Certificadora)
- Fecha de expiración (en el certificado: notAfter)
- Una firma oficial que lo hace difícil de falsificar (en el certificado: la firma criptográfica de la CA)
Sin esa firma oficial, cualquiera podría imprimir un pasaporte falso. De la misma manera, sin la firma de una CA de confianza, cualquier servidor podría crear un certificado y afirmar ser elprofe.org.
Formato estándar: X.509 v3¶
Los certificados web siguen el estándar X.509 versión 3, definido en el RFC 5280. Cuando tu navegador se conecta a cualquier sitio HTTPS, recibe uno o varios certificados en este formato.
Veamos el contenido de un certificado real típico para elprofe.org:
┌─────────────────────────────────────────────────────────────┐
│ Certificado X.509 v3 — elprofe.org │
├─────────────────────┬───────────────────────────────────────┤
│ Campo │ Valor │
├─────────────────────┼───────────────────────────────────────┤
│ Versión │ X.509 v3 │
│ Número de serie │ 03:a1:b2:c3:4d:5e:6f:... │
├─────────────────────┼───────────────────────────────────────┤
│ Sujeto (Subject) │ │
│ CN │ elprofe.org │
├─────────────────────┼───────────────────────────────────────┤
│ SAN (Alt. Names) │ DNS: elprofe.org │
│ │ DNS: www.elprofe.org │
│ │ DNS: api.elprofe.org │
├─────────────────────┼───────────────────────────────────────┤
│ Emisor (Issuer) │ CN=R11, O=Let's Encrypt, C=US │
├─────────────────────┼───────────────────────────────────────┤
│ Validez │ Desde: 28 Jun 2026 00:00:00 UTC │
│ │ Hasta: 26 Sep 2026 00:00:00 UTC │
├─────────────────────┼───────────────────────────────────────┤
│ Clave pública │ EC 256 bits (curva prime256v1) │
├─────────────────────┼───────────────────────────────────────┤
│ Algoritmo de firma │ SHA-256 with ECDSA │
├─────────────────────┼───────────────────────────────────────┤
│ Firma de la CA │ 3046022100d4e3... (Let's Encrypt R11) │
└─────────────────────┴───────────────────────────────────────┘
Los campos que más importan¶
CN (Common Name): El nombre del dominio principal. Históricamente era el campo que los navegadores verificaban para validar el dominio. Hoy ese rol lo tiene el SAN.
SAN (Subject Alternative Names): La lista de todos los dominios que cubre el certificado. Desde 2017, los navegadores ignoran el CN y solo valoran el SAN para la validación del dominio. Si elprofe.org no está en el SAN (aunque esté en el CN), el navegador mostrará un error de certificado. Es crítico que todos los dominios que uses estén listados aquí.
Validez (notBefore / notAfter): La ventana de tiempo en que el certificado es válido. Let's Encrypt emite certificados de 90 días. El CA/Browser Forum estableció un máximo de 1 año desde 2020, y existe una propuesta activa en 2026 para reducirlo a 47 días. Los certificados más cortos obligan a la automatización, lo que en realidad mejora la seguridad (menos tiempo de exposición si una clave privada se compromete).
Firma de la CA: La firma criptográfica de la Autoridad Certificadora sobre todos los campos anteriores. Esta firma es lo que hace al certificado confiable: demuestra que la CA verificó que quien solicitó el certificado realmente controla elprofe.org.
7.5 Autoridades Certificadoras: ¿quién garantiza la garantía?¶
El problema de confianza inicial¶
Tienes el certificado de elprofe.org. Dice que la clave pública que contiene pertenece a elprofe.org. ¿Pero quién te dice que ese certificado no lo creó un atacante que simplemente escribió elprofe.org en el campo CN?
Aquí está la clave: el certificado viene firmado por una Autoridad Certificadora (CA). La firma dice: "Yo, Let's Encrypt, verifico que quien controla este certificado también controla el dominio elprofe.org en este momento."
Pero entonces, ¿cómo sabes que Let's Encrypt es de confianza? Porque su certificado viene firmado por el Root CA de ISRG (Internet Security Research Group). Y ese Root CA está preinstalado en tu sistema operativo y navegador. Es la base de confianza: alguien tuvo que decidir en algún momento que ciertos Root CAs son confiables, y ese trabajo lo hacen los fabricantes de sistemas operativos y navegadores (Apple, Microsoft, Google, Mozilla).
La cadena de confianza¶
┌─────────────────────────────────────────────────────────────────┐
│ CADENA DE CONFIANZA PKI │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Root CA: ISRG Root X1 │ │
│ │ Preinstalado en Chrome, Firefox, macOS, Windows, iOS │ │
│ │ Certificado autofirmado — es la raíz de confianza │ │
│ └────────────────────────┬─────────────────────────────────┘ │
│ │ firma a │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Intermediate CA: R11 (Let's Encrypt) │ │
│ │ Emite certificados reales a dominios. │ │
│ │ Firmado por ISRG Root X1. │ │
│ └────────────────────────┬─────────────────────────────────┘ │
│ │ firma a │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Certificado del servidor: elprofe.org │ │
│ │ Lo que recibe el navegador. │ │
│ │ Firmado por R11 (Let's Encrypt). │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ Verificación: │
│ 1. Navegador recibe cert de elprofe.org + cert de R11 │
│ 2. Verifica firma de elprofe.org con clave pública de R11 │
│ 3. Verifica firma de R11 con clave pública de ISRG Root X1 │
│ 4. ISRG Root X1 está en su almacén de confianza → ✓ válido │
└─────────────────────────────────────────────────────────────────┘
Hay alrededor de 150 Root CAs preinstaladas en los navegadores modernos. Cada una de ellas puede emitir (o delegar en intermediarias que emitan) certificados para cualquier dominio del mundo.
Certificate Transparency: el registro público de todos los certificados¶
Antes de 2018, una CA comprometida o maliciosa podía emitir certificados fraudulentos para cualquier dominio sin que nadie se enterara. En 2011, Comodo y DigiNotar fueron comprometidas y emitieron certificados fraudulentos para dominios de Google, Yahoo y otros. Fue un escándalo enorme.
La respuesta de la industria fue Certificate Transparency (CT), estandarizado en RFC 9162. Desde 2018, todas las CAs están obligadas a registrar cada certificado que emiten en logs públicos inmutables (como un blockchain). Cualquier persona puede auditar estos logs y detectar si alguien emitió un certificado fraudulento para su dominio.
Puedes ver todos los certificados emitidos para tu dominio en crt.sh. Es una práctica de seguridad recomendada revisarlo periódicamente.
Las CAs principales¶
| CA | Tipo | Especialidad |
|---|---|---|
| Let's Encrypt (ISRG) | Gratuita | DV automático, ACME. Líder en volumen. |
| DigiCert | Comercial | Enterprise, OV/EV. Compró Symantec CA (2017). |
| Sectigo (ex Comodo) | Comercial | Mayor volumen comercial de OV/EV. |
| GlobalSign | Comercial | B2B, compliance. |
| Google Trust Services | Gratuita | Integrada en Google Cloud y Firebase. |
| Cloudflare CA | Gratuita | Universal SSL para clientes de Cloudflare. |
7.6 Let's Encrypt: la democratización del HTTPS¶
El problema que resolvió¶
Antes de 2015, obtener un certificado SSL era un proceso manual, burocrático y caro. Tenías que enviar documentos, esperar días, pagar $50-$200 al año, y luego recordar renovarlo manualmente cada año. El resultado era predecible: millones de sitios web pequeños funcionaban en HTTP plano simplemente porque HTTPS era demasiado engorroso y caro.
Let's Encrypt cambió eso radicalmente. Fundado por la EFF, Mozilla, Cisco, Akamai, y otros, y gestionado por el ISRG (Internet Security Research Group), se lanzó en diciembre de 2015 con una misión simple: certificados TLS gratuitos, automáticos y para todos.
En 2025, Let's Encrypt superó los 1,000 millones de certificados emitidos históricamente y protege una fracción enorme del tráfico HTTPS mundial. Puedes ver las estadísticas en tiempo real en letsencrypt.org/stats/.
Por qué 90 días en vez de 1 año¶
Let's Encrypt emite certificados de solo 90 días de validez (frente al año de muchas CAs comerciales). Esto podría parecer una limitación, pero es una decisión de diseño inteligente por dos razones:
-
Obliga a la automatización. No puedes gestionar un certificado de 90 días manualmente sin volverte loco. Esto fuerza a implementar renovación automática, lo cual es mejor práctica de todas formas.
-
Limita la exposición si una clave privada se compromete. Si alguien roba tu clave privada hoy, el daño máximo dura 90 días (o menos, si detectas el problema).
ACME Protocol: el protocolo que lo hace posible¶
El protocolo ACME (Automatic Certificate Management Environment, RFC 8555) es la tecnología que permite que todo el proceso de obtención y renovación de certificados sea completamente automático. En vez de un humano enviando documentos, es un programa que completa el proceso en segundos.
El flujo ACME funciona así: el cliente (Certbot u otro) solicita un certificado a Let's Encrypt, que responde con un challenge — un desafío que el servidor debe completar para demostrar que controla el dominio:
┌─────────────────────────────────────────────────────────────────┐
│ FLUJO ACME (RFC 8555) │
│ │
│ ┌─────────────┐ ┌────────────────────┐ │
│ │ Certbot │ │ Let's Encrypt │ │
│ │ (cliente) │ │ (ACME server) │ │
│ └──────┬──────┘ └─────────┬──────────┘ │
│ │ │ │
│ │── 1. "Quiero cert para elprofe.org" ──▶│ │
│ │ │ │
│ │◀─ 2. "Challenge: coloca este token" ──│ │
│ │ en /.well-known/acme-challenge/ │ │
│ │ │ │
│ │── 3. Coloca el archivo en el servidor─▶ │
│ │ │ │
│ │── 4. "Listo, puedes verificar" ───────▶│ │
│ │ │ │
│ │ 5. Let's Encrypt verifica el archivo│ │
│ │ vía HTTP desde Internet │ │
│ │ │ │
│ │◀─ 6. "Verificado. Aquí tu certificado"│ │
│ │ │ │
│ ✓ Certificado instalado en segundos │ │
└─────────────────────────────────────────────────────────────────┘
Hay tres tipos de challenge disponibles:
- HTTP-01 (el más común): Certbot coloca un archivo en
http://elprofe.org/.well-known/acme-challenge/TOKEN. Let's Encrypt lo fetcha para verificar. Requiere que el servidor web esté accesible en el puerto 80. - DNS-01: Certbot añade un registro TXT
_acme-challenge.elprofe.orgcon un valor específico. Let's Encrypt verifica el DNS. Necesario para wildcards (*.elprofe.org) y para servidores sin acceso público al puerto 80. - TLS-ALPN-01: El servidor responde en el handshake TLS con la prueba. Menos común.
Certbot: la herramienta oficial¶
Certbot es la herramienta de referencia para obtener y renovar certificados de Let's Encrypt en servidores Linux. Desarrollada por la EFF, es gratuita y de código abierto.
# Instalar certificado para Nginx en Ubuntu (configura Nginx automáticamente)
# Solo obtener el certificado (sin modificar configuración de Nginx)
# Renovar todos los certificados próximos a expirar (simulación)
# Renovar de verdad
# Añadir al cron para renovación automática (cada día a medianoche)
# Redirigir HTTP → HTTPS
# Ver fechas del certificado
# Probar renovación
# Intentar conectar directamente al origen (usando la IP del servidor)
# Ver todos los detalles del certificado
# Ver solo el certificado (texto legible)
# Ver solo fechas de validez
# Ver la cadena completa de certificados
# Verificar que TLS 1.3 funciona
# Verificar HTTPS y mostrar detalles de la negociación TLS
# Forzar TLS 1.3
# Ver solo los headers de respuesta HTTP (incluyendo HSTS)
# Ignorar errores de certificado (solo para diagnóstico, nunca en producción)
# Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
# Instalar Certbot (Ubuntu 22.04+)
# Obtener e instalar certificado
# Verificar renovación automática (Certbot instala un timer systemd)
# En el servidor de origen (Ubuntu/Debian)
# /etc/nginx/sites-available/elprofe.org
# Redirigir HTTP → HTTPS
# Verificar HTTPS y headers
# Buscar el header HSTS
# Ver versión TLS y cipher suite
# Ver detalles del certificado
### Paso 11: Configurar alertas de expiración de certificado
Aunque Cloudflare renueva el Universal SSL automáticamente, configura una alerta externa como red de seguridad:
- **UptimeRobot** (gratuito): Nuevo monitor → tipo SSL → dominio `elprofe.org` → alerta 30 días antes de expiración.
- O en el panel de Cloudflare: **Notifications** → crear alerta para expiración de certificado.
---
### Paso 12: Verificar Certificate Transparency
Visita [crt.sh/?q=elprofe.org](https://crt.sh/?q=elprofe.org) para ver todos los certificados emitidos para tu dominio.
Deberías ver el Universal SSL de Cloudflare y, si configuraste el Origin Certificate, también ese aparecerá (aunque los certificados de origen a veces no se registran en CT porque no son certificados de CA pública).
Si ves certificados que no reconoces (de CAs que no son Cloudflare o Let's Encrypt), investiga inmediatamente — podría ser evidencia de que alguien emitió un certificado fraudulento para tu dominio.
**Opcional:** Configura un registro DNS **CAA** para `elprofe.org` que solo permita a Cloudflare y Let's Encrypt emitir certificados:
Resultado final¶
Con esta configuración, elprofe.org tiene:
- ✓ HTTPS cifrado de extremo a extremo (navegador → Cloudflare → origen)
- ✓ Certificado validado en ambos tramos (Full Strict)
- ✓ TLS 1.2 mínimo, TLS 1.3 disponible
- ✓ Forward secrecy garantizado (ECDHE)
- ✓ HSTS progresivo hacia preload
- ✓ Redirección automática HTTP → HTTPS
- ✓ Contenido mixto corregido automáticamente
- ✓ Alerta de expiración configurada
- ✓ Certificate Transparency monitoreado
- ✓ Calificación: A+ en SSL Labs
Referencias bibliográficas¶
-
RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — E. Rescorla, IETF (agosto 2018).
https://www.rfc-editor.org/rfc/rfc8446 -
RFC 8996 — Deprecating TLS 1.0 and TLS 1.1 — K. Moriarty, S. Farrell, IETF (marzo 2021).
https://www.rfc-editor.org/rfc/rfc8996 -
RFC 8555 — Automatic Certificate Management Environment (ACME) — R. Barnes et al., IETF (marzo 2019).
https://www.rfc-editor.org/rfc/rfc8555 -
RFC 5280 — Internet X.509 PKI Certificate and CRL Profile — D. Cooper et al., IETF (mayo 2008).
https://www.rfc-editor.org/rfc/rfc5280 -
RFC 6797 — HTTP Strict Transport Security (HSTS) — J. Hodges, C. Jackson, A. Barth, IETF (noviembre 2012).
https://www.rfc-editor.org/rfc/rfc6797 -
RFC 9162 — Certificate Transparency Version 2.0 — B. Laurie et al., IETF (diciembre 2021).
https://www.rfc-editor.org/rfc/rfc9162 -
Cloudflare SSL/TLS — Origin Configuration (Modos SSL) — Documentación oficial de Cloudflare.
https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/ -
Let's Encrypt Stats — Estadísticas de certificados emitidos históricamente.
https://letsencrypt.org/stats/ -
SSL Labs SSL Server Test — Qualys. Herramienta gratuita de análisis TLS.
https://www.ssllabs.com/ssltest/ -
DV, OV and EV Certificates — SSL.com.
https://www.ssl.com/article/dv-ov-and-ev-certificates/ -
CA/Browser Forum — Information for Consumers — Baseline Requirements y políticas de certificados.
https://cabforum.org/about/information/consumers/ -
TLS 1.2 vs TLS 1.3 Adoption Statistics — Orankit Blog (2026).
https://orankit.com/blog/tls-1-2-vs-1-3 -
Certbot — Documentación oficial — Electronic Frontier Foundation.
https://certbot.eff.org -
HSTS Preload List — Sitio oficial para solicitar inclusión.
https://hstspreload.org -
crt.sh — Certificate Transparency Log Search — Sectigo/Comodo.
https://crt.sh -
POODLE: SSLv3 vulnerability — Bodo Möller, Thai Duong, Krzysztof Kotowicz, Google Security Blog (octubre 2014).
https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
¿Qué viene en el Capítulo 8?¶
Ahora que elprofe.org viaja seguro por Internet gracias a TLS, hay otro aspecto crítico de una infraestructura web profesional que no hemos tocado: la velocidad y la disponibilidad global.
Cuando alguien en Ciudad de México accede a elprofe.org y el servidor está en Ámsterdam, los datos tienen que viajar 10,000 kilómetros de ida y otros 10,000 de vuelta. Eso son entre 150-200ms de latencia solo por la física, antes de que el servidor procese nada. ¿Qué pasa si 10,000 usuarios acceden simultáneamente? ¿Y si el servidor en Ámsterdam cae?
La respuesta es una CDN — Content Delivery Network (Red de Distribución de Contenido). En el Capítulo 8 aprenderás:
- Qué es una CDN y cómo funciona (spoiler: son servidores en todo el mundo que guardan copias de tu contenido)
- Cloudflare CDN: cómo la misma Cloudflare que estamos usando para SSL también distribuye tu contenido globalmente
- AWS CloudFront: la CDN de Amazon Web Services, integrada con S3 y EC2
- Fastly: la CDN favorita de medios de comunicación y empresas de alta exigencia
- Cómo una CDN puede reducir la latencia de 200ms a 15ms para usuarios en cualquier continente
- Headers de caché, TTL, invalidación de caché, y el delicado arte de decidir qué se cachea y qué no
- Cómo las CDNs añaden una capa extra de protección DDoS (porque absorben el ataque en sus servidores distribuidos, no en el tuyo)
Las CDNs son la diferencia entre un sitio web que "funciona" y una infraestructura web que escala. Te vemos en el Capítulo 8.
Capítulo 7 — SSL/TLS: Cómo Internet protege la información
Libro: Arquitectura Web Moderna — De cero a una infraestructura profesional para Internet