Certificate Load Issue within Java / Shibboleth 3.2.1
Brent Putman
putmanb at georgetown.edu
Tue Jul 25 03:32:08 EDT 2017
On 7/25/17 1:43 AM, Reid Watson wrote:
> Hi Everyone
>
> We just received the new metadata from the vendor but when shibboleth attempted to sign the request it couldn’t process the certificate
>
> Metadata Location: http://blogs.auckland.ac.nz/Shibboleth.sso/Metadata
>
> -----BEGIN CERTIFICATE REQUEST-----
> <snip>
> -----END CERTIFICATE REQUEST——
>
>
> - Key-Size EC 384 bits
> - Signature Algorithm Strong (ecdsa-with-SHA256)
Cool. So they are signing with an EC certificate (presumably the 3rd
one listed in metadata). We haven't seen many of those yet in the
wild. Yay. You win the "interesting question of the week" prize. :-)
(Btw, the header/footer there should be "BEGIN/END CERTIFICATE" if you
want to read with OpenSSL, etc. This is an actual cert, not a CSR).
>
> 2017-07-25 13:53:16,725 - WARN [org.opensaml.saml.common.binding.security.impl.BaseSAMLSimpleSignatureSecurityHandler:291] - Message Handler: Error evaluating the request's simple signature using the trust engine
> org.opensaml.security.SecurityException: Error resolving trusted credentials
> at org.opensaml.xmlsec.signature.support.impl.ExplicitKeySignatureTrustEngine.doValidate(ExplicitKeySignatureTrustEngine.java:147)
> Caused by: net.shibboleth.utilities.java.support.resolver.ResolverException: Error processing KeyInfo child element
> at org.opensaml.xmlsec.keyinfo.impl.BasicProviderKeyInfoCredentialResolver.processKeyInfoChild(BasicProviderKeyInfoCredentialResolver.java:322)
> Caused by: org.opensaml.security.SecurityException: Error extracting certificates from X509Data
> at org.opensaml.xmlsec.keyinfo.impl.provider.InlineX509DataProvider.extractCertificates(InlineX509DataProvider.java:192)
Is this from a signed SAML request? That's what it looks like to me...
except it can't be Redirect b/c that doesn't convey a KeyInfo. So it
would have to be POST SimpleSign, which is also unusual. Although I
guess since it appears to be a Shibboleth SP, then it's supported, and
maybe there's some way this has been (mis)configured.
> Caused by: java.security.cert.CertificateParsingException: java.io.IOException: Only named ECParameters supported
> at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:169)
> Caused by: java.io.IOException: Only named ECParameters supported
> at sun.security.ec.ECParameters.engineInit(ECParameters.java:150)
Well, this is a Genuine Error (tm). Assuming you are using Oracle Java
or OpenJDK with the standard JCA security providers, it simply doesn't
support that format of EC certificate. As the error states, they (for
some reason) only support EC keys in the named curve style, not with
the explicitly enumerated curve parameters. So this cert is simply not
going to work with the Shib IdP - or indeed anything Java-based,
without installing a custom security provider. I recall this
limitation being the case, but don't think I've ever actually seen it
happen, since I think most people are using the named curve style in EC
certs, at least that I've seen.
I *think* Bouncy Castle does support explicit EC key curve parameters.
So if you really wanted/needed to get this working as-is, then you'd
have to install BC as the preferred security provider. That's a bit
iffy because it's going to affect all the crypto operations - I don't
think we know if that works 100%.
Honestly, though, you probably don't want to go that route. Instead
either 1) see if the SP can sign to you using one of the other 2 certs,
which are good old RSA ones (it's a Shib SP, so they should be able to
do that) or 2) see if they can regenerate that EC cert to use named
curve style key representation. Since no standard current Java version
supports that EC cert format out-of-the-box (and probably other
software as well), that was probably a bad choice on their part,
although perhaps unintentionally.
> - Workaround: Manually updated the metadata (removing the certificate) and shibboleth reloaded the metadata correctly
> - I have already loaded “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy"
>
Neither of those is relevant, although you'd see the same issue with
the metadata credential resolver trying to load that EC cert as well.
It's all the same KeyInfo processing code.
--Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170725/19e9afd4/attachment-0001.html>
More information about the users
mailing list