curl v8.20.0 does not adhere to the fallback chain for certificate lookups advertized in https://curl.se/docs/sslcerts.html

[chrizilla]

I did this

curl v8.0.1 successfully talks IMAP with a server:
curl imaps://0@imap.gmx.net (omitting credentials here)
curl: (67) Login denied (but login succeeds with credentials)

curl v8.20.0 produces an error for the exact same command:

curl imaps://0@imap.gmx.net
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
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 webpage mentioned above.

This makes no sense:

Curl produces an error.
     --> And the error says, look at this URL.
            --> And the URL describes a fallback chain, which, if followed, would not produce said error in the first place.

I expected the following

I expect curl to do what the manual claims, namely use the following very useful fallback chain:

If you are using the curl command line tool on Windows, curl searches for a CA cert file named curl-ca-bundle.crt in these directories and in this order:

1. application's directory
2. current working directory
3. Windows System directory (e.g. C:\Windows\System32)
4. Windows Directory (e.g. C:\Windows)
5. all directories along %PATH%

• According to this fallback chain, the certificate error above should not occur, since "application's directory" already is the n°1 lookup-priority !
• Likewise, the --cacert curl-ca-bundle.crt workaround should neither be needed nor work, since "application's directory" already is the n°1 lookup-priority !

So either the manual is wrong or not adhered to.
Either way, this is confusing for users and should be fixed.

💡 concrete suggestions for how to fix this issue:

1. re-enable the fallback chain advertised on the error help page
2. If a higher-priority cert storage location lacks the needed certificate, look in lower-priority locations. I.e. make the storage locations not "all or nothing", but available for individual lookups, so curl can locate a matching cert across stores instead of failing outright at first try. Comparison: If my favourite bookstore does not have my book, I don't have to give up but can go to another bookstore.

curl/libcurl version

curl 8.20.0 (x86_64-w64-mingw32) libcurl/8.20.0 LibreSSL/4.3.1 zlib/1.3.1.zlib-ng brotli/1.2.0 zstd/1.5.7 WinIDN libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.69.0 ngtcp2/1.22.1 nghttp3/1.15.0 WinLDAP
Release-Date: 2026-04-29
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy HTTPSRR IDN IPv6 Kerberos Largefile libz NativeCA PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

operating system

Windows 10

related issues:

• Curl 8.19 Fails With SSL Error on Win 10 #20897 (closed without fix and explanation)

[bagder]

Is this a curl tool version downloaded from curl.se ?

(curl does not have fallback chains for CA certs. It uses the set it is told to trust.)

[vszakats]

This is an overridable build default when explicitly enabling Native CA by default (for macOS and
Windows). I don't consider this a curl issue.

In curl-for-win, it may be a debate to enable the embedded certdata CA bundle as a fallback, but I'd
personally prefer to figure out why Native CA did not work in the handful of reports that came out in
the last years. Even more so, because the fallback method doesn't work for libcurl, only for the curl
tool, and curl-for-win provides both.

[vszakats]

This replicated now in my Windows 11 VM using command-line: curl https://gmx.net/
Then I run the system curl (C:\WINDOWS\system32\curl.exe) once with this same
command-line, and after that the curl-for-win curl also worked. AFAICT there was no
network access made by the system during that time (such as Windows downloading
new certs or something), suggesting something local got unblocked just by accessing
the same URL via Schannel. Pretty weird.

[MichalPetryka]

AFAICT there was no
network access made by the system during that time (such as Windows downloading
new certs or something), suggesting something local got unblocked just by accessing
the same URL via Schannel. Pretty weird.

It could be that the Windows Update file with the certs was already on the drive and only got unpacked then.

[vszakats]

If that means anything, I was holding back Windows Updates for several months now on
this particular machine. But t's not impossible, yes.

[MichalPetryka]

If that means anything, I was holding back Windows Updates for several months now on this particular machine. But t's not impossible, yes.

Last update of CA roots was in September of 2025 and I assume the CA root for the domain was added earlier than that.
I assume it ships with some version of it in the install image already, one that'd probably be enough for a lot of domains.

[vszakats]

I wonder why that many months weren't enough for these roots to become served
by the API. Though, this machine sees little network use, no browser use, only rare
system curl.exe runs, and definitely no accessing gmx.net in that period.

Maybe "general use" of the OS eventually fixes this in the background, e.g. loading
gmx.net from the browser or other Windows OS means?

[jay]

This replicated now in my Windows 11 VM using command-line: curl https://gmx.net/
Then I run the system curl (C:\WINDOWS\system32\curl.exe) once with this same
command-line, and after that the curl-for-win curl also worked. AFAICT there was no
network access made by the system during that time (such as Windows downloading
new certs or something), suggesting something local got unblocked just by accessing
the same URL via Schannel. Pretty weird.

This sounds a lot like #20897 which the OP referenced. Maybe there is some network activity that you missed or Windows Update cached the root cert somewhere and only imported it after the Schannel verification attempt (which uses Windows crypto).