CURLSSLOPT_NATIVE_CA does not read from Windows' intermediate CA certificate store

[gix]

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_CA say "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

[bagder]

The current code loads and uses the ROOT store:

curl/lib/vtls/openssl.c

Line 3064 in d4314cd

HCERTSTORE hStore = CertOpenSystemStore(0, TEXT("ROOT"));

Sources seem to indicate that we also need to get the certs from the CertificationAuthority store, which is documented to hold the "Certificate store for intermediate certification authorities (CAs)."

[jay]

we also need to get the certs from the CertificationAuthority store, which is documented to hold the "Certificate store for intermediate certification authorities (CAs)."

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.

[bagder]

@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.

[gix]

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).

[bagder]

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).