¿Qué es HTTPS para desarrolladores?

Si alguna vez has trabajado montando una app web o una API, seguramente te enconctraste con la necesidad de usar HTTPS. Y aunque parece algo que simplemente “se activa”, detrás hay mucho más.

Este artículo está basado en la documentación oficial de FastAPI, pero está pensado para que cualquier desarrollador, sin importar el lenguaje o framework que uses, pueda entender cómo funciona HTTPS desde una perspectiva práctica. Sin meternos en detalles crípticos de criptografía, pero con suficiente profundidad para que sepas qué estás haciendo y por qué.

¿Para quién es esto?

Este artículo es ideal si:

• Eres desarrollador y quieres entender cómo usar HTTPS correctamente.
• No eres un experto en criptografía ni necesitas leer los estándares (RFCs).
• Quieres tener claro cómo proteger tu app con HTTPS sin volverte loco.

Entendiendo HTTPS: más que “poner el candadito”

Desde fuera, HTTPS puede parecer algo mágico:

• Compras un dominio.
• Lo conectas.
• Lo “activas”... y ya.

Pero como desarrollador, necesitas saber qué ocurre realmente bajo el capó. Vamos paso a paso.

1. ¿Qué es HTTPS exactamente?

HTTPS no es más que el protocolo HTTP funcionando dentro de una conexión segura, encriptada con TLS (Transport Layer Security). Esa encriptación es lo que evita que otros vean o manipulen la información que pasa entre tu cliente y tu servidor.

2. El papel de los certificados

Para establecer esa conexión segura, el servidor necesita un certificado HTTPS válido. Este certificado lo emite una autoridad confiable (como Let's Encrypt), y es lo que le dice al navegador: “Sí, este dominio es legítimo, puedes confiar”.

No generas tú mismo el certificado, lo obtienes de una entidad externa.

3. HTTPS ocurre antes de HTTP

Algo que puede sonar contraintuitivo: la seguridad de HTTPS no se maneja a nivel de HTTP, sino en una capa más baja: TCP.

Entonces:

• Antes de que tu app siquiera reciba una solicitud HTTP, el servidor ya ha hecho todo el trabajo de establecer una conexión segura.
• Esa negociación previa se llama el TLS handshake.

4. El problema con los dominios y las IPs

Aquí hay algo curioso: TCP trabaja con IPs, no con dominios. Pero los certificados HTTPS están asociados a dominios.

¿Entonces cómo se resuelve eso?

Con una extensión llamada SNI (Server Name Indication), que le permite al servidor saber qué dominio está solicitando el cliente, incluso antes de que llegue la parte HTTP. Así puede seleccionar el certificado adecuado.

5. ¿Y cómo se organiza todo esto?

En muchos despliegues modernos, todo esto se maneja con un componente llamado TLS Termination Proxy. Este es un programa que:

• Escucha en el puerto 443 (HTTPS).
• Se encarga del handshake TLS y de seleccionar el certificado correcto.
• Desencripta la solicitud.
• Reenvía esa solicitud HTTP en texto plano a tu aplicación (por ejemplo, a FastAPI).
• Recibe la respuesta de la app.
• La encripta de nuevo y la envía al cliente.

Algunos proxies que puedes usar para esto:

• Traefik (muy cómodo para certificados automáticos)
• Caddy (automático también)
• Nginx
• HAProxy

6. Let's Encrypt: HTTPS gratis y fácil

Antes, conseguir un certificado HTTPS era caro y engorroso. Pero hoy, gracias a Let's Encrypt, puedes tener certificados gratuitos, válidos y seguros, que se pueden renovar automáticamente.

¿La única condición? Que demuestres que realmente tienes control del dominio. Eso se puede hacer de varias formas:

• Cambiando registros DNS.
• Sirviendo un archivo en tu servidor durante el proceso de verificación.

Un recorrido paso a paso

Vamos a ver cómo fluye una solicitud HTTPS desde que el usuario escribe tu URL hasta que recibe una respuesta:

• Tienes un dominio (por ejemplo, someapp.example.com), y apuntas ese dominio a la IP pública de tu servidor usando un registro DNS.
• El navegador del usuario hace una consulta DNS para saber a qué IP conectarse.

• Se conecta a esa IP en el puerto 443 y arranca el TLS handshake.

• El servidor (es decir, tu TLS Termination Proxy) usa SNI para elegir el certificado correcto.
• Se establece una conexión segura.

• Ahora sí, el navegador manda la solicitud HTTPS (que es solo HTTP por dentro de una conexión encriptada).

• El proxy desencripta la solicitud y se la pasa a tu app FastAPI.

• La API responde en HTTP normal.

• El proxy encripta la respuesta y la devuelve al navegador.

• El navegador verifica que todo esté en orden, y listo, el usuario ve tu app web funcionando con el candadito en verde.

¿Y si tengo varias apps en el mismo servidor?

No hay problema. Aunque solo un proceso puede escuchar en el puerto 443 por IP, ese proceso puede manejar múltiples certificados y redirigir cada solicitud a la app que corresponde, según el dominio.

Por ejemplo:

• api.tuapp.com → FastAPI
• dashboard.tuapp.com → otra app (tal vez en PHP, Node.js, Flutter...)

El proxy se encarga de todo eso.

Renovación de certificados

Como los certificados vencen (cada 90 días, en el caso de Let's Encrypt), necesitas una manera de renovarlos automáticamente.

Lo ideal es que el mismo proxy (como Traefik o Caddy) se encargue de eso. Así no tienes que parar nada.

Si no usas un proxy que lo haga, tendrás que:

• Parar el proxy momentáneamente.
• Ejecutar el programa que renueva el certificado.
• Volver a levantar el proxy con los nuevos certificados.

No es lo ideal, pero se puede hacer. Aunque hoy en día, es mucho más común automatizar todo con herramientas modernas.