github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #14003] Add support for signed TLS certificates and API key authentication #9153

New Issue
Open
opened 2026-04-12 22:00:21 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-12 22:00:21 -05:00
Owner
Copy Link

Originally created by @akniy on GitHub (Jan 31, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/14003

Description

A recent study highlighted that 175,000 publicly exposed Ollama AI servers have been discovered across 130 countries, leaving users and organizations vulnerable to unauthorized access and data leakage. The report emphasizes the need for stronger security controls for self‑hosted LLM deployments. While several issues in the repository have requested API key and TLS certificate support, this report highlights the increased importance of these frequently requested features. The report also indicates marketplace style commercialization of access to these compromised instances.

Proposed solution

Implement native support in the Ollama server to:

  1. Require signed TLS certificates

    • Allow users to configure a CA‑signed certificate (or self‑signed with a local CA that is trusted by the client) for all incoming connections.
    • Allow enforcement of TLS v1.3 and disable older protocols/weak cipher suites.
    • Provide clear CLI and GUI options to enable/disable TLS, set certificate paths, and display connection status.

  2. Enable API key authentication

    • Generate per‑installation API keys that must be presented by clients before any model request is processed.
    • Support key rotation and revocation via a simple command line interface or web UI.
    • Optional logging of all requests with the key identifier for audit purposes.

  3. Cross‑platform compatibility

    • Ensure the implementation works seamlessly on Linux, Windows, and macOS.
    • Leverage existing platform TLS libraries (OpenSSL on Linux/macOS, Schannel on Windows) and keep the dependencies minimal.

Benefits

  • Prevents accidental exposure: Even if the server is reachable over the internet, only clients with valid certificates and keys can interact.
  • Simplify deployment: Enables simpler end-to-end encryption for deployments without co-located Load Balancers and Ollama installations.
  • Compliance: Meets common security frameworks (ISO 27001, SOC 2, NIS2) that require encrypted transport and authentication for API access.
  • User trust: Demonstrates a proactive approach to security for the Ollama community.

Next steps

  • Add documentation for generating and configuring TLS certificates and API keys.
  • Update the installer scripts to prompt for these settings during initial setup.
  • Include automated tests to verify that unauthenticated connections are rejected.

Thank you for your consideration. Improving Ollama’s security posture will benefit the entire community and help avoid the kind of exposure detailed in the referenced research.

Originally created by @akniy on GitHub (Jan 31, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/14003 ### Description A recent [study](https://thehackernews.com/2026/01/researchers-find-175000-publicly.html) highlighted that **175,000** publicly exposed Ollama AI servers have been discovered across 130 countries, leaving users and organizations vulnerable to unauthorized access and data leakage. The report emphasizes the need for stronger security controls for self‑hosted LLM deployments. While several issues in the repository have requested API key and TLS certificate support, this report highlights the increased importance of these frequently requested features. The report also indicates marketplace style commercialization of access to these compromised instances. ### Proposed solution Implement native support in the Ollama server to: 1. **Require signed TLS certificates** - Allow users to configure a CA‑signed certificate (or self‑signed with a local CA that is trusted by the client) for all incoming connections. - Allow enforcement of TLS v1.3 and disable older protocols/weak cipher suites. - Provide clear CLI and GUI options to enable/disable TLS, set certificate paths, and display connection status. 2. **Enable API key authentication** - Generate per‑installation API keys that must be presented by clients before any model request is processed. - Support key rotation and revocation via a simple command line interface or web UI. - Optional logging of all requests with the key identifier for audit purposes. 3. **Cross‑platform compatibility** - Ensure the implementation works seamlessly on **Linux**, **Windows**, and **macOS**. - Leverage existing platform TLS libraries (OpenSSL on Linux/macOS, Schannel on Windows) and keep the dependencies minimal. ### Benefits - **Prevents accidental exposure**: Even if the server is reachable over the internet, only clients with valid certificates and keys can interact. - **Simplify deployment**: Enables simpler end-to-end encryption for deployments without co-located Load Balancers and Ollama installations. - **Compliance**: Meets common security frameworks (ISO 27001, SOC 2, NIS2) that require encrypted transport and authentication for API access. - **User trust**: Demonstrates a proactive approach to security for the Ollama community. ### Next steps - Add documentation for generating and configuring TLS certificates and API keys. - Update the installer scripts to prompt for these settings during initial setup. - Include automated tests to verify that unauthenticated connections are rejected. Thank you for your consideration. Improving Ollama’s security posture will benefit the entire community and help avoid the kind of exposure detailed in the referenced research.
GiteaMirror added the feature request label 2026-04-12 22:00:21 -05:00
GiteaMirror commented 2026-04-12 22:00:21 -05:00
Author
Owner
Copy Link

@ajmal-yazdani commented on GitHub (Feb 2, 2026):

We have custom mTLS where we're combining ollama and caddy together into single docker image and applied mTLS on top of that.

<!-- gh-comment-id:3834998173 --> @ajmal-yazdani commented on GitHub (Feb 2, 2026): We have custom mTLS where we're combining ollama and caddy together into single docker image and applied mTLS on top of that.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#9153
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?