TLS Certificates: Secure Connections for AI

What this article covers

• Why TLS matters for your AI services
• What a TLS certificate is and how the handshake works
• How to get free certificates with Let’s Encrypt
• When self-signed certificates make sense
• How Certbot and mkcert simplify everyday tasks

Introduction

When you want to expose AI services like Ollama, Open WebUI, or an API endpoint on your own network or the internet, one topic comes up early: TLS. Without TLS, requests travel in plaintext across the network. Anyone on the same network can eavesdrop. This becomes especially critical when API keys, sensitive prompts, or model data are in transit.

TLS certificates ensure that your browser or client communicates securely with the server. The connection content is encrypted. Additionally, the client verifies that the certificate actually belongs to the domain being accessed. This creates trust between client and server.

This article is for you if you’re just starting to explore network security. We keep things practical and use technical terms in English like Certificate, Certificate Authority, and Handshake so you’ll recognize the same vocabulary in tools and documentation.

Why TLS matters for AI services

AI models and their APIs often handle private data. A chat conversation might contain personal information. An AI agent could access your files through a tool. If the connection isn’t encrypted, anyone on the network can read the traffic.

TLS protects the connection on three levels:

1. Confidentiality: Data is encrypted. Outsiders cannot read the content.
2. Integrity: Messages cannot be altered in transit without detection.
3. Authenticity: The client verifies that the certificate actually belongs to the domain being accessed.

Especially in self-hosting setups where you expose services like Ollama or Open WebUI across a network, you shouldn’t treat TLS as an optional extra. Even on a local network, it makes sense when multiple people or devices access these services. You’ll find more details in our guide to secure operations and the fundamentals of network security.

TLS explained briefly

TLS stands for Transport Layer Security. It’s the successor to SSL, though people still often call it SSL colloquially. When a website is accessible via HTTPS, TLS is at work underneath.

The core of TLS is a Certificate. This contains a Public Key and metadata such as the domain name, validity period, and issuer. It comes paired with a Private Key that stays only on the server.

When a client establishes a connection, a handshake occurs. The server presents its Certificate. The client checks it against a Trust Store. This Trust Store contains certificates from trusted Certificate Authorities like Let’s Encrypt. If everything matches, a symmetric session key is negotiated. After that, communication runs encrypted.

Important: TLS encrypts the connection, not the data stored on the server. If you store sensitive models or user data, you need additional measures like authentication and a solid firewall.

Who this article is for

This article is for beginners who want to operate AI services themselves. You don’t need deep cryptography knowledge. Basic familiarity with the terminal helps, since we’ll show some Bash commands.

This is for you if you:

• Want to expose AI tools like Ollama or Open WebUI on your network or the internet
• Own a domain or can register one
• Want to understand when Let’s Encrypt, self-signed certificates, or mkcert are appropriate
• Plan to set up a Reverse Proxy

If you haven’t encountered Reverse Proxies yet, it’s worth exploring. A Reverse Proxy simplifies TLS considerably.

Key terminology

Term	Explanation
Certificate	A digital file containing a Public Key and information about the owner.
Certificate Authority (CA)	A trusted entity that signs certificates and is stored in clients’ Trust Stores.
Public Key	The public key that the client uses to send encrypted data to the server.
Private Key	The secret key on the server. It must never be made public.
CSR	Certificate Signing Request. A request to a CA to sign a certificate.
Let’s Encrypt	A free Certificate Authority that issues certificates via the ACME protocol.
Certbot	An official CLI tool from Let’s Encrypt for requesting and renewing certificates.
mkcert	A tool for local development that creates a local CA and updates the Trust Store.
SSL	Older term for the predecessor technology to TLS. Often used synonymously in everyday speech.
ACME	Automatic Certificate Management Environment. Protocol for automated certificate issuance.

Let’s Encrypt: Free certificates

Let’s Encrypt is a Certificate Authority that issues free certificates for public domains. These certificates are included in the Trust Store of all major browsers and operating systems. This means your users won’t see a warning when they visit your HTTPS site.

Let’s Encrypt requires a public domain and a server reachable on port 80 or 443. Validation happens either via HTTP-01 or DNS-01. With HTTP-01, a specific token must be accessible at a defined URL. With DNS-01, you set a TXT record in your DNS zone. DNS-01 works especially well for wildcard certificates.

Certificates are valid for 90 days and must be renewed regularly. This is where Certbot comes in. Automated renewals are crucial so expiration doesn’t slip your mind.

Self-signed certificates

A self-signed certificate is one you create yourself, without a public CA. You become your own Certificate Authority. It’s free and works without a domain, but has a major drawback: browsers and clients don’t know your CA.

When a user visits your site, the browser shows a warning. For testing or internal services, you can accept the warning. Better yet, import your self-signed Root Certificate into the Trust Store of your clients. This is feasible on a local network with a few devices, but doesn’t scale for the public internet.

Self-signed certificates are practical for lab environments where you want to test HTTPS quickly. For production on the internet, they’re not suitable. Use Let’s Encrypt instead.

Certbot in Practice

Certbot is the official command-line tool for Let’s Encrypt. It handles validation, certificate creation, and renewal. On Debian and Ubuntu systems, the simplest installation method is through the package repository:

