4. TLS/SSL加密通信：自签名证书生成、配置HTTPS、强制加密传输、证书管理最佳实践

说实话，很多人在部署Ollama时，最容易被忽略的就是通信加密。我见过不少团队，API端口直接裸奔在公网上，模型数据明文传输——想想都后怕。今天咱们就把这块彻底讲透。

4.1 为什么必须上TLS？

Ollama默认监听127.0.0.1:11434，只允许本地访问。但一旦你把它暴露到局域网或公网，问题就来了：

  • API请求中的提示词（prompt）和模型输出都是明文
  • 攻击者可以中间人攻击，篡改你的推理请求
  • 敏感数据（比如企业文档、代码片段）完全暴露

嗯，说白了，没有TLS的Ollama就像没锁门的服务器。我在一次客户审计中就遇到过，对方直接抓包看到了所有对话内容——场面一度非常尴尬。

⚠️ 重要提醒： 即使在内网环境，也建议启用TLS。内网不等于安全，ARP欺骗、DNS劫持这些攻击手段，在内网同样有效。

4.2 自签名证书生成

生产环境当然推荐用CA签发的证书。但开发测试、内部使用场景下，自签名证书完全够用。我个人的习惯是，先用自签名证书跑通流程，再替换成正式证书。

4.2.1 生成CA根证书

# 生成CA私钥
openssl genrsa -out ca.key 4096

# 生成CA根证书（有效期10年）
openssl req -x509 -new -nodes -key ca.key \
  -sha256 -days 3650 \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=MyCA" \
  -out ca.crt

4.2.2 生成服务器证书

# 生成服务器私钥
openssl genrsa -out server.key 2048

# 生成证书签名请求（CSR）
openssl req -new -key server.key \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=ollama.example.com" \
  -out server.csr

# 创建配置文件（重要！）
cat > server.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = ollama.example.com
DNS.2 = localhost
IP.1 = 192.168.1.100
IP.2 = 127.0.0.1
EOF

# 用CA签发服务器证书
openssl x509 -req -in server.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out server.crt -days 365 \
  -sha256 -extfile server.ext
💡 我的经验： 一定要在subjectAltName里加上IP地址和所有可能的域名。我曾经漏掉了内网IP，结果客户端连接时证书校验失败，排查了半天才发现是SAN没配全。

4.3 配置Ollama启用HTTPS

Ollama本身不直接支持TLS配置，但我们可以用反向代理来实现。我个人推荐Nginx，轻量、稳定、配置简单。

4.3.1 Nginx反向代理配置

# /etc/nginx/sites-available/ollama
server {
    listen 443 ssl http2;
    server_name ollama.example.com;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
    
    # 安全配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    
    # 强制HSTS（可选）
    add_header Strict-Transport-Security "max-age=63072000" always;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # WebSocket支持（Ollama流式输出需要）
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# HTTP重定向到HTTPS
server {
    listen 80;
    server_name ollama.example.com;
    return 301 https://$server_name$request_uri;
}

4.3.2 启动并验证

# 检查配置
nginx -t

# 重启Nginx
systemctl restart nginx

# 验证HTTPS
curl -k https://ollama.example.com/api/tags

# 用CA证书验证（推荐）
curl --cacert ca.crt https://ollama.example.com/api/tags
🔑 关键点： 生产环境不要用 -k 参数跳过验证。把ca.crt分发给所有客户端，用 --cacert 指定CA证书才是正确做法。

4.4 强制加密传输

光配好HTTPS还不够，你得确保所有流量都走加密通道。我见过有人配了443端口，但11434端口还开着——等于白配。

4.4.1 防火墙规则

# 只允许Nginx端口
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 11434 -j DROP

# 或者用ufw
ufw allow 443/tcp
ufw deny 11434/tcp

4.4.2 客户端强制使用HTTPS

在客户端代码中，直接写死https://，不要留任何http的退路。比如Python客户端：

import requests

# 正确做法
response = requests.post(
    "https://ollama.example.com/api/generate",
    json={"model": "llama2", "prompt": "Hello"},
    verify="ca.crt"  # 验证服务端证书
)

# 错误做法——绝对不要用
# response = requests.post("http://ollama.example.com:11434/api/generate")

4.5 证书管理最佳实践

证书管理是个细活，搞不好比不加密还危险。我总结了几条铁律：

实践 说明 我的建议
证书有效期 自签名证书建议1年，CA证书3-5年 设个日历提醒，提前1个月续期
私钥保护 私钥文件权限设为600，定期更换 用HSM或密钥管理服务存储
证书吊销 维护CRL或OCSP响应器 小团队用CRL就够了
自动续期 用acme.sh或certbot自动化 生产环境强烈推荐
证书监控 监控证书过期时间 Prometheus + Blackbox Exporter

4.5.1 自动化续期脚本

#!/bin/bash
# renew_cert.sh - 每月执行一次

CERT_DIR="/etc/ssl/certs"
KEY_DIR="/etc/ssl/private"
DAYS_LEFT=$(openssl x509 -in $CERT_DIR/server.crt -noout -enddate | cut -d= -f2)

# 如果证书在30天内过期，重新生成
if [ $(date -d "$DAYS_LEFT" +%s) -lt $(date -d "+30 days" +%s) ]; then
    echo "证书即将过期，重新生成..."
    
    # 重新生成证书（复用之前的步骤）
    openssl genrsa -out $KEY_DIR/server.key 2048
    # ... 省略中间步骤 ...
    
    # 重启Nginx
    systemctl reload nginx
    
    echo "证书已更新，Nginx已重载"
else
    echo "证书有效期充足，无需更新"
fi
💡 自动化小技巧： 把这个脚本放到crontab里，每月1号执行。再配合Prometheus告警，证书过期前7天发邮件通知——双重保险。

4.6 整体架构图

下面这张图展示了完整的TLS加密通信流程，从客户端到Ollama服务端的全链路：

客户端 curl / SDK Nginx TLS终止 端口443 Ollama 端口11434 HTTPS 加密传输 HTTP 内网明文 证书文件 server.crt / server.key 图例： 客户端 反向代理（TLS终止点） Ollama服务 证书存储 客户端 → Nginx：HTTPS加密 | Nginx → Ollama：内网HTTP（安全可控）

这个架构的核心思路是：TLS终止在反向代理层，Ollama本身只监听内网端口。这样既保证了加密通信，又不需要修改Ollama的代码。

4.7 常见问题与排障

最后分享几个我踩过的坑：

  • 证书链不完整：客户端报"unable to verify the first certificate"。检查server.crt是否包含了中间证书，用 openssl verify -CAfile ca.crt server.crt 验证。
  • SAN不匹配：客户端报"Hostname mismatch"。确保证书的SAN包含了客户端访问的域名或IP。
  • 权限问题：Nginx无法读取私钥。检查 chmod 600 server.key 和 chown root:root server.key。
  • WebSocket失败：流式输出卡住。确认Nginx配置了WebSocket升级头。
⚠️ 曾经踩过的坑： 有一次我忘了在Nginx配置里加 proxy_set_header Host $host，结果Ollama返回的响应里Location头是127.0.0.1，客户端直接连不上。排查了俩小时才发现是Host头没传过去。

好了，TLS这块就讲到这里。证书管理是个持续的过程，别想着配一次就一劳永逸。定期检查、自动续期、监控告警——这三板斧用好了，你的Ollama服务就稳了。

专注资料整理

← 上一章 📖 返回目录 下一章 →