Ability to Toggle SSL verification when making HTTP requests

[seanw7]

Self Checks

• [X] I have searched for existing issues search for existing issues, including closed ones.
• [X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [X] Pleas do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing?

When attempting to add an on-prem ollama model provider that is running in OpenShift, we experience an ssl issue because the SSL certs are self-signed in our lab environment cluster

we also see similar issues when attempting to use the http response node/block in the workflow editor against servers using self-signed certificates.

In both cases, there does not appear to be any obvious options to toggle this behavior on or off in the webgui.

2. Describe the feature you'd like to see

A slider or check box to enable or disable ssl verification when:

• Adding model providers & when making http requests with the http request node in the workflow editor

3. How will this feature improve your workflow or experience?

It will enable me to utilize the tool without having to configure SSL certificates on multiple machines in my lab environment kubernetes cluster

4. Additional context or comments

If there is some way that this can be enabled without a feature request, I would greatly appreciate it someone could point me in the right direction! If there isn't, I can imagine there are others who are experiencing the same issue, as I saw others mentioning similar issues in the past.

5. Can you help us with this feature?

• [X] I am interested in contributing to this feature.

[hanhyalex123]

please solve this problem，plz

[crazywoola]

@Yeuoly Can you take a look at this issue?

[Yeuoly]

I guess you guys need an environment variable to specify whether ignore SSL verification or not, but it's not a recommended method, self-signed certificate make non-sense for HTTPS requests, why not just using HTTP? btw, are you using our cloud version or self-hosted a Dify instance? for the first one, we have on plan currently, as for the next, we can introduce an environment variable.

[JokerQyou]

I guess you guys need an environment variable to specify whether ignore SSL verification or not, but it's not a recommended method, self-signed certificate make non-sense for HTTPS requests, why not just using HTTP? btw, are you using our cloud version or self-hosted a Dify instance? for the first one, we have on plan currently, as for the next, we can introduce an environment variable.

Would it be feasible to implement this as an option of HTTP request block? An environment variable is nice, but it might affect much more than one expected. In my case it's a self-hosted instance. It needs to call some of our own APIs. Those servers are exposed on the Internet, but they have no domain name, so there is no way to get CA-signed certificates for them (it's really hard to get CAs to sign certificates for IP addresses). So to prevent someone (e.g. milicious ISPs or other actors along the network chain) from seeing the request content and changing responses, we add self-signed certificates for these IP addresses. This differs from using HTTP in some way:

• SSL is still used, it's just the CA of the certificate is not verified.
• Any one on the network chain can see what you sent and received if it's just HTTP.

It's also common for embedded devices like router or NAS to use self-signed certificates. But I don't currently interact with these with Dify.

Currently the workaround is to merge the certificate into Dify's API container like this:

docker cp mycert.crt docker-api-1:/tmp/
docker compose exec api bash
# And in the container:
cat /tmp/mycert.crt >> python -c 'import certifi;print(certifi.where())'

This forcibly trust the self-signed certificate so no SSL errors would occur. But you'd have to do this every time the container is re-created. If the Dify team decide to not add 'disable SSL verification', maybe an option to add additionally trusted certificates would also work (for my scenario).

[tak-s]

I am constructing Dify locally, and have set up Ollama and NGINX with Self-signed SSL. I also encountered a certificate error when trying to register Ollama models on Dify.

Therefore, I took the following:

1. Enter the Dify API container:

docker exec -it docker-api-1 bash

2. Modify the Ollama calling code:

vi core/model_runtime/model_providers/ollama/llm/llm.py

3. Add verify=False to the requests.post call around line 238:

# Send a post request to validate the credentials
response = requests.post(
    endpoint_url, headers=headers, json=data, timeout=(10, 300), stream=stream, verify=False
)

4. Restart the Docker container:

# not 'docker compose down'
docker compose stop && docker compose up -d

I hope this helps.