Add SSL Certificate Verification Options to FastMCP Client

[iDataist]

Is your feature request related to a problem? Please describe.

When connecting to an MCP server over HTTPS with self-signed or internal certificates, the FastMCP Client fails with SSL certificate verification errors. Currently, there's no straightforward way to disable SSL verification or provide custom certificates when using the Client class.

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)

Describe the solution you'd like
Please add one or more of the following options to the FastMCP Client:

A verify parameter to disable SSL verification or to provide a custom certificate:

client = Client(MCP_URL, verify=False)

client = Client(MCP_URL, verify="/path/to/certificate.pem")

This is needed when working with internal or development environments that use self-signed certificates or private certificate authorities.

Describe alternatives you've considered
Users need to resort to insecure workarounds like patching Python's SSL module.

Additional context

The issue appears to be in how the transport is inferred and created from the URL string. When a URL is provided, the infer_transport function creates a StreamableHttpTransport for HTTPS URLs, but there's no way to configure the SSL verification options for this transport.

According to FastMCP requirements, streamable-http transport is required for web deployments, and the client needs to connect to the /mcp path. The current implementation doesn't provide a way to handle SSL verification for these connections.

This would align with how other HTTP client libraries (like requests) handle SSL verification, making the API more intuitive and flexible for enterprise environments.

[cabusar]

To add more detail to this issue :

MCP use httpx wich use certifi wich is an external trusted CA store not modifiable by user.

Certifi does not support any addition/removal or other modification of the CA trust store content. This project is intended to provide a reliable and highly portable root of trust to python deployments.
Source : https://github.com/certifi/python-certifi

An issue is open since 2019 for httpx to use the system trusted CA store instead : encode/httpx#302 but didn't seem to progress much.

Beside the fact it's really annoying to deal with "SSL: CERTIFICATE_VERIFY_FAILED" every time you use a self-signed certificate, it's a real security concern that httpx use a CA store that users can't modify/manage.

But things could be easy to deal with as httpx provide a simple way to use the system CA store :

import httpx
import ssl
import truststore

ssl_context = truststore.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
client = httpx.Client(verify=ssl_context)

Source :
encode/httpx#302 (comment)

This way all python projects using mcp will not have to deal with SSL issues on self-signed certificate and the security side will be handle by the user who will have to manually add the CA certificate to the system's truststore.

In addition this method is compatible with linux, windows and osx as "trustore" is designed to precisely do it that way :
https://github.com/sethmlarson/truststore

Hope this help. :)

PS :

One temporary workaround for those who are stuck :

In ./venv/lib/python3.12/site-packages/certifi/, edit cacert.pem, add the CA you generate with your self-signed certificate.

-----BEGIN CERTIFICATE-----
your cert here
-----END CERTIFICATE-----

[iDataist]

@cabusar, thank you so much for looking into this ticket! I'm still encountering SSL certificate verification issues with FastMCP. I've tried implementing the truststore approach you suggested, but I'm still facing challenges.

I have two specific questions:
Does FastMCP's Client create its own httpx client internally that might bypass our SSL context settings? If so, is there a way to provide the SSL context directly to FastMCP?

Instead of modifying certifi's cacert.pem directly, is there a way to configure FastMCP to use a custom certificate file path?

[cabusar]

@iDataist : i'm not a contributor of this project, i was facing a similar issue with the python implementation of mcp and tried to help.

From my understanding of the problem : mcp use httpx with it's default parameters witch imply the use of certifi, a CA store that doesn't allow the modification of the CAs stored internally in ./venv/lib/python3.12/site-packages/certifi/cacert.pem (adapt regarding of your specific configuration).

mcp didn't offer the possibility to modify the behavior of httpx regarding which CA store to use, so you can't modify the "verify" option of the httpx instance created by mcp.

So, still in my understanding, and note that i'm not a good dev :

os.environ['PYTHONHTTPSVERIFY'] = '0'
import ssl
ssl._create_default_https_context = ssl._create_unverified_context

Have no effect in you script because certifi didn't take that into account.

client = Client(MCP_URL)

Here you create your instance of fastmcp which in the back use mcp, then httpx, but you have no control on how it's done regarding the "verify" parameter.

So, from here, three options :

• mcp project implement a solution to control the verify parameter of httpx.
• httpx project stop using certifi by default (which is a really curious/dumb choice from my adminsys perspective anyway)
• You bypass entirely all this crap and just add your self-signed/generated CA in the certifi truststore (and froze the certifi dependancy to avoid any break caused by an update of certifi and it's truststore)

Keep in mind that the last "solution" should be really temporary, CA certificates are renewed regularly for security purposes, if you froze the CA store of certifi it could prevent legitimate certificate to be trusted in the futur.

The best solution would that httpx to change their approach of course.
As they seems not willing to do so, mcp dev would be really kind to offer a way to change the "verify" parameter of httpx.

@dsp-ant : David, if you have some time to look into this discussion it would be really kind (at least to tell if i understand the problem correctly). I would be glad to make a PR about it and save you some time, but given my coding skills you definitely don't want it to happen. ^^'