Certificados TLS: Conexiones seguras para IA

Qué encontrarás en este artículo

• Por qué TLS es fundamental para tus servicios de IA
• Qué es un certificado TLS y cómo funciona el handshake
• Cómo obtener certificados gratuitos con Let’s Encrypt
• Cuándo tienen sentido los certificados autofirmados
• Cómo Certbot y mkcert simplifican el trabajo diario

Introducción

Cuando quieres poner servicios de IA como Ollama, Open WebUI o un endpoint de API accesible en tu red local o en internet, surge temprano un tema crucial: TLS. Sin TLS, las solicitudes viajan sin cifrar a través de la red. Cualquiera en la misma red puede interceptarlas. Esto es especialmente crítico cuando se transmiten claves de API, prompts sensibles o datos de modelos.

Los certificados TLS garantizan que tu navegador o cliente se comunique de forma segura con el servidor. El contenido de la conexión se cifra. Además, el cliente verifica que el certificado pertenece realmente al dominio solicitado. Así se establece confianza entre cliente y servidor.

Este artículo está dirigido a quien apenas se está adentrando en seguridad de redes. Mantenemos un enfoque práctico y usamos términos técnicos en inglés como Certificate, Certificate Authority y Handshake, para que encuentres los mismos conceptos en herramientas y documentación.

Por qué TLS es importante para servicios de IA

Los modelos de IA y sus APIs suelen procesar datos privados. Una conversación puede contener información personal. Un agente de IA podría acceder a tus archivos a través de una herramienta. Si la conexión no está cifrada, cualquiera en la red puede leer el tráfico.

TLS protege la conexión en tres niveles:

1. Confidencialidad: Los datos se cifran. Los terceros no pueden leer el contenido.
2. Integridad: Los mensajes no pueden modificarse sin ser detectados durante la transmisión.
3. Autenticidad: El cliente verifica que el certificado pertenece realmente al dominio solicitado.

Especialmente en configuraciones de auto-alojamiento, donde expones servicios como Ollama u Open WebUI a través de una red, no debes considerar TLS como un extra opcional. Incluso en la red local puede ser útil cuando múltiples personas o dispositivos acceden a estos servicios. Más información en nuestra guía sobre operación segura y los fundamentos de seguridad en redes.

TLS explicado brevemente

TLS significa Transport Layer Security. Es el protocolo sucesor de SSL, aunque en la práctica aún se suele llamar SSL. Cuando un sitio web es accesible por HTTPS, subyace TLS.

El corazón de TLS es un Certificate. Este contiene una Public Key y metadatos como el nombre de dominio, período de validez y emisor. Incluye una Private Key que permanece únicamente en el servidor.

Cuando un cliente establece una conexión, ocurre un Handshake. El servidor presenta su Certificate. El cliente lo verifica contra un Trust Store. Este Trust Store contiene certificados de Certificate Authorities confiables como Let’s Encrypt. Si todo coincide, se negocia una clave de sesión simétrica. Después, la comunicación ocurre cifrada.

Importante: TLS cifra la conexión, no los datos almacenados en el servidor. Si guardas modelos sensibles o datos de usuarios, necesitas medidas adicionales como autenticación y un buen firewall.

A quién va dirigido este artículo

Este artículo es para principiantes que desean operar servicios de IA por su cuenta. No necesitas conocimientos profundos de criptografía. Comprensión básica de la terminal ayuda, porque mostraremos algunos comandos Bash.

Este texto es para ti si:

• Quieres hacer accesibles herramientas de IA como Ollama u Open WebUI en tu red o en internet
• Tienes un dominio propio o puedes registrar uno
• Deseas entender cuándo son apropiados Let’s Encrypt, certificados autofirmados o mkcert
• Planeas configurar un Reverse Proxy

Si aún no conoces bien los Reverse Proxies, vale la pena echarles un vistazo. Un Reverse Proxy simplifica enormemente TLS.

Términos clave

Término	Explicación
Certificate	Un archivo digital que contiene una Public Key e información sobre el propietario.
Certificate Authority (CA)	Una entidad confiable que firma certificados y se encuentra en el Trust Store de los clientes.
Public Key	La clave pública que el cliente usa para enviar datos cifrados al servidor.
Private Key	La clave secreta en el servidor. Nunca debe hacerse pública.
CSR	Certificate Signing Request. Una solicitud a una CA para firmar un certificado.
Let’s Encrypt	Una Certificate Authority gratuita que emite certificados a través del protocolo ACME.
Certbot	La herramienta CLI oficial de Let’s Encrypt para solicitar y renovar certificados.
mkcert	Una herramienta para desarrollo local que crea una CA local y actualiza el Trust Store.
SSL	Término antiguo para la tecnología predecesora de TLS. A menudo se usa sinónimamente en la práctica.
ACME	Automatic Certificate Management Environment. Protocolo para la emisión automática de certificados.

