On Tue, 1 Apr 2025 17:29:57 GMT, Sean Mullan <mul...@openjdk.org> wrote:
> > > I am dubious that this is the right thing to do. There is a distinct > > > difference between a certificate that is trusted and one that requires > > > additional validation to determine if it is trusted. Blindly trusting > > > self-signed certificates is very dangeorous, and unless I am mistaken, > > > this seems to be what this code may do. I do not think lumping both of > > > these certificates into "trusted" certificates is the right thing to do. > > > > > > There is no 'blind' trust in this pull request. Any 'non trusted' > > certificate is validated via the OS APIs, once it has been validated by the > > OS then it is a trusted certificate it just needed its chain verified to > > the root. > > > > That helps, but just because it successfully validated once does not mean it > should be treated as a trusted certificate (essentially as a trust anchor). > It may later be revoked/expired, its key or signature algorithm may weaken or > it may fail validation for some other reason, or CA certificates further up > the chain may change and affect the trustworthiness of this certificate. Exactly the same happens with other certificates with trust settings. They are loaded on start and not verified for trust settings later. They are still trusted, If the Trust Settings are updated manually in the native KeyChainStore. Also, it affects KeychainStore only and does not affect KeychainStore-ROOT certificates, as it is static. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770352993
