infiniflow
[Feature Request]: Support Custom Certificate Path via SSL_CERT_FILE in RAGFlow
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] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
- [x] Please do not modify this template :) and fill in all the required fields.
Is your feature request related to a problem?
Many OpenAI-compatible applications (e.g. local LLM endpoints or proxies) are served over HTTPS with custom or self-signed certificates. When using RAGFlow to connect to such endpoints, SSL verification fails unless the CA is explicitly trusted.
Python’s httpx library respects the SSL_CERT_FILE environment variable to override the CA bundle, but it’s unclear whether RAGFlow preserves or honors this by default — especially in wrapped or containerized environments.
Describe the feature you'd like
RAGFlow should support using the standard SSL_CERT_FILE environment variable to specify a custom CA bundle when making HTTPS requests (via HTTPX). This allows users to work securely with internal, self-signed, or private CA certificates without modifying code.
Describe implementation you've considered
A simple and effective implementation would involve creating an explicit SSL context that respects the standard SSL_CERT_FILE and SSL_CERT_DIR environment variables, which are already supported by Python’s ssl module. By initializing the context with ssl.create_default_context(cafile=os.environ.get("SSL_CERT_FILE", certifi.where()), capath=os.environ.get("SSL_CERT_DIR")) and passing it to HTTPX via verify=ctx, RAGFlow can securely support custom CA bundles without breaking existing behavior. This approach ensures that if users set these environment variables, their custom certificates will be used automatically, while falling back to the default trusted bundle (via certifi) when not set.
Documentation, adoption, use case
Additional information
No response
You could have Niginx configured for this feature.
I'm experiencing the same issue; could you explain how to set it up? I tried modifying the Nginx configuration with the following:
location /
proxy_pass
proxy_ssl_verify on
proxy_ssl_trusted_certificate <path-to-certificate>
proxy_ssl_name
proxy_set_header Host <url-i-send-request-to>
Curl works fine from the server using the same certificate file.
You could have Niginx configured for this feature.
It's the other way around, here OP wants to make calls to an OpenAI-compatible endpoint over HTTPS. The target service has self-signed certificate, or certificate signed by an internal CA.
As it's running in Docker, putting the CA's certificate in the host's /usr/local/share/ca-certificates and running update-ca-certificates won't do the trick (ex. for Ubuntu).
A simple and effective implementation would involve creating an explicit SSL context that respects the standard SSL_CERT_FILE and SSL_CERT_DIR environment variables, which are already supported by Python’s ssl module. By initializing the context with ssl.create_default_context(cafile=os.environ.get("SSL_CERT_FILE", certifi.where()), capath=os.environ.get("SSL_CERT_DIR")) and passing it to HTTPX via verify=ctx, RAGFlow can securely support custom CA bundles without breaking existing behavior. This approach ensures that if users set these environment variables, their custom certificates will be used automatically, while falling back to the default trusted bundle (via certifi) when not set.
This is the way 👍
JFYI, SSL_CERT_FILE worked for me. This works if the host trusts your CA:
volumes:
...
- /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro
env_file: .env
environment:
...
- SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
JFYI, SSL_CERT_FILE worked for me. This works if the host trusts your CA:
volumes: ... - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro env_file: .env environment: ... - SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
Alright, I guess the issue can be closed then! Did you try it @sagivma?