KeychainStore include user and predefined roots within one truststore

[Tim Jacomb]

Responses below

On Tue, 7 Jan 2025 at 22:15, Sean Mullan <sean.mullan at oracle.com> wrote:

> 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.
>
No, I'm not suggesting we change the 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?
>
System Roots is read-only and can't be modified by the user, (yes I have
tried).

> 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?
>

Private CA solution that utilises intermediate, ZScaler has an intermediate
CA for resigning certificates but does not have the company root CA.


> Typically, these would be sent by a TLS server and validated as part of a
> certificate chain.
>

It is also valid for them to be trusted by the OS.
For example, Chrome, Rust and Python are all capable of doing this just
fine.


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

 Yes they are roughly, they shouldn't be set as 'trustAsRoot' though as
then the chain of trust isn't verified to the root only to the
intermediate, and e.g. if the root cert was removed or marked as distrusted
validation would still pass if the intermediate CA was configured as a root.

I've implemented validation in https://github.com/openjdk/jdk/pull/22911 as
per
https://developer.apple.com/documentation/security/sectrustsettingscopytrustsettings(_:_:_:)?language=objc
.

Specifically "However, an empty trust settings array isn’t the same as no
trust settings, where the trustSettings parameter returns NULL. No
trust-settings array means “this certificate must be verifiable using a
known trusted certificate”.

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

I've requested my employer to sign, hopefully, should be resolved soon.


> 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?
>

Which use-case are you asking about? If its about intermediate CA's with
the implementation in https://github.com/openjdk/jdk/pull/22911 then:

The use-case is so that Java is able to handle intermediate certificates in
internal PKI, specifically here is with developer laptops that have an
enterprise CA which is performing MiTM on most URLs.

There's a self-contained runnable reproducer in
https://github.com/timja/openjdk-intermediate-ca-reproducer

TLS handshake fails with PKIX path building error.

Chain is Root -> Intermediate -> Leaf in the runnable example although in
our real-world use-case its Root -> Intermediate 1 -> Intermediate 2 -> Leaf
If I run the example only with Root -> Leaf then it works fine...

Thanks
Tim




>
> 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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250108/c905a8c4/attachment.htm>