SSL peer certificate or SSH remote key was not OK error in v1.5

[JinIgarashi]

What happens?

When we upgrade duckdb to 1.5.1, I got the following error.

_duckdb.IOException: IO Error: SSL peer certificate or SSH remote key was not OK error for HTTP HEAD to 'https://XXXX.s3.ap-northeast-1.amazonaws.com/XXXX.parquet'

When I set a specific version of v1.4.4, the error has gone. Looks like the bug was introduced in v1.5, I guess.

To Reproduce

This is our code to use Duckdb in Django.

from contextlib import contextmanager
import duckdb

@contextmanager
def duckdb_connection(region=None, access_key_id=None, secret_access_key=None, load_spatial=True):
    region = region or AWS_REGION_NAME
    access_key_id = access_key_id or AWS_ACCESS_KEY_ID
    secret_access_key = secret_access_key or AWS_SECRET_ACCESS_KEY

    if region and region.lower() != "local":
        config = {
            "s3_region": region,
            "s3_access_key_id": access_key_id,
            "s3_secret_access_key": secret_access_key,
        }
        conn = duckdb.connect(database=":memory:", read_only=False, config=config)
    else:
        conn = duckdb.connect()

    try:
        if load_spatial:
            conn.execute("INSTALL spatial;")
            conn.execute("LOAD spatial;")
        yield conn
    finally:
        conn.close()

When we connect to geoparquet hosted in AWS S3, suddenly we started getting this SSL peer certificate error with v1.5.1

OS:

MacOS

DuckDB Package Version:

v1.5.1

Python Version:

3.10

Full Name:

Jin Igarashi

Affiliation:

Fracta Inc

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have not tested with any build

Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration to reproduce the issue?

• Yes, I have

[evertlammerts]

We've made significant changes to the http client in 1.5.0 (see https://duckdb.org/2026/03/09/announcing-duckdb-150#network-stack), this is likely related to that.

It smells like a certificate trust-store issue, and since the changes have been very extensively tested with S3 you might have uncovered an edge case. duckdb/duckdb-httpfs#282 is (probably) also a trust store related issue on OSX and you might be seeing the same problem, i.e. curl in duckdb not using KeyChain. But you are connecting to amazonaws.com so normally you would be dealing with a well known, public root CA that should be present in the static cert store anyway. There are some edge cases where all traffic is proxied so it can be inspected, and a local CA is used for connections to the proxy.

Can you run the following and paste the output here:

# 1. the version of curl you're using
curl --version
# 2. the TLS handshake with aws
curl -v https://s3.ap-northeast-1.amazonaws.com/
# 3. (optional) openssl for the cert + chain
openssl s_client -connect s3.ap-northeast-1.amazonaws.com:443 < /dev/null
# 4. (optional) cert store for openssl
ls -l `openssl version -d | sed 's/.*"\(.*\)"/\1\/cert.pem/'`