Windows: Support intermediate certificates

[timja]

Fixes #9

TODO:

• Run tests on Windows

I haven't run this yet on Windows but its the same code I wrote for node.js nodejs/node#57164 which I have tested as working. - Ran on Windows its working.

Also see Chromium's implementation: https://github.com/chromium/chromium/blob/98f89988c9774d0e138a0724aa64c46187203a77/net/cert/internal/trust_store_win.cc#L220-L222

[timja]

cc @shalupov

[shalupov]

Why you don't check that intermediate CA is signed with any root CA like in mac OS?

[timja]

Why you don't check that intermediate CA is signed with any root CA like in mac OS?

Its based on the chromium implementation for Windows, https://github.com/chromium/chromium/blob/98f89988c9774d0e138a0724aa64c46187203a77/net/cert/internal/trust_store_win.cc#L220-L222. How they do the macOS implementation for intermediates is not clear (although it does work).

I've been thinking about whether its necessary or not to do that on macOS, its based on https://developer.apple.com/documentation/security/sectrustsettingscopytrustsettings(_:_:_:)?language=objc

No trust-settings array means “this certificate must be verifiable using a known trusted certificate”.

i.e. whether this needs to be validated at this point or whether it should be validated later by path building.
Using the OS verification also means that you know that the trust settings are fine for it but that can be checked as well.

[shalupov]

whether it should be validated later by path building.

In this design, we can't validate certificates later because we return all certificates as a single trusted root list. While Chromium may correctly inject intermediate certificates into the validating trust chain, we simplify it by passing everything as a single list to TrustManagerFactory as one key store.

This approach could probably be improved, but I haven't found a better way yet--and so far, it has been good enough.

According to the javadoc for SecurityFrameworkUtil, it would be better to implement X509TrustManager using the native API. However, this would require a larger effort and is best handled at the JDK level.

That's why I prefer to validate that all intermediate certificates are signed by a trusted root--no completely untrusted certificates are injected into TrustManagerFactory.

[timja]

Right yeah I haven't had time to validate whether my putting an intermediate in then it would be trusted without the root.
e.g. in node.js it was fine as they validated the chain separately.

Do you happen to know if there's a similar OS API to macOS I can use here? (I can validate against all certificates but may need to check a bunch).

[timja]

Do you happen to know if there's a similar OS API to macOS I can use here? (I can validate against all certificates but may need to check a bunch).

I think a combination of

• https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain
• https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certverifycertificatechainpolicy

[shalupov]

@timja e.g. https://github.com/pmverma/winscp/blob/af9dfcb8fa08e8defff1e4814a393174a4681819/source/core/Security.cpp#L155

[shalupov]

Interesting test will be to check whether ROOT -> INTERMEDIATE1 -> INTERMEDIATE2 will work

[shalupov]

I decided to merge this PR to have less stacked PRs around

[shalupov]

merged manually cc7cba2

added intermediate certificates check: 8819503