sudo apt update
sudo apt install certbot

To obtain a certificate for your own web server on port 80, use the Standalone option:

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

If you already have a web server like Nginx running, you can use the Nginx plugin instead:

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

Certbot stores certificates in /etc/letsencrypt/live. Your private key, certificate, and chain files are located there. To test automatic renewal, run a dry run:

sudo certbot renew --dry-run

On standard installations, Certbot sets up a cron job to renew certificates before expiration. If your setup uses a reverse proxy, ensure the proxy reloads the new files after renewal. Learn more about this in our article on the Nginx Proxy Manager.

mkcert for Local Development

mkcert is a small tool created by Filippo Valsorda. It generates a local Certificate Authority and installs it in your operating system’s trust store. This lets you use HTTPS locally without browser warnings.

Installation is available through your package manager or as a binary. On Ubuntu, install mkcert like this:

sudo apt install mkcert
mkcert -install

After installation, create a certificate for a local domain or IP address:

mkcert kiservice.local 192.168.1.42

You get two files as a result: the certificate named after your domain and the private key. You can integrate them into your local web server or reverse proxy. The benefit: your local system and browser trust the certificate because the local CA is installed in the trust store.

mkcert is perfect for development, but not suitable for public production systems. For those, stick with Let’s Encrypt and Certbot.

TLS at the Reverse Proxy

Many setups run a reverse proxy in front of the actual AI services. The proxy is the only service that needs a TLS certificate. Behind the proxy, AI services communicate unencrypted over HTTP. This simplifies configuration considerably.

Imagine you run Ollama on port 11434 and Open WebUI on port 8080. Both should be accessible via HTTPS. Instead of configuring a separate certificate for each service, you place a certificate on the reverse proxy. The proxy receives the HTTPS connection and forwards it internally.

For this setup, tools like the Nginx Proxy Manager are recommended. It provides a web interface to request certificates from Let’s Encrypt and assign domains. You can find additional basics in our article on Ollama Network Access.

Common Pitfalls

1. Certificate expires: If renewal fails, browsers report a security error. Regularly verify that Certbot renews your certificates.
2. Wrong domain validated: Let’s Encrypt checks whether your server is reachable under the specified hostname. A typo in the domain name causes validation to fail.
3. Mixed content: If your HTTPS page loads HTTP resources, browsers block them. Ensure all internal links use HTTPS as well.
4. Unprotected private key: The private key belongs in a directory with restricted permissions. Never copy it into a repository or public storage.
5. Forgot to restart Certbot: After renewal, your web server or proxy must restart to load the new certificate. Automate this step.
6. Self-signed certificate on the internet: Public visitors receive warnings and lose trust. Use Let’s Encrypt for public domains.
7. Port 80 blocked: HTTP-01 validation requires port 80 to be accessible. Firewalls or routers must allow this port through.

Hardware, Costs, and Security

Let’s Encrypt and Certbot are free. The only ongoing costs come from your domain and server. A basic VPS or home server is sufficient for most AI services.

Computationally intensive cryptography is supported by modern CPUs. TLS introduces barely noticeable delays as long as your server doesn’t handle thousands of connections per second. For the private key, never use an unencrypted hard drive if physical access is possible.

Backing up your private key is also important. If you lose it, you must issue a new certificate. Store it securely, for example in a password manager or encrypted backup. We also recommend familiarizing yourself with Firewall configuration to ensure only necessary ports are accessible.

Further Reading

• Secure Operation Overview
• Network Security
• Reverse Proxy
• Authentication
• Firewall
• Nginx Proxy Manager
• Ollama Network Access

FAQ

What is the difference between TLS and SSL?

SSL is the older technology. TLS is the current standard. In everyday usage, the terms are often mixed, but technically we refer to TLS today.

Do I need a domain for Let’s Encrypt?

Yes, Let’s Encrypt requires a public domain. For local tests without a domain, use mkcert or a self-signed certificate.

How much does a TLS certificate cost?

Let’s Encrypt is free. Commercial CAs charge based on certificate type. mkcert is also free for local development.

How often do I need to renew a Let’s Encrypt certificate?

The certificates are valid for 90 days. Certbot renews them automatically before expiration. A monthly check doesn’t hurt.

What is a CSR?

A CSR is a Certificate Signing Request. It contains your public key and applicant information. The CA signs the CSR and creates the certificate.

What happens if the private key is compromised?

You should revoke the certificate immediately and generate a new key pair. Anyone with the private key can impersonate your server.

Can I use a Let’s Encrypt certificate locally?

No, Let’s Encrypt requires a public domain. For local development, use mkcert.

What is the benefit of a wildcard certificate?

A wildcard certificate applies to all subdomains of a domain. It works well for multiple AI services running on different subdomains.

Does TLS run on the AI service or on the reverse proxy?

Both are possible. In practice, the certificate often sits on the Reverse Proxy so AI services don’t need individual configuration.

Are self-signed certificates secure?

The encryption strength is identical to that of public CAs. The difference comes down to trust. Browsers warn you because they don’t recognize the CA.

What is ACME?

ACME stands for Automatic Certificate Management Environment. It’s the protocol that Certbot and Let’s Encrypt use to issue and renew certificates.

Sources

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