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.