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/'`

[evertlammerts]

Closing for lack of info. We're releasing 1.5.2 soon as wel. If you still see issues now then upgrade to 1.5.2 when it's out. If that also causes issues, then please send the info I asked for above.

[vs-jdefting]

@evertlammerts I am also experiencing this issue on v1.5.2. Here is the output of running the above commands.

output

curl 8.7.1 (x86_64-apple-darwin24.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.64.0
Release-Date: 2024-03-27
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe UnixSockets
* Host cccc.ddddd.com.s3.us-east-1.amazonaws.com:443 was resolved.
* IPv6: (none)
* IPv4: 16.15.187.230, 52.217.46.0, 16.182.67.58, 3.5.0.73, 16.15.253.102, 16.15.207.4, 16.15.212.63, 52.217.137.106
*   Trying 16.15.187.230:443...
* Connected to cccc.ddddd.com.s3.us-east-1.amazonaws.com (16.15.187.230) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=s3.amazonaws.com
*  start date: Nov 18 00:00:00 2025 GMT
*  expire date: Nov  6 23:59:59 2026 GMT
*  subjectAltName does not match host name cccc.ddddd.com.s3.us-east-1.amazonaws.com
* SSL: no alternative certificate subject name matches target host name 'cccc.ddddd.com.s3.us-east-1.amazonaws.com'
* Closing connection
curl: (60) SSL: no alternative certificate subject name matches target host name 'cccc.ddddd.com.s3.us-east-1.amazonaws.com'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Connecting to 3.5.0.73
CONNECTED(00000006)
depth=2 C=US, O=Amazon, CN=Amazon Root CA 1
verify return:1
depth=1 C=US, O=Amazon, CN=Amazon RSA 2048 M04
verify return:1
depth=0 CN=s3.amazonaws.com
verify return:1
---
Certificate chain
 0 s:CN=s3.amazonaws.com
   i:C=US, O=Amazon, CN=Amazon RSA 2048 M04
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Nov 18 00:00:00 2025 GMT; NotAfter: Nov  6 23:59:59 2026 GMT
 1 s:C=US, O=Amazon, CN=Amazon RSA 2048 M04
   i:C=US, O=Amazon, CN=Amazon Root CA 1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Aug 23 22:26:35 2022 GMT; NotAfter: Aug 23 22:26:35 2030 GMT
 2 s:C=US, O=Amazon, CN=Amazon Root CA 1
   i:C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Services Root Certificate Authority - G2
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 25 12:00:00 2015 GMT; NotAfter: Dec 31 01:00:00 2037 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIINDCCBxygAwIBAgIQBzY6cFaMz1k3hS5AnEod7jANBgkqhkiG9w0BAQsFADA8
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRwwGgYDVQQDExNBbWF6b24g
UlNBIDIwNDggTTA0MB4XDTI1MTExODAwMDAwMFoXDTI2MTEwNjIzNTk1OVowGzEZ
MBcGA1UEAxMQczMuYW1hem9uYXdzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMsU7J2cPn1X6BuP1Ia2NHQ+lLx85L+p+mb6jiXDygVGKI19R5E+
gOv2l6Fcvh/C/rzCCfIyLQ/w07/yjCWpxjWvl4EzdFhxpW3Pt41tnRm1uWxXM9Jr
SOCTUIkTm4SpG1oWY4Yg0sy6RjwgBSk0Iae+FIo14F5EhFV/5O5rh/agi++nH+sA
PLQV5pAdrueyfAy8aJVNbxfAfKxJwHq+1qCQHMuF8PUHWyuQWLQnKfP4df58cre3
UfaCGZ+nrZ6V9vklym4dJbd2hXLNjQuFaYhna9m7JNHVemniJwKypdy1kYTEJYN7
o/F5JJpVxBzjLRLJx4jrU1ka4mH9F/XRl7MCAwEAAaOCBVEwggVNMB8GA1UdIwQY
MBaAFB9SkmFWglR/gWbYHT0KqjJch90IMB0GA1UdDgQWBBQ0Ew9KwJNvdQrCmRwH
9voTvQeNnTCCAokGA1UdEQSCAoAwggJ8ghBzMy5hbWF6b25hd3MuY29tghIqLnMz
LmFtYXpvbmF3cy5jb22CKCouczMtYWNjZXNzcG9pbnQudXMtZWFzdC0xLmFtYXpv
bmF3cy5jb22CJCouczMtY29udHJvbC51cy1lYXN0LTEuYW1hem9uYXdzLmNvbYIk
czMuZHVhbHN0YWNrLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tgicqLnMzLWRlcHJl
Y2F0ZWQudXMtZWFzdC0xLmFtYXpvbmF3cy5jb22CLHMzLWNvbnRyb2wuZHVhbHN0
YWNrLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tgh0qLnMzLWV4dGVybmFsLTIuYW1h
em9uYXdzLmNvbYIaczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb22CMiouczMtYWNj
ZXNzcG9pbnQuZHVhbHN0YWNrLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tghwqLnMz
LnVzLWVhc3QtMS5hbWF6b25hd3MuY29tgh0qLnMzLWV4dGVybmFsLTEuYW1hem9u
YXdzLmNvbYImKi5zMy5kdWFsc3RhY2sudXMtZWFzdC0xLmFtYXpvbmF3cy5jb22C
G3MzLWV4dGVybmFsLTIuYW1hem9uYXdzLmNvbYIiczMtY29udHJvbC51cy1lYXN0
LTEuYW1hem9uYXdzLmNvbYIbczMtZXh0ZXJuYWwtMS5hbWF6b25hd3MuY29tgiVz
My1kZXByZWNhdGVkLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tgi4qLnMzLWNvbnRy
b2wuZHVhbHN0YWNrLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tMBMGA1UdIAQMMAow
CAYGZ4EMAQIBMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATA7
BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLnIybTA0LmFtYXpvbnRydXN0LmNv
bS9yMm0wNC5jcmwwdQYIKwYBBQUHAQEEaTBnMC0GCCsGAQUFBzABhiFodHRwOi8v
b2NzcC5yMm0wNC5hbWF6b250cnVzdC5jb20wNgYIKwYBBQUHMAKGKmh0dHA6Ly9j
cnQucjJtMDQuYW1hem9udHJ1c3QuY29tL3IybTA0LmNlcjAMBgNVHRMBAf8EAjAA
MIIBgAYKKwYBBAHWeQIEAgSCAXAEggFsAWoAdgDYCVU7lE96/8gWGW+UT4WrsPj8
XodVJg8V0S5yu0VLFAAAAZqUisdkAAAEAwBHMEUCIENz43wr1jdLUGbX4IXSPgMz
ZdVaTZ8S4pTtXN108SNcAiEAr/btwaN2y0t5kriIGkWxQ8darsFJjQIL1EXJEKao
SE8AdwDCMX5XRRmjRe5/ON6ykEHrx8IhWiK/f9W1rXaa2Q5SzQAAAZqUisdvAAAE
AwBIMEYCIQC23N1q42ikjstPdadKliArNQ3cd5lDcVM6uDgNa7WarQIhANGSFEAS
RR5r7BfxuLvBpr87f1tiKsvP2YNJ8MhZC0ZJAHcAlE5Dh/rswe+B8xkkJqgYZQHH
0184AgE/cmd9VTcuGdgAAAGalIrHhAAABAMASDBGAiEAxpU5AfXV5XyVIJLxqIcG
lULdhKipR0E1tuM7p15i+zkCIQDW98bQeo1Kr69Rlmcww0tONMoVYKorBCRn0vrF
DyYj4TANBgkqhkiG9w0BAQsFAAOCAQEAtuyqRRwU0I2cfn/zxAKOpMvYbzMQJ9Tt
CCoAxv7FCLQtqWKv0W6On1N4l2Sh22U7moTNAg8BQVT62ho90s2n3l+dQWs51wvH
uEEHXI5jR6FZ+CTSeADYP3+nUjr10nQi0q7r0xCMTIlB7AZKUj+MWETEmMrr4RUY
htV6NG4thQ4ZgB6/coGoN8hdUE24D1K/6NFuj6scufNwB5Rd36xKzhhoRdj4Caqr
hJC702bRq+fshE4Vz40skhXyj/Ygdd1VaQ04oZiQlTKw5oDbbWD59HtRDutNpgES
jQgSFhAkjWQtSETRnOUYdHwtCrMpPr8zdfWprbfstvwoDxmu+s4irg==
-----END CERTIFICATE-----
subject=CN=s3.amazonaws.com
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M04
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 6038 bytes and written 1641 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
lrwxr-xr-x  1 jdefting  admin  27 Apr 15 17:07 /opt/homebrew/etc/openssl@3/cert.pem -> ../ca-certificates/cert.pem

[evertlammerts]

Thanks @vs-jdefting, very useful output. Your bucket name includes dots (cccc.ddddd.com) and as you can see from your output, this results in a hostname that cannot be verified: cccc.ddddd.com.s3.us-east-1.amazonaws.com:

curl: (60) SSL: no alternative certificate subject name matches target host name 'cccc.ddddd.com.s3.us-east-1.amazonaws.com'

This is a documented limitation of virtual hosting of S3 buckets: https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html

There is a ticket already open for this issue: duckdb/duckdb-httpfs#283. I'll copy your comment there.

You can work around this by setting URL_STYLE path on your S3 secret config in duckdb.