On Tue, 1 Apr 2025 16:13:55 GMT, Tim Jacomb <d...@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. > > It may mean that we need to enhance the `KeyStore` API to be able to store > > arbitrary certificates. Or you could consider storing these additional > > certificates in a `CertStore`. > > The `KeyStore` can store them arbitrarily right now can't it but is it that > currently anything in there is 'trusted'? > > > I am also not sure the use case is common. Typically a web server will send > > its entire chain, and not just the server certificate. > > I don't think its very common either but I think its becoming more common > with ZTNA providers (Zero Trust Network Access) being deployed in a lot of > organisations for compliance and security reasons. > > When these are third party providers they often won't have your root cert and > they may or may not provide the complete chain (I don't know if its > configurable to do that) my organisation's one certainly doesn't provide the > whole chain and there are other bug reports out there from other > organisations too. > > > Certainly open to hearing alternate opinions if I have overlooked something. > > An alternative option would be a truststore or some other mechanism that just > does > [SecTrustEvaluateWithError](https://developer.apple.com/documentation/security/sectrustevaluatewitherror(_:_:)?language=objc) > without any of the complexity of providing the actual certificates but just > checks the trust for the presented chain. Not sure how complex that would be. I think at this point if this is important enough we would need to explore other options. I haven't had time to really think about the different use cases you mention above, but providing more rationale and pointers to issues where users are having issues with Java because of this issue would help. Thanks, Sean ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770193958
