[Bug]: SEARCH_WEB tool has SSLCert error

[klkr1]

Quick check

• I've searched existing issues and didn't find a duplicate.
• This issue relates to Gaia Agent UI (gaia chat --ui).
• This issue relates to a CLI command (gaia ...) or the SDK.

GAIA version

0.19.0

What happened?

1. use the web search agent
2. agent uses search_web tool
3. tool has error:
   Error performing web search: HTTPSConnectionPool(host='40.114.177.156', port=443): Max retries exceeded with url: /html/ (Caused by SSLError(SSLCertVerificationError(1, "[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address mismatch, certificate is not valid for '40.114.177.156'. (_
4. agent tries search_web tool again
5. same error
   agent gives up after 3 tries

What did you expect to happen?

search_web tool providing searched info

Acceptance criteria

search_web tool can do web searches

Environment

OS: Windows 11 25H2
CPU: AMD Ryzen 7 3700X
GPU: AMD Radeon RX 9060 XT
Lemonade: 10.6.0
Installer: Installer

[github-actions]

Thanks for the detailed report 🟡 — this is a real bug in our DNS-rebind protection, not a flaky network.

The search_web tool POSTs to https://html.duckduckgo.com/html/, but PinnedIPAdapter (src/gaia/web/client.py:64) rewrites the request URL to https://40.114.177.156/html/ before sending it, in order to close a DNS-rebind TOCTOU window between validate_url() and the TCP connect. It sets the Host header back to html.duckduckgo.com, but Python's TLS layer still uses the URL's hostname for SNI and certificate-CN verification — so urllib3 (rightly) rejects the cert as "not valid for 40.114.177.156". Exactly the error in your traceback.

This will reproduce for anyone whose DuckDuckGo edge resolves to a CDN IP where the cert isn't multi-SAN'd to the IP (most users). The previous fetch-page path worked because direct fetches of well-known sites still hit the same code path — they're equally affected, but a search is the easiest way to surface it.

Fix needs to preserve the original hostname for SNI + cert verification while still pinning the IP. Two reasonable approaches:

1. Subclass the HTTPSConnectionPool so it dials the pinned IP but presents the original hostname for SNI and assert_hostname (urllib3's documented pattern).
2. Pass server_hostname=host through urllib3.util.ssl_.create_urllib3_context on the wrapped socket and skip cert-hostname validation against the IP.

I'll mark this for the maintainers — @kovtcharov-amd, want me to draft a PR with approach (1)? It's localised to that one adapter and has good test coverage hooks via tests/ already.

Workaround in the meantime: there isn't a clean one short of patching the file locally to drop the PinnedIPAdapter mount (which trades back the TOCTOU risk for a working search). I'd hold off on monkey-patching production installs.

[kovtcharov]

@claude please draft a PR and share it here.