hermes - ✅(Solved) Fix [Feature]Support user-provided extra CA bundles for Python/httpx clients [1 pull requests, 2 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#24917Fetched 2026-05-14 03:50:36
View on GitHub
Comments
2
Participants
1
Timeline
10
Reactions
0
Participants
Timeline (top)
labeled ×4commented ×2cross-referenced ×1mentioned ×1

Root Cause

This can happen because different runtimes use different trust stores. For example, Node-based tools may be configured with NODE_EXTRA_CA_CERTS, while Hermes uses Python/httpx/OpenAI SDK and does not automatically consume that Node-specific CA configuration.

Fix Action

Fixed

PR fix notes

PR #24918: feat(agent): support user-provided extra CA bundles for OpenAI/httpx clients

Description (problem / solution / changelog)

Summary

This adds generic extra CA bundle support for Hermes' Python/httpx-based OpenAI client path.

When users configure extra CA cert files via HERMES_EXTRA_CA_CERTS or NODE_EXTRA_CA_CERTS, Hermes now builds a merged CA bundle and uses it for the keepalive-enabled httpx client used by the main agent.

This helps in environments where an HTTPS proxy presents certificates signed by a local/private root CA. The change keeps TLS verification enabled and does not hardcode any organization, vendor, or company-specific CA paths.

Closes #24917.

Details

New helper: configure_extra_ca_bundle()

Added in utils.py.

The helper:

  • reads extra CA paths from:
    • HERMES_EXTRA_CA_CERTS
    • NODE_EXTRA_CA_CERTS
  • supports path-list values using os.pathsep
  • filters missing files
  • deduplicates cert paths
  • builds a merged CA bundle from:
    • existing SSL_CERT_FILE or REQUESTS_CA_BUNDLE, when configured
    • otherwise certifi.where()
    • otherwise Python's default SSL cafile
  • writes the merged bundle to:
    • HERMES_CA_BUNDLE, if set
    • otherwise $HERMES_HOME/hermes-ca-bundle.pem
  • sets:
    • SSL_CERT_FILE
    • REQUESTS_CA_BUNDLE
  • stores the original base bundle in _HERMES_CA_BASE_BUNDLE so repeated calls are idempotent
  • supports opt-out via HERMES_DISABLE_EXTRA_CA_AUTO

Proxy normalization path

normalize_proxy_env_vars() now calls configure_extra_ca_bundle() after normalizing proxy env vars.

This keeps proxy and TLS trust configuration on the same runtime initialization path.

Main OpenAI/httpx client

AIAgent._build_keepalive_http_client() now calls configure_extra_ca_bundle().

If a merged bundle is available, the httpx client receives:

ssl.create_default_context(cafile=bundle_path)

This preserves the existing keepalive transport and explicit proxy handling while also allowing Python/httpx to trust user-provided extra CA roots.

The implementation uses an SSLContext instead of verify=<str> to avoid httpx's deprecation warning for string verify paths.

Why this is needed

Hermes can already route requests through proxies, but proxy routing alone is not sufficient when the proxy presents certificates signed by a CA that Python/httpx does not trust.

Some users already have extra CA configuration for Node-based tools via NODE_EXTRA_CA_CERTS, but Hermes' Python/httpx clients do not automatically consume that setting.

Gateway mode also has a specific ordering issue: SSL_CERT_FILE may be set before .env is loaded. The new helper handles this by merging extra CA files even when SSL_CERT_FILE is already present.

Tests

Added regression coverage in tests/run_agent/test_create_openai_client_proxy_env.py:

  • existing proxy tests now clear CA-related env vars to avoid cross-test contamination
  • extra CA bundle is merged when SSL_CERT_FILE is preconfigured
  • repeated calls are idempotent and do not duplicate extra CA contents

How to test

env HERMES_HOME=/private/tmp/hermes-pytest \
  venv/bin/python -m pytest \
  tests/run_agent/test_create_openai_client_proxy_env.py \
  tests/agent/test_proxy_and_url_validation.py

All 27 tests pass.

Platforms tested

  • macOS 15.x (darwin, arm64)

Validation

  • git diff --check: passed
  • Targeted tests: 27 passed
  • Full suite (scripts/run_tests.sh): 22,000+ passed, failures are pre-existing (optional deps: discord, faster_whisper, bedrock)

Changed files

  • run_agent.py (modified, +10/-5)
  • tests/run_agent/test_create_openai_client_proxy_env.py (modified, +76/-0)
  • utils.py (modified, +125/-0)
RAW_BUFFERClick to expand / collapse

Problem

Hermes already supports standard proxy environment variables such as HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY.

However, when Hermes runs behind an HTTPS proxy that presents upstream certificates signed by a private/local root CA, Python/httpx can fail TLS verification even though other tools on the same machine work.

This can happen because different runtimes use different trust stores. For example, Node-based tools may be configured with NODE_EXTRA_CA_CERTS, while Hermes uses Python/httpx/OpenAI SDK and does not automatically consume that Node-specific CA configuration.

The issue is especially visible in gateway mode:

  • the gateway is a long-lived process
  • gateway/run.py may pre-populate SSL_CERT_FILE early
  • .env is loaded afterwards
  • if Hermes treats an existing SSL_CERT_FILE as final, later user-provided extra CA configuration cannot be merged

The result is that platform adapters can connect successfully, but LLM calls through the OpenAI/httpx client can fail with APIConnectionError or TLS/proxy-related connection errors.

Expected behavior

Hermes should provide generic extra CA bundle support for Python/httpx clients.

It should:

  • keep TLS verification enabled
  • allow users to provide additional CA certificate files
  • work with existing proxy support
  • preserve NO_PROXY behavior
  • respect existing Python CA env vars where possible
  • avoid hardcoding any organization, vendor, or company-specific CA path
  • work in both CLI and gateway contexts

Proposed behavior

Support these environment variables:

  • HERMES_EXTRA_CA_CERTS: Hermes-native path list of extra CA cert files
  • NODE_EXTRA_CA_CERTS: compatibility with existing Node-based setups
  • HERMES_CA_BUNDLE: optional output path for the generated merged bundle
  • SSL_CERT_FILE / REQUESTS_CA_BUNDLE: existing Python CA bundle settings
  • HERMES_DISABLE_EXTRA_CA_AUTO: opt out of automatic extra CA handling

When extra CA files are configured, Hermes can build a merged CA bundle from the base CA bundle plus the extra CA files, then point Python/httpx at that merged bundle.

This should not disable TLS verification.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Hermes should provide generic extra CA bundle support for Python/httpx clients.

It should:

  • keep TLS verification enabled
  • allow users to provide additional CA certificate files
  • work with existing proxy support
  • preserve NO_PROXY behavior
  • respect existing Python CA env vars where possible
  • avoid hardcoding any organization, vendor, or company-specific CA path
  • work in both CLI and gateway contexts

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING