KeychainStore include user and predefined roots within one truststore

[Tim Jacomb]

> It looks like the use case you described can be easily achieved by
wrapping all certificates from the KeychainStore-ROOT and KeychainStore
stores into one custom Trust Store.

1. I've implemented something like that in
https://github.com/JetBrains/jvm-native-trusted-roots/pull/6 (although it
just gets all the certificates rather than does it as a trust store).
Is KeychainStore-ROOT something that would be backportable, as it's only
available from Java 23?

2. I still think there should be value in a built-in store that can provide
all of the OS trusted certificates, so that an admin could specify a
truststore pointing to the OS rather than relying on the application having
implemented a custom truststore.

Thanks
Tim

On Sat, 4 Jan 2025 at 08:45, Tim Jacomb <timjacomb1 at gmail.com> wrote:

> Hi Alexey
>
> > It looks like the use case you described can be easily achieved by
> wrapping all certificates from the KeychainStore-ROOT and KeychainStore
> stores into one custom Trust Store. As far as I know, all certificates
> should be in one or another Keychain store.
>
> Yes that would work although I would like to avoid that. We have
> developers using many different Java versions from different vendors and it
> would be great if you could just get them to set
> "JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStoreType=KeychainStore-Something".
>
> Then validation could just work out of the box without having to do
> anything.
>
> > Also, please look at my comments for the patch for intermediate certs
> Thanks that makes sense, I'll take a look and try implement on Monday
>
> On Sat, 4 Jan 2025 at 00:36, Alexey Bakhtin <alexey at azul.com> wrote:
>
>> Hello Tim,
>>
>> It looks like the use case you described can be easily achieved by
>> wrapping all certificates from the KeychainStore-ROOT and KeychainStore
>> stores into one custom Trust Store. As far as I know, all certificates
>> should be in one or another Keychain store.
>>
>> Also, please look at my comments for the patch for intermediate certs:
>> https://github.com/openjdk/jdk/pull/22911#issuecomment-2569957562
>>
>> Thank you
>> Alexey
>>
>>
>> On 3 Jan 2025, at 03:29, Tim Jacomb <timjacomb1 at gmail.com> wrote:
>>
>> Some people who received this message don't often get email from
>> timjacomb1 at gmail.com. Learn why this is important
>> <https://aka.ms/LearnAboutSenderIdentification>
>> Caution: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know
>> the content is safe.
>>
>> Hi
>>
>> 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)
>> 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).
>>
>> 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).
>>
>> 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?
>>
>> Thanks
>> Tim
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250107/d1de5507/attachment-0001.htm>