# SSL, TLS y certificados: cómo funciona HTTPS

**Categoría:** Desarrollo web · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/desarrollo-web/ssl-tls-certificados-y-https/

## Respuesta rápida

**HTTPS** es HTTP dentro de una conexión cifrada con **TLS**. Protege tres cosas: la **confidencialidad** —nadie en el camino lee lo que viaja—, la **integridad** —nadie lo modifica— y la **autenticidad del nombre** —quien responde controla ese dominio—. Lo que **no** prueba es que el sitio sea honesto ni que sus datos estén seguros. **SSL** es el nombre del protocolo viejo, obsoleto desde hace años; el vigente es TLS, aunque todos sigan diciendo «certificado SSL». Los certificados hoy se emiten y renuevan solos con **ACME** —los de Let’s Encrypt duran **90 días** y se renuevan a los 60—, y su vigencia máxima se está acortando por calendario: de 398 días bajó a **200** en marzo de 2026 y llegará a **47** en 2029.

## Qué protege y qué no

Empecemos por acá porque es donde está el malentendido más extendido. Una conexión HTTPS garantiza tres propiedades:

1. **Confidencialidad** Nadie entre tu navegador y el servidor puede leer lo que viaja: ni el wifi del bar, ni el proveedor de internet, ni quien esté en el medio.
2. **Integridad** Nadie puede modificar el contenido sin que se note. Sin esto, un intermediario puede inyectar publicidad o código en cualquier página.
3. **Autenticidad del nombre** Quien responde **controla ese dominio**. Eso, y nada más que eso.

> **Atención**
>
> No dice que el sitio sea **honesto**: un sitio de estafa con certificado válido muestra el mismo candado que un banco. No dice que la empresa sea **confiable**. No dice que tus datos estén **seguros una vez que llegan**: protege el viaje, no el destino. Y no protege contra nada que pase **dentro** del sitio, como una vulnerabilidad en el código.

