On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer <clan...@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. No trust settings will be reported as "inputTrust" being null. If the >> certificate is trusted with no specific records, "inputTrust" will be an >> empty list. >> 3. The Java Method to add a certificate now checks for "self signed" >> certificate not only by checking whether it was signed with its own key but >> it must also not be a root certificate that can be used to sign other >> certificates. This is done by inspecting the key usage extension. >> 4. We now trust certificates that are either "real" self-signed certificates >> or certificates that have an explicit trust entry with no sub-records that >> would deny the certificate for any purpose. >> 5. 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: > > Check return code of SecTrustSettingsCopyTrustSettings and address review > comments Before your new change, such a certificate is not trusted, because `SecTrustSettingsCopyTrustSettings` returns `errSecItemNotFound` so `jm_createTrustedCertEntry` is not called at all. I am not sure if such a certificate is meant to be always trusted. Note that you can create such an entry with only `security add-certificates` but not `security add-trusted-cert`. macOS allows anyone to run the first command but prompts you for an administrator password when running the second. The name of the second command also implies that it's the only way to assign trust to a certificate, IMHO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552229495
