RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5]
Sean Mullan
mullan at openjdk.org
Tue Apr 1 19:26:27 UTC 2025
On Mon, 27 Jan 2025 22:43:32 GMT, Tim Jacomb <duke at openjdk.org> wrote:
>> ## The change
>>
>> Without this change intermediate certificates that don't have explicit trust settings are ignored not added to the truststore.
>>
>>
>>
>> ## Reproducer
>>
>> See https://github.com/timja/openjdk-intermediate-ca-reproducer
>>
>> Without this change the reproducer fails, and with this change it succeeds.
>>
>> ## Example failing architecture
>>
>> 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
>>
>> Previously Root CA would be found but intermediate 1 and 2 would be skipped when verifying trust settings.
>>
>> ## Background reading
>>
>> ### Rust
>> see also Rust Lib that is used throughout Rust ecosystem for this:
>> https://github.com/rustls/rustls-native-certs/blob/efe7b1d77bf6080851486535664d1dc7ef0dea68/src/macos.rs#L39-L58
>>
>> e.g. in Deno `https://github.com/denoland/deno/pull/11491` where I've verified it is correctly implemented and works in my setup
>>
>> ## Python
>>
>> I also looked at the Python implementation for inspiration as well (which also works on my system): https://github.com/sethmlarson/truststore/blob/main/src/truststore/_macos.py
>
> Tim Jacomb has updated the pull request incrementally with one additional commit since the last revision:
>
> Make test output easier to read
We need to be really careful here. With this fix we are deciding at runtime that these intermediate certificates should be treated as `KeyStore.TrustedCertificateEntry` objects just because they validated ok, and without any interaction with the user or application.
Also, the JDK does not rely on certificate chain validation from the OS. The JDK has its own PKIX `CertPathValidator` implementation and has its own restrictions on weak algorithms, etc which is a key part of establishing trust in certificates used in TLS, signed JARs, etc. You are now delegating this to MacOS as a mostly invisible change which brings in a new set of security concerns which may make it less secure or at a minimum requires resources to ensure this code is properly reviewed, audited, etc.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770471055
More information about the security-dev
mailing list