[GH-ISSUE #9391] TLS --insecure #52638

Closed
opened 2026-04-28 23:55:29 -05:00 by GiteaMirror · 5 comments
Owner

Originally created by @3GDXC on GitHub (Feb 27, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/9391

What is the issue?

When running ollama as a docker container where the host is using a proxy like zscaler; ollama run [model] fails due to failure to validate certificate.

Please consider either allowing the user to over this check and accept the insecure connection; or provide a environment variable/switch or configuration option to install a certificate authority certificate.

Relevant log output


OS

No response

GPU

No response

CPU

No response

Ollama version

No response

Originally created by @3GDXC on GitHub (Feb 27, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/9391 ### What is the issue? When running ollama as a docker container where the host is using a proxy like zscaler; ollama run [model] fails due to failure to validate certificate. Please consider either allowing the user to over this check and accept the insecure connection; or provide a environment variable/switch or configuration option to install a certificate authority certificate. ### Relevant log output ```shell ``` ### OS _No response_ ### GPU _No response_ ### CPU _No response_ ### Ollama version _No response_
GiteaMirror added the feature request label 2026-04-28 23:55:29 -05:00
Author
Owner

@flywiththetide commented on GitHub (Mar 4, 2025):

It looks like your issue is related to TLS certificate validation when running Ollama behind a proxy like Zscaler. Here are two possible solutions:

You can disable TLS certificate verification by setting the following environment variable when running the container:

docker run -e NODE_TLS_REJECT_UNAUTHORIZED=0 ollama/ollama

Alternatively, if using cURL inside the container, add:

curl -k https://registry.ollama.ai

This will bypass TLS validation but is not secure for production use.


Option 2: Install Your Proxy’s Root CA Certificate

A more secure approach is to install your Zscaler (or proxy) CA certificate inside the container.

  1. Copy the Zscaler Root CA certificate into the container:

    docker cp zscaler.crt <container-id>:/usr/local/share/ca-certificates/
    
  2. Update the certificate store:

    docker exec -it <container-id> update-ca-certificates
    
  3. Restart the container:

    docker restart <container-id>
    

After doing this, Ollama should trust your proxy’s certificate and allow downloads.

Let me know if you need help finding the correct CA certificate for your proxy!

<!-- gh-comment-id:2696238908 --> @flywiththetide commented on GitHub (Mar 4, 2025): It looks like your issue is related to **TLS certificate validation** when running Ollama behind a **proxy like Zscaler**. Here are two possible solutions: ### **Option 1: Disable TLS Verification (Not Recommended for Production)** You can disable TLS certificate verification by setting the following environment variable when running the container: ```bash docker run -e NODE_TLS_REJECT_UNAUTHORIZED=0 ollama/ollama ``` Alternatively, if using **cURL inside the container**, add: ```bash curl -k https://registry.ollama.ai ``` This will bypass TLS validation but is **not secure** for production use. --- ### **Option 2: Install Your Proxy’s Root CA Certificate** A more secure approach is to **install your Zscaler (or proxy) CA certificate** inside the container. 1. **Copy the Zscaler Root CA certificate into the container**: ```bash docker cp zscaler.crt <container-id>:/usr/local/share/ca-certificates/ ``` 2. **Update the certificate store**: ```bash docker exec -it <container-id> update-ca-certificates ``` 3. **Restart the container**: ```bash docker restart <container-id> ``` After doing this, Ollama should trust your proxy’s certificate and allow downloads. Let me know if you need help finding the **correct CA certificate** for your proxy!
Author
Owner

@3GDXC commented on GitHub (Mar 4, 2025):

Firstly, thanks for the advise/suggestions; around the issue seen when running ollama behind a proxy.
Ideally, it would be great not to modify the container image and simply run it with a environment flag as you have show with

docker run -e NODE_TLS_REJECT_UNAUTHORIZED=0 ollama/ollama
I have tried the above, without success the error
Error: pull model manifest: Get "https://registry.ollama.ai/v2/library/phi3/manifests/latest": tls: failed to verify certificate: x509: certificate signed by unknown authority

still occurs when executing ollama pull phi3 or any other model

the alternative to run

curl -k https://registry.ollama.ai

fails as curl is not install in the ollama image

I can confirm option 2 of installing the certificate works as expected; however I feel that this may be something that should be avoided as containers should be configured as close to production as possible with only minor differences when running with container host switches

<!-- gh-comment-id:2697434077 --> @3GDXC commented on GitHub (Mar 4, 2025): Firstly, thanks for the advise/suggestions; around the issue seen when running ollama behind a proxy. Ideally, it would be great not to modify the container image and simply run it with a environment flag as you have show with `docker run -e NODE_TLS_REJECT_UNAUTHORIZED=0 ollama/ollama ` I have tried the above, without success the error ` Error: pull model manifest: Get "https://registry.ollama.ai/v2/library/phi3/manifests/latest": tls: failed to verify certificate: x509: certificate signed by unknown authority` still occurs when executing ollama pull phi3 or any other model the alternative to run ` curl -k https://registry.ollama.ai` fails as curl is not install in the ollama image I can confirm option 2 of installing the certificate works as expected; however I feel that this may be something that should be avoided as containers should be configured as close to production as possible with only minor differences when running with container host switches
Author
Owner

@rick-github commented on GitHub (Mar 4, 2025):

Another couple of ways to handle this.

You can mount the cert in the container and then modify the entrypoint to update the certificates on every start of the container:

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama-data:/root/.ollama
      - ./zscalert.crt:/usr/local/share/ca-certificates/zscaler.crt
    entrypoint: bash -c 'update-ca-certificates ; exec ollama serve'

Or you can inherit from the ollama container and roll your own image:

FROM ollama/ollama:latest

COPY zscaler.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates
docker build -f Dockerfile -t ollama-cert .
services:
  ollama:
    image: ollama-cert
    volumes:
      - ollama-data:/root/.ollama
<!-- gh-comment-id:2698816430 --> @rick-github commented on GitHub (Mar 4, 2025): Another couple of ways to handle this. You can mount the cert in the container and then modify the entrypoint to update the certificates on every start of the container: ```yaml services: ollama: image: ollama/ollama:latest volumes: - ollama-data:/root/.ollama - ./zscalert.crt:/usr/local/share/ca-certificates/zscaler.crt entrypoint: bash -c 'update-ca-certificates ; exec ollama serve' ``` Or you can inherit from the ollama container and roll your own image: ```dockerfile FROM ollama/ollama:latest COPY zscaler.crt /usr/local/share/ca-certificates/ RUN update-ca-certificates ``` ``` docker build -f Dockerfile -t ollama-cert . ``` ```yaml services: ollama: image: ollama-cert volumes: - ollama-data:/root/.ollama ```
Author
Owner

@apbard commented on GitHub (Apr 3, 2025):

I have a similar problem but it's corporate network that is messing up with cert chain. Is there a way to disable tls inspection? I have seen an attempt #4615 but apparently has been abandoned

<!-- gh-comment-id:2774832563 --> @apbard commented on GitHub (Apr 3, 2025): I have a similar problem but it's corporate network that is messing up with cert chain. Is there a way to disable tls inspection? I have seen an attempt #4615 but apparently has been abandoned
Author
Owner

@CupOfGeo commented on GitHub (Apr 28, 2025):

@apbard i had the same issue my company uses Netskope. i added this InsecureSkipVerify to here in the http client of images.go and iit solved my issues. 0b9198bf47/server/images.go (L785)

	c := &http.Client{
		CheckRedirect: regOpts.CheckRedirect,
		Transport: &http.Transport{
			TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
		},
	}
<!-- gh-comment-id:2833740628 --> @CupOfGeo commented on GitHub (Apr 28, 2025): @apbard i had the same issue my company uses Netskope. i added this InsecureSkipVerify to here in the http client of images.go and iit solved my issues. https://github.com/ollama/ollama/blob/0b9198bf47d71b9cc1830beb29123d0d9f302f07/server/images.go#L785 ```go c := &http.Client{ CheckRedirect: regOpts.CheckRedirect, Transport: &http.Transport{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, }, } ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#52638