RFR: 8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates [v6]

Weijun Wang weijun at openjdk.org
Tue May 23 15:10:50 UTC 2023


On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose.
>> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove another obsolete comment

The code change looks fine to me. Thanks.

Since this is rather a big behavior change, I think a CSR and a release note are required. The previous release note on this is at https://www.oracle.com/java/technologies/javase/19-relnote-issues.html#JDK-8278449.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559419631



More information about the security-dev mailing list