… or provide an API for those custom trust managers to query the PKIX path validation of the existing trust manager which does check the existing blocked.certs file.
I can say we went some some extra extend maintaining the full validation semantics of the JDK in addition to custom functions, so the existing blocking hook was enough for us. (Not sure why in the end it was not used to block the eMudhra certificates)
Gruß
Bernd
--
https://bernd.eckenfels.net
Hi,
How are you doing?
In practice, I noticed a few commonly used libraries wrapped with
their own trust stores. While the library might be happy with its TLS
connections, the hard-coded trust store makes it difficult for
customers to maintain trust.
What do you think to add a security property to block specific
certificates? The cert could be trust anchor, intermediate CAs, and
end entity certificate. We may use the system property as:
jdk.tls.client/server.disabledCertificates=skid:xxx, skid:yyy.
If this seems like the right approach, I can develop the design
further for your review.
Thanks,
Xuelei