Let’s Encrypt: Certificados gratuitos

Let’s Encrypt es una Certificate Authority que emite certificados gratuitos para dominios públicos. Los certificados están incluidos en el Trust Store de todos los navegadores y sistemas operativos comunes. Esto significa que tus usuarios no verán advertencias cuando visiten tu sitio HTTPS.

Let’s Encrypt requiere un dominio público y un servidor accesible en el puerto 80 o 443. La validación ocurre mediante HTTP-01 o DNS-01. Con HTTP-01, un token específico debe estar disponible en una URL definida. Con DNS-01, debes establecer un registro TXT en tu zona DNS. DNS-01 es especialmente adecuado para certificados Wildcard.

Los certificados son válidos por 90 días y deben renovarse regularmente. Aquí es donde entra Certbot. Las renovaciones automatizadas son importantes para evitar que expiren.

Certificados autofirmados

Un certificado autofirmado lo creas por ti mismo, sin una CA pública. Eres tu propia Certificate Authority. Es gratuito y funciona sin dominio, pero tiene una gran desventaja: los navegadores y clientes no conocen tu CA.

Cuando un usuario accede a tu sitio, el navegador muestra una advertencia. Para pruebas o servicios internos, puedes aceptar la advertencia. Lo ideal es importar tu certificado Root autofirmado en el Trust Store de los clientes. Esto es factible en una red local con pocos dispositivos, pero no escala para internet público.

Los certificados autofirmados son prácticos para entornos de laboratorio donde quieres probar HTTPS rápidamente. Para producción en internet no son adecuados. Usa Let’s Encrypt en su lugar.

Certbot en la práctica

Certbot es la herramienta de línea de comandos oficial de Let’s Encrypt. Se encarga de la validación, creación y renovación de certificados. En sistemas Debian y Ubuntu, la forma más sencilla de instalarlo es a través del repositorio:

sudo apt update
sudo apt install certbot

Para un servidor web propio en el puerto 80, obtienes un certificado con la opción Standalone:

sudo certbot certonly --standalone -d kiservice.dein-domain.de

Si ya ejecutas un servidor web como Nginx, puedes usar el plugin de Nginx:

sudo certbot --nginx -d kiservice.dein-domain.de

Certbot almacena los certificados en /etc/letsencrypt/live. La clave privada, el certificado y los archivos de cadena se encuentran allí. Para probar la renovación automática, ejecuta un dry run:

sudo certbot renew --dry-run

En instalaciones estándar, Certbot configura un cronjob que renueva los certificados antes de que caduquen. Si tu configuración usa un reverse proxy, asegúrate de que el proxy cargue los nuevos archivos después de una renovación. Encontrarás más información en nuestro artículo sobre Nginx Proxy Manager.

mkcert para desarrollo local

mkcert es una pequeña herramienta de Filippo Valsorda. Genera una autoridad de certificados local e la instala en el almacén de confianza de tu sistema operativo. Con esto, puedes usar HTTPS localmente sin advertencias del navegador.

La instalación se realiza a través del gestor de paquetes o como binario. En Ubuntu, instala mkcert así:

sudo apt install mkcert
mkcert -install

Luego creas un certificado para un dominio local o dirección IP:

mkcert kiservice.local 192.168.1.42

El resultado son dos archivos: el certificado con el nombre del dominio y la clave privada. Puedes integrarlos en tu servidor web local o reverse proxy. La ventaja: tu sistema local y el navegador confían en el certificado porque la CA local está registrada en el almacén de confianza.

mkcert es ideal para desarrollo, pero no para sistemas de producción públicos. Para esos casos, sigues usando Let’s Encrypt y Certbot.

TLS en el reverse proxy

En muchas configuraciones, un reverse proxy se ejecuta frente a los servicios de IA reales. El proxy es el único servicio que necesita un certificado TLS. Detrás del proxy, los servicios de IA se comunican sin cifrar mediante HTTP. Esto simplifica considerablemente la configuración.

Imagina que ejecutas Ollama en el puerto 11434 y Open WebUI en el puerto 8080. Ambos deben ser accesibles mediante HTTPS. En lugar de configurar un certificado separado para cada servicio, colocas un certificado en el reverse proxy. El proxy recibe la conexión HTTPS y la reenvía internamente.

Para esta configuración, herramientas como Nginx Proxy Manager son muy recomendables. Ofrecen una interfaz gráfica para solicitar certificados de Let’s Encrypt y asignar dominios. Encontrarás más fundamentos en nuestro artículo sobre acceso a la red de Ollama.

Tropiezos comunes