El blog de Underc0de documentó un caso que lo ilustra bien: [Microsoft revocó doscientos certificados usados en una campaña de ransomware](https://blog.underc0de.org/microsoft-bloquea-ataques-de-ransomware-rhysida-tras-revocar-200-certificados-falsos-de-teams/). Eran certificados *válidos*, emitidos correctamente, y por eso funcionaban.

Dicho eso, HTTPS dejó de ser opcional: los navegadores marcan como no seguros los sitios sin cifrado, varias funciones del navegador solo están disponibles con conexión segura, y [WordPress](../wordpress-desde-cero/index.md) lo declara requerido en todas sus instalaciones.

## SSL o TLS: el nombre viejo

**SSL** fue el protocolo original de los años noventa. Todas sus versiones están obsoletas y desactivadas por inseguras. Su reemplazo se llama **TLS**, y la versión vigente es **TLS 1.3**, definida en el RFC 8446.

Que todo el mundo siga diciendo «certificado SSL» es una costumbre heredada, y no genera problemas mientras se entienda que **el certificado no es ni SSL ni TLS**: el certificado es un documento, y TLS es el protocolo que lo usa. La única situación donde la distinción importa de verdad es al configurar un servidor, donde hay que **desactivar las versiones viejas** y dejar TLS 1.2 y 1.3.

## Qué es un certificado

Un **certificado** es un archivo firmado que dice, en esencia: «la clave pública tal corresponde al nombre tal, y yo, autoridad certificadora, lo verifiqué». El navegador confía en él porque confía en la autoridad que lo firmó, y esa confianza viene preinstalada: cada sistema y cada navegador traen una lista de autoridades raíz reconocidas.

De ahí sale la **cadena de confianza**: tu certificado está firmado por un certificado intermedio, que a su vez está firmado por una raíz que el navegador ya conoce. El servidor tiene que enviar tu certificado **y los intermedios**; si falta un eslabón, algunos navegadores lo resuelven solos y otros no, y aparece el clásico «funciona en mi computadora pero no en el celular».

## Los tipos de validación

| Tipo | Qué verifica | Cómo y cuánto |
|---|---|---|
| **De dominio (DV)** | Solo que controlás el nombre | Automática, en segundos, **gratis** |
| De organización (OV) | Además, datos de la empresa | Trámite manual, días, pago |
| Extendida (EV) | Verificación más estricta de la entidad | Trámite más largo, más caro |

Hay un dato que cambia por completo la decisión de compra: **los navegadores ya no muestran ninguna diferencia visual entre los tres**. La barra verde con el nombre de la empresa, que era el argumento de venta de la validación extendida, se eliminó hace años. Para quien visita el sitio, el candado es idéntico.

La conclusión práctica: **para la enorme mayoría de los sitios, un certificado de validación de dominio gratuito y automático es la opción correcta**. Los otros dos tienen sentido en contextos donde algún requisito contractual o regulatorio los exija.

## Emisión y renovación automáticas

El cambio que hizo que HTTPS se volviera universal no fue técnico sino de proceso: **ACME**, el protocolo que permite pedir, validar y renovar certificados sin intervención humana. El flujo tiene cuatro pasos:

1. **El cliente pide el certificado** Un programa en tu servidor le solicita a la autoridad un certificado para tu dominio.
2. **La autoridad plantea un desafío** «Demostrame que controlás ese nombre.»
3. **El cliente lo resuelve** Publicando un archivo en una ruta del sitio, o un registro `TXT` en el [DNS](../como-funciona-el-dns/index.md).
4. **La autoridad emite** Verifica el desafío y firma el certificado. Todo el proceso dura segundos.

Sobre **Let’s Encrypt**, que es la autoridad gratuita más usada, conviene conocer cuatro datos de su documentación:

- Los certificados por defecto son válidos por **90 días**, y se recomienda renovarlos **cada 60**.
- Existe además una opción de certificados de **seis días**, con renovación recomendada cada tres.
- Los certificados **comodín** —que cubren todos los subdominios— **deben usar el desafío por DNS**.
- Las autorizaciones ya validadas se guardan **hasta 30 días**, así que las renovaciones siguientes pueden saltear la validación.

Y una recomendación operativa de la propia documentación: los clientes ACME hacen las renovaciones **en horarios aleatorios** para evitar picos de tráfico. Si automatizás una renovación con un temporizador propio, conviene no ponerla a medianoche en punto.

## La vigencia se está acortando

Esta es la novedad que más va a afectar a quien todavía renueva a mano. En abril de 2025, el **CA/Browser Forum** —el organismo donde autoridades y navegadores acuerdan las reglas— aprobó un calendario que reduce la vigencia máxima de los certificados **de 398 días a 47**, en etapas:

| Desde | Vigencia máxima | Qué implica |
|---|---|---|
| Hasta el 14 de marzo de 2026 | 398 días | El esquema histórico: renovar una vez al año |
| **15 de marzo de 2026** | **200 días** | **Ya vigente.** Dos renovaciones al año |
| 15 de marzo de 2027 | 100 días | Cuatro renovaciones al año |
| 15 de marzo de 2029 | **47 días** | Ocho renovaciones al año: inviable a mano |

La dirección es clara y no va a revertirse: **la renovación manual deja de ser una opción**. Si hoy tenés un certificado que renovás una vez al año con un recordatorio en el calendario, ese proceso va a fallar. El momento de automatizarlo es antes de que la vigencia baje otro escalón, no el día que el sitio aparezca con la advertencia de certificado vencido.

Conviene además configurar **un aviso independiente** que verifique desde afuera cuántos días le quedan al certificado. La automatización también se rompe, y lo hace en silencio.

## HSTS y la redirección

Tener certificado no alcanza: hay que asegurarse de que nadie llegue por HTTP. Dos capas:

La **redirección** permanente de HTTP a HTTPS es lo mínimo, y resuelve el caso de quien escribe la dirección sin prefijo. Su límite es que **la primera petición sigue viajando sin cifrar**, y ahí hay una ventana para un intermediario.

**HSTS** cierra esa ventana. Es una cabecera que le dice al navegador «para este dominio, usá HTTPS siempre, aunque el usuario escriba otra cosa». El navegador la recuerda durante el tiempo indicado y ni siquiera intenta la conexión insegura.

```text
Strict-Transport-Security: max-age=31536000; includeSubDomains

  max-age            un año, en segundos
  includeSubDomains  aplica también a todos los subdominios
```

> **Atención**
>
> Una vez que el navegador guardó la instrucción, la respeta durante todo el plazo **aunque quites la cabecera**. Si activás `includeSubDomains` y algún subdominio no tiene certificado, ese subdominio queda inaccesible para quien ya visitó el sitio, y no hay forma de arreglarlo del lado del servidor. Conviene empezar con un plazo corto, verificar que todos los subdominios funcionen con HTTPS, y recién entonces subirlo.

## Los cuatro errores del navegador

Casi todas las advertencias de certificado son una de estas cuatro:

| Síntoma | Causa | Solución |
|---|---|---|
| Certificado vencido | La renovación automática falló y nadie se enteró | Renovar y agregar un aviso externo de vencimiento |
| El nombre no coincide | El certificado es para `underc0de.org` y entraron por `www.underc0de.org` | Emitirlo para ambos nombres |
| Cadena incompleta | El servidor no envía los certificados intermedios | Configurar la cadena completa. Funciona en un navegador y falla en otro |
| **Contenido mixto** | La página es HTTPS pero carga una imagen o un script por HTTP | Corregir esas URLs. El navegador bloquea los scripts |

El **contenido mixto** es el más molesto porque el sitio parece funcionar: el candado desaparece o aparece tachado, y algunos recursos no cargan sin explicación visible. Aparece siempre después de migrar un sitio de HTTP a HTTPS, cuando quedan direcciones absolutas escritas en la base de datos o en el contenido.

Para verificar todo esto de una vez, conviene usar un analizador externo de configuración TLS: revisa la cadena, las versiones de protocolo habilitadas y los cifrados en un solo informe.

> Si el sitio pasa por un intermediario, el certificado se parte en dos tramos y aparece una configuración que conviene conocer antes de tocarla: está en [qué es Cloudflare y cómo configurarlo](../que-es-cloudflare-y-como-configurarlo/index.md). Y para limitar qué autoridades pueden emitir certificados a tu nombre, el registro `CAA` se explica en [cómo funciona el DNS](../como-funciona-el-dns/index.md).

## Errores frecuentes

- **Pagar por validación extendida esperando que se note.** Los navegadores ya no la distinguen visualmente.
- **Renovar a mano.** Con 200 días ya es incómodo; con 47 será inviable.
- **No monitorear el vencimiento desde afuera.** La automatización falla en silencio.
- **Emitir solo para el dominio sin `www`.** O al revés. Conviene incluir ambos.
- **Olvidar los intermedios.** Funciona en tu navegador y falla en otros dispositivos.
- **Activar HSTS con subdominios sin comprobarlos.** Deja subdominios inaccesibles y no se puede revertir rápido.
- **Migrar a HTTPS y dejar direcciones absolutas viejas.** Contenido mixto y candado roto.
- **Dejar habilitadas versiones viejas del protocolo.** Se desactivan una vez y se olvidan.

## Preguntas frecuentes

**¿Qué garantiza realmente el candado del navegador?**
Tres cosas: que nadie en el camino puede leer lo que viaja, que nadie puede modificarlo sin que se note, y que quien responde controla ese dominio. Nada más. No garantiza que el sitio sea honesto, que la empresa sea confiable ni que tus datos estén protegidos una vez que llegan al servidor: protege el viaje, no el destino. Un sitio de estafa con un certificado válido muestra exactamente el mismo candado que un banco, y por eso el candado nunca fue un indicador de legitimidad.

**¿Cuál es la diferencia entre SSL y TLS?**
SSL es el protocolo original de los años noventa y todas sus versiones están obsoletas y desactivadas por inseguras. TLS es su reemplazo, y la versión vigente es TLS 1.3. Que todo el mundo siga diciendo «certificado SSL» es una costumbre heredada que no genera problemas mientras se entienda que el certificado no es ni SSL ni TLS: el certificado es un documento y TLS es el protocolo que lo usa. La distinción importa al configurar un servidor, donde hay que desactivar las versiones viejas y dejar TLS 1.2 y 1.3.

**¿Conviene pagar por un certificado?**
Para la enorme mayoría de los sitios, no. Un certificado de validación de dominio es gratuito, se emite en segundos, se renueva solo y cifra exactamente igual que uno pago: la fortaleza criptográfica no depende del precio. La validación de organización y la extendida verifican además datos de la empresa, pero los navegadores dejaron de mostrar cualquier distinción visual entre los tipos, así que para quien visita el sitio el candado es idéntico. Tienen sentido solo si algún requisito contractual o regulatorio los exige.

**¿Por qué los certificados duran cada vez menos?**
Porque una vigencia corta limita el daño de una clave comprometida y reduce la dependencia de los mecanismos de revocación, que funcionan mal. El CA/Browser Forum aprobó un calendario que baja la vigencia máxima de 398 días a 47: desde el 15 de marzo de 2026 son 200 días, desde marzo de 2027 serán 100 y desde marzo de 2029, 47. La consecuencia práctica es que la renovación manual deja de ser viable y la automatización pasa de ser una comodidad a ser un requisito.

**¿Qué es el contenido mixto y por qué rompe el candado?**
Es una página servida por HTTPS que carga algún recurso por HTTP: una imagen, una hoja de estilos, un script. Rompe la garantía, porque ese recurso viaja sin cifrar y puede ser modificado en el camino; si es un script, el atacante puede ejecutar código en tu página. Por eso los navegadores bloquean los scripts inseguros y quitan o tachan el candado. Aparece casi siempre después de migrar un sitio a HTTPS, cuando quedan direcciones absolutas viejas guardadas en la base de datos o en el contenido.

**¿Qué es HSTS y qué precaución hay que tener?**
Es una cabecera que le indica al navegador que para ese dominio use HTTPS siempre, incluso si la persona escribe la dirección sin prefijo, lo que cierra la ventana insegura de la primera petición. La precaución es que no se puede deshacer rápido: el navegador respeta la instrucción durante todo el plazo indicado aunque quites la cabecera. Si además activás la opción que incluye los subdominios y alguno no tiene certificado, ese subdominio queda inaccesible. Conviene empezar con un plazo corto y subirlo después de verificar.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, blog.** [Microsoft bloquea ataques de ransomware Rhysida tras revocar 200 certificados falsos](https://blog.underc0de.org/microsoft-bloquea-ataques-de-ransomware-rhysida-tras-revocar-200-certificados-falsos-de-teams/), 16 de octubre de 2025. Un certificado válido no prueba buenas intenciones.
2. **Underc0de, foro.** [Sección Seguridad web y en servidores](https://underc0de.org/foro/seguridad-en-servidores/). Configuración y diagnóstico de servidores expuestos.

### Documentación oficial

1. **Let’s Encrypt.** [FAQ](https://letsencrypt.org/docs/faq/). Vigencia de 90 días con renovación recomendada a los 60, la opción de seis días, el desafío DNS para comodines y la caché de autorizaciones, citados en esta guía.
2. **CA/Browser Forum.** [Ballot SC081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), 11 de abril de 2025. El calendario de reducción de la vigencia máxima de 398 a 47 días entre marzo de 2026 y marzo de 2029.
3. **IETF.** [RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446). La versión vigente del protocolo.
4. **IETF.** [RFC 8555: Automatic Certificate Management Environment (ACME)](https://www.rfc-editor.org/rfc/rfc8555). El protocolo que permite emitir y renovar certificados sin intervención humana.
5. **Mozilla.** [SSL Configuration Generator](https://ssl-config.mozilla.org/). Configuraciones recomendadas para los servidores web más usados.

## Guías relacionadas

- [Cómo funciona el DNS](../como-funciona-el-dns/index.md)
- [Cloudflare](../que-es-cloudflare-y-como-configurarlo/index.md)
- [Hosting](../tipos-de-hosting-web-y-como-elegir/index.md)
- [Cadena de suministro](../../devops-cloud/seguridad-de-la-cadena-de-suministro-de-software/index.md)
- [Índice de Desarrollo web](../index.md)