RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

Sean Mullan mullan at openjdk.java.net
Tue Oct 26 15:32:13 UTC 2021


On Mon, 25 Oct 2021 23:48:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Unless I am misunderstanding your comment, I don't think this is an issue in practice. The code inside the `X509CertImpl.getExtension` method only throws an Exception if invalid OIDs or attribute names are passed to the internal `get` methods of `X509CertInfo` and `CertificateExtensions`, which isn't possible when you are passing in known values/attributes. I think this is why the code swallows the exceptions and returns null, but it would be nice to have a comment explaining that.
>
> I was asking if `getIssuerAlternativeNameExtension` can throw the exception is IAE exists but not parseable.

Ok, I understand your comment now. I'm hesitant to change those methods to throw an exception because to be consistent all the `get*Extension()` methods should then throw an Exception. That might be the right thing to do, but it is a bigger change and more risky. The code that calls these internal methods is used for building certification paths, and if null is returned, it is as if the certificate did not contain the extension. That might be a more reasonable behavior than throwing an Exception, since it allows the code to find other potential certificates or certification paths. Adding certpath debug can always be used to find out more about why certain certificates were not selected.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6106



More information about the security-dev mailing list