1. El certificado caduca: Si la renovación no funciona, los navegadores reportan un error de seguridad. Verifica regularmente que Certbot renueve los certificados.
2. Dominio validado incorrectamente: Let’s Encrypt comprueba que tu servidor sea accesible para el nombre de host especificado. Un error tipográfico en el dominio causa un fallo.
3. Contenido mixto: Si tu página HTTPS carga recursos HTTP, los navegadores los bloquean. Asegúrate de que todos los enlaces internos también usen HTTPS.
4. Clave privada desprotegida: La clave privada debe estar en un directorio con permisos restringidos. Nunca la copies a un repositorio o almacenamiento público.
5. Reinicio de Certbot olvidado: Después de una renovación, el servidor web o proxy debe reiniciarse para cargar el nuevo certificado. Automatiza este paso.
6. Certificado autofirmado en Internet: Los visitantes públicos reciben advertencias y pierden confianza. Usa Let’s Encrypt para dominios públicos.
7. Puerto 80 bloqueado: Para la validación HTTP-01, el puerto 80 debe ser accesible. Los firewalls o routers deben permitir este puerto.

Hardware, costos y seguridad

Let’s Encrypt y Certbot son gratuitos. Los únicos costos recurrentes provienen del dominio y el servidor. Un VPS simple o un servidor casero son suficientes para la mayoría de los servicios de IA.

La criptografía computacionalmente intensiva es compatible con las CPUs modernas. TLS añade apenas retrasos perceptibles, siempre que tu servidor no procese miles de conexiones por segundo. Para la clave privada, nunca uses un disco duro sin cifrado si es posible el acceso físico.

También es importante hacer una copia de seguridad de la clave privada. Si la pierdes, debes emitir un nuevo certificado. Almacénala de forma segura, por ejemplo en un gestor de contraseñas o una copia de seguridad cifrada. Además, te recomendamos que te familiarices con el tema de Firewall para asegurar que solo los puertos necesarios sean accesibles.

Enlaces relacionados

• Operación segura en general
• Seguridad de red
• Reverse proxy
• Autenticación
• Firewall
• Nginx Proxy Manager
• Acceso a la red de Ollama

Preguntas frecuentes

¿Cuál es la diferencia entre TLS y SSL?

SSL es la tecnología más antigua. TLS es el estándar actual. En el lenguaje cotidiano, ambos se suelen mezclar, pero técnicamente hoy se habla de TLS.

¿Necesito un dominio para Let’s Encrypt?

Sí, Let’s Encrypt requiere un dominio público. Para pruebas locales sin dominio, mkcert o un certificado autofirmado son las opciones adecuadas.

¿Cuánto cuesta un certificado TLS?

Let’s Encrypt es gratuito. Las autoridades de certificación comerciales cobran dependiendo del tipo de certificado. mkcert también es gratuito para desarrollo local.

¿Con qué frecuencia debo renovar un certificado de Let’s Encrypt?

Los certificados son válidos por 90 días. Certbot los renueva automáticamente antes de que caduquen. Una verificación mensual no está de más.

¿Qué es un CSR?

Un CSR es una Certificate Signing Request. Contiene tu clave pública e información sobre el solicitante. La CA firma el CSR y crea el certificado.

¿Qué sucede si la clave privada se pierde?

Entonces debes revocar el certificado inmediatamente y generar un nuevo par de claves. Cualquiera que posea la clave privada puede hacerse pasar por tu servidor.

¿Puedo usar un certificado de Let’s Encrypt localmente?

No, Let’s Encrypt requiere un dominio público. Para desarrollo local, usa mkcert.

¿Cuál es la ventaja de un certificado comodín?

Un certificado comodín es válido para todos los subdominios de un dominio. Es ideal para muchos servicios de IA que se ejecutan en diferentes subdominios.

¿Se ejecuta TLS en el servicio de IA o en el reverse proxy?

Ambos son posibles. En la práctica, el certificado suele estar en el reverse proxy, para que los servicios de IA no tengan que configurarse individualmente.

¿Son seguros los certificados autofirmados?

La encriptación es igual de fuerte que la de las autoridades públicas. La diferencia radica en la confianza. Los navegadores advierten porque no reconocen la CA.

¿Qué es ACME?

ACME significa Automatic Certificate Management Environment. Es el protocolo que utilizan Certbot y Let’s Encrypt para emitir y renovar certificados.

Fuentes

1. Let’s Encrypt - https://letsencrypt.org/docs/
2. Certbot Documentación - https://eff-certbot.readthedocs.io/
3. mkcert GitHub-Repository - https://github.com/FiloSottile/mkcert
4. IETF TLS 1.3 Spezifikation - https://datatracker.ietf.org/doc/html/rfc8446