Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8308690

KeyStore of type KeychainStore, provider Apple does not show all trusted certificates

    XMLWordPrintable

Details

    • behavioral
    • medium
    • Hide
      There is a major behavior change introduced by this code change.

      If a certificate is only trusted in admin domain but not in user domain, it was not shown as a trusted certificate entry. Now it is. This is an expected behavior. According to the Apple documentation at https://developer.apple.com/documentation/security/sectrustsettingsdomain/admin, the admin domain contains "locally administered, system-wide trust settings".

      When a certificate has trust settings in both domains, according to the Apple documentation at https://developer.apple.com/documentation/security/1400261-sectrustsettingscopytrustsetting (notice the outer OR and inner AND in the Discussion part), it is trusted if trusted by either the user or admin domain. There are other documents on the net (Ex: https://github.com/golang/go/commit/60cbff6f1906ec1bbc939acfb7cc97b18e639ce9) suggesting that user settings would override admin settings, but our own experiments shows it's the opposite direction. To be safe, we decide to only trust a certificate if there is at least one "allow" in all trust settings and there is no "deny" in them, i.e. at least one "approval" and no "veto".

      This means even with trust settings only on the user side, if there are both "allow" and "deny" items inside, we switched from trust to distrust after this code change. We think this is a correct and safe change since the Java keystore does not (yet) have fine-grained trust settings for different purposes and trusting a certificate means trusting it for any usage the certificate itself claims (in its key usage extensions).

      We label the compatibility risk as medium but we think all behavior changes are necessary for this bug fix.
      Show
      There is a major behavior change introduced by this code change. If a certificate is only trusted in admin domain but not in user domain, it was not shown as a trusted certificate entry. Now it is. This is an expected behavior. According to the Apple documentation at https://developer.apple.com/documentation/security/sectrustsettingsdomain/admin, the admin domain contains "locally administered, system-wide trust settings". When a certificate has trust settings in both domains, according to the Apple documentation at https://developer.apple.com/documentation/security/1400261-sectrustsettingscopytrustsetting (notice the outer OR and inner AND in the Discussion part), it is trusted if trusted by either the user or admin domain. There are other documents on the net (Ex: https://github.com/golang/go/commit/60cbff6f1906ec1bbc939acfb7cc97b18e639ce9) suggesting that user settings would override admin settings, but our own experiments shows it's the opposite direction. To be safe, we decide to only trust a certificate if there is at least one "allow" in all trust settings and there is no "deny" in them, i.e. at least one "approval" and no "veto". This means even with trust settings only on the user side, if there are both "allow" and "deny" items inside, we switched from trust to distrust after this code change. We think this is a correct and safe change since the Java keystore does not (yet) have fine-grained trust settings for different purposes and trusting a certificate means trusting it for any usage the certificate itself claims (in its key usage extensions). We label the compatibility risk as medium but we think all behavior changes are necessary for this bug fix.
    • Other
    • JDK

    Description

      Summary

      Modify the KeychainStore KeyStore implementation to be more precise on what a trusted certificate is in a macOS KeyChain.

      Problem

      With JDK-8278449, we started exposing only certificates with trust settings on OS level (e.g. maintained via Keychain Access app or security command) as trusted certificate entries in a Java KeyStore loaded from a macOS Keychain. The initial implementation was not good enough because we only checked user domain trust settings. However, on MacOS Keychain trust settings can also be present in the admin domain.

      Solution

      Modify the KeychainStore KeyStore implementation so that a certificate is trusted (aka shown as a TrustedCertificateEntry in the KeyStore object) if:

      1. It has trust settings in at least one of the user domain or the admin domain, and
      2. Of all these trust settings, there is at least one "allow" item and no "deny" item

      Specification

      No Specification. This is an implementation detail.

      Attachments

        Issue Links

          Activity

            People

              clanger Christoph Langer
              mbaesken Matthias Baesken
              Weijun Wang
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: