Log and rethrow added in d536a2bdc75d149c6fd7fa0402333181b4249449.

In X509Support.getAltNames() I'm going to add the catch/log/rethrow, just to get it logged in the unlikely event this happens.

I don't think it's warranted to try and handle in any of the callers (there's about 4 of them; 3 in OpenSAML, 1 in the IdP).  The reason is that unlike what Rod already fixed - which were support methods that are essentially parsing a byte[] (or base64 or File) - this method takes an existing java.security.cert.X509Certificate instance.  AFAIK it's extremely unlikely that we would have one of those that has somehow been parsed successfully to the Java object, but somehow has corrupt or invalid alt name extension such that it throws a fatal cryptacular EncodingException.  So IMHO we shouldn't worry about those.

Rod's changes look fine to me.  This is the problem though with libraries that throw unchecked RuntimeExceptions, we may not have gotten all of the places and it's pretty hard to find them other than by trial and error, seeing in the wild, etc.

As far as the X509Support.getAltNames() goes, I don't know what we can do other than catch it, log it and rethrow.  We can't change the signature to throw a checked exception until 4.0.0 and we can't just return null or empty List, since given the security function of some of the callers (trust engines, client authN), that might cause bad things to happen...

Meaning the SP's signing key corrupt? Yeah, that's more problematic, it's too early.

As long as the log is clear, that's the improvement I was after.

The bottom line is that there is a Cryptacular exception EncodingEceptuion that we need to be aware of and funnel into one of our own exceptions at the appropriate level.

I have made a stab at fixing this as a7b45e2cb

However I'm not going to resolve this I'll ask Brent to check my sums, since there is more going on here than meets the eye

• I see that that this exception is also thrown by CertUtil.subjectAltNames but where we call it (in X509Support.getAltNames we cannot convert it into a known exception in the same way we (now) do for X509Support.decodeCertificate and X509Support.decodeCertificates

• Nothing in secuirty and X509 is as simple as it seems, so why should this be any different?

• The top level behavior is now very diferent between the two failing cases:

  • If the Signing Certicate is corrupt the login stops at the IdP with a Message Security Error.

  • If the Encryption Certificate is corrupt the login stops back at the SP with a SAML error message

I totally get why this happens, its just slightly weird.