<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 7/25/17 1:43 AM, Reid Watson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0FF4A10E-DB0A-4612-8985-18B64C798A0C@auckland.ac.nz">
<pre wrap="">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: <a class="moz-txt-link-freetext" href="http://blogs.auckland.ac.nz/Shibboleth.sso/Metadata">http://blogs.auckland.ac.nz/Shibboleth.sso/Metadata</a>
-----BEGIN CERTIFICATE REQUEST-----
<snip>
-----END CERTIFICATE REQUEST——
- Key-Size EC 384 bits
- Signature Algorithm Strong (ecdsa-with-SHA256)</pre>
</blockquote>
<br>
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).<br>
<br>
<br>
<blockquote type="cite"
cite="mid:0FF4A10E-DB0A-4612-8985-18B64C798A0C@auckland.ac.nz">
<pre wrap="">
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)
</pre>
</blockquote>
<br>
<br>
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. <br>
<br>
<br>
<blockquote type="cite"
cite="mid:0FF4A10E-DB0A-4612-8985-18B64C798A0C@auckland.ac.nz">
<pre wrap="">
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)
</pre>
</blockquote>
<br>
<br>
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.<br>
<br>
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%.<br>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:0FF4A10E-DB0A-4612-8985-18B64C798A0C@auckland.ac.nz">
<pre wrap="">
- 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"
</pre>
</blockquote>
<br>
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.<br>
<br>
--Brent<br>
<br>
<br>
</body>
</html>