Some additional thoughts below.
On 1/4/25 3:45 AM, Tim Jacomb wrote:
Following on from:
https://bugs.openjdk.org/browse/JDK-8320362
It's now possible to get system roots on macOS devices in the
truststore: KeychainStore-ROOT.
That's quite useful.
Unfortunately it doesn't cover everything though.
In practice there's two issues I've found in trying to use it:
1. It is missing custom CA certificates, (which would have been
included if Apple APIs - SecTrustCopyCustomAnchorCertificates were
used, see discussion at
https://github.com/openjdk/jdk/pull/16722#issuecomment-1948542783)
I don't think you are suggesting this, but I don't think it should
include custom CA certificates if they are stored or trusted differently
than roots. KeychainStore-ROOT should represent the System Roots that
have been approved by Apple's root program. It is important that we
don't change that meaning. If there is a way to import a custom CA into
System Roots and mark it trusted, then maybe it would just work. Have
you tried that?
2. It is missing intermediate certificates which are required for
custom CA certificates, (these are not included with
SecTrustCopyCustomAnchorCertificates although the root CAs above are).
Why do you need to include intermediate CA certificates? Typically,
these would be sent by a TLS server and validated as part of a
certificate chain. If you are sending a truncated chain and
short-circuiting the validation process by trusting the intermediate CA
directly, then maybe those intermediate CAs should be treated just like
a root CA, as they really are anchors.
The architecture at my company that is using ZScaler MiTM proxy is:
Root CA -> Intermediate 1 -> Intermediate 2 -> Leaf
Where:
* All certs are in admin domain kSecTrustSettingsDomainAdmin
* Root CA is marked as always trust
* Intermediate 1 and 2 are Unspecified
Not all certificates get re-signed by Zscaler, some URLs are bypassed.
So I need to be able to trust both custom CAs and the predefined roots.
I was thinking of creating a new truststore: KeychainStore-ALL.
I think it could just reuse all the existing code, and work pretty
seamlessly, (I have a separate patch for intermediate certs not
working correctly - https://github.com/openjdk/jdk/pull/22911).
Based on my questions above, I am not sure yet whether this Enhancement
is something that would be useful.
If you are proposing that we look at your contribution, have you signed
the OCA?: https://openjdk.org/guide/#sign-the-oca. But even before we
look at that, I think you need to describe the use case more, and the
motivation. Can you explain how your server certificate is configured
and how the TLS handshake fails and why?
Thanks,
Sean
It could be improved at the expense of more code to use the Apple APIs
directly (SecTrustCopyCustomAnchorCertificates) and not read the
keychain file.
What do you think?
