Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CURLSSLOPT_NATIVE_CA does not read from Windows' intermediate CA certificate store #12155

Closed
gix opened this issue Oct 19, 2023 · 5 comments
Closed

CURLSSLOPT_NATIVE_CA does not read from Windows' intermediate CA certificate store #12155

gix opened this issue Oct 19, 2023 · 5 comments
Labels
not-a-bug This is not a bug in curl TLS Windows Windows-specific

Comments

@gix
Copy link
Contributor

gix commented Oct 19, 2023

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 bagder added TLS Windows Windows-specific labels Oct 19, 2023
@bagder
Copy link
Member

bagder commented Oct 19, 2023

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
Copy link
Member

jay commented Oct 20, 2023

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 bagder added not-a-bug This is not a bug in curl and removed help wanted labels Oct 20, 2023
@bagder
Copy link
Member

bagder commented Oct 20, 2023

@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
Copy link
Contributor Author

gix commented Oct 20, 2023

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
Copy link
Member

bagder commented Oct 20, 2023 •
edited

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

gix added a commit to gix/curl that referenced this issue Oct 23, 2023
@gix
openssl: make CURLSSLOPT_NATIVE_CA also import Windows CA store
605f313 
The CA store contains intermediate CA certificates. This allows curl to
work in situations where a server does not send all intermediate certs and
they are present in the CA store. This already works using the SChannel
backend.

Fixes curl#12155
@gix gix mentioned this issue Oct 23, 2023
Closed
gix added a commit to gix/curl that referenced this issue Oct 26, 2023
@gix
openssl: make CURLSSLOPT_NATIVE_CA also import Windows CA store
7cd8893 
The CA store contains intermediate CA certificates. This allows curl to
work in situations where a server does not send all intermediate certs and
they are present in the CA store. This already works using the SChannel
backend.

Fixes curl#12155
jay pushed a commit to gix/curl that referenced this issue Oct 28, 2023
@gix @jay
openssl: make CURLSSLOPT_NATIVE_CA import Windows intermediate CAs
4a95a89 
- 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
@jay jay closed this as completed in 2d63331 Oct 29, 2023
@talregev talregev mentioned this issue Mar 14, 2024
Closed
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
not-a-bug This is not a bug in curl TLS Windows Windows-specific
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gix @bagder @jay