CURLSSLOPT_NATIVE_CA does not read from Windows' intermediate CA certificate store #12155
Comments
I disagree. This is a server issue and not our bug. Servers are supposed to send the intermediates. This has been reported before, though I can't find it. AFAICT Windows CA store it will cache an intermediate once it encounters it. Firefox does (or did) the same thing. There is no guarantee you can connect to a problem server unless you first connected to some other server that was doing the right thing and passing the intermediate, then you have it cached. It works by chance. |
|
@jay is of course right here and I did not think this through. Intermediate certs should be provided by the server during the handshake, checks like SSL labs' SSLtest will identify this error and point it out. This is a (common) server setup mistake. |
|
I don't think this has anything to do with caching. These are enterprise CA and sub-CA certificates deployed to intranet clients via Group Policy or Active Directory. I agree that the proxy should send those intermediates, but there is nothing I can do about it (especially seeing that browsers or SChannel work fine on those clients). |
|
Not sending intermediary certificates in the handshake is a server error. The fact that browsers or Schannel can (mostly) work around the issue is not changing where the error is. You can point out to the admins of the server that it is wrongly configured. I consider your issue here a feature-request for curl to support this because this is not a bug. I can certainly see where you are coming from though. I will not personally work on this feature (primarily because I don't develop on Windows and this is very windows specific code). |
- If CURLSSLOPT_NATIVE_CA on Windows then import from intermediate CA "CA" store after importing from root CA "ROOT" store. This change allows curl to work in situations where a server does not send all intermediate certs and they are present in the "CA" store (the store with intermediate CAs). This is already allowed by the Schannel backend. Also this change makes partial chain verification possible for those certs since we allow partial chain verification by default for OpenSSL (unless CURLSSLOPT_NO_PARTIALCHAIN). This is not allowed by the Schannel backend. Prior to this change CURLSSLOPT_NATIVE_CA only imported "ROOT" certs. Fixes curl#12155 Closes curl#12185
…certificates According to curl/curl#12155 and curl/curl@2d63331 Some corporate Windows proxy (mis)configurations don't pass along intermediate certificates in their TLS handshakes, breaking lots of things that don't work around it. This creates a problem in our curl calls when checking for .upgrade_requirements.json, and seems to be the source of errors for a few of our users: #14826 (comment) In this change, we detect when running on windows environments and load the curl option that works around this.
…certificates According to curl/curl#12155 and curl/curl@2d63331 Some corporate Windows proxy (mis)configurations don't pass along intermediate certificates in their TLS handshakes, breaking lots of things that don't work around it. This creates a problem in our curl calls when checking for .upgrade_requirements.json, and seems to be the source of errors for a few of our users: snipe#14826 (comment) In this change, we detect when running on windows environments and load the curl option that works around this.
I did this
libcurl with openssl backend fails to validate a server's certificate if the chain has intermediate CA certificates which are not sent by the server but are available via Windows' intermediate CA store. I've encountered this problem with certain SSL proxies in corporate environments.
Since the docs for
CURLSSLOPT_NATIVE_CAsay "use the operating system's CA store for certificate verification" I'd classify this as a bug.I expected the following
Certificate validation succeeds.
curl/libcurl version
8.4.0
operating system
Windows 10
The text was updated successfully, but these errors were encountered: