> 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 <timjaco...@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 <ale...@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 <timjaco...@gmail.com> wrote: >> >> Some people who received this message don't often get email from >> timjaco...@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 >> >> >>
