<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Afternoon,</p>
<p>I'm using shibboleth SP 3.5.0 on Linux.<br>
</p>
<p>Our signing and encryption certificates expired, so the IdP folk
asked us to replace them. The process was to generate signing and
encryption keys, use them to generate CSRs, submit them to the IdP
people, receive the certificates from them, sign and submit a
metadata file, then switch things over at the IdP and SP ends.<br>
<br>
However, the SSO dance ends with this in the browser:<br>
</p>
<blockquote>
<p class="error">opensaml::FatalProfileException at (<a
class="moz-txt-link-freetext"
href="https://nsm-test.collectionsindex.com/Shibboleth.sso/SAML2/POST"
moz-do-not-send="true">https://nsm-test.collectionsindex.com/Shibboleth.sso/SAML2/POST</a>)</p>
<p>SAML response reported an IdP error.</p>
<p>Error from identity provider:</p>
<strong>Status:</strong>
urn:oasis:names:tc:SAML:2.0:status:Requester</blockquote>
<p>Looking through the logs, I see this pair in shibd_warn.log which
I assume are indicative of the problem:<br>
</p>
<blockquote>
<p>no signing credential resolved, leaving message unsigned<br>
error processing incoming assertion: SAML response reported an
IdP error.<br>
</p>
</blockquote>
<p>(I'm no OAuth expert but my hunch would be, for some reason shibd
can't figure out how to sign requests so it doesn't and the IdP
tells it to go away.)<br>
<br>
What I've changed in shibboleth2.xml are the key, password and
certificate attributes of the relevant CredentialResolvers. I've
verified (manually and using shibd -t) that</p>
<ul>
<li>I didn't change anything else</li>
<li>the key and certificate files exist</li>
<li>the password is correct<br>
</li>
</ul>
<p>DuckDuckGo gives no hits for the error message, while Google at
least points me to the source code. Browsing the code I can see
where the credential resolver error is reported, but I don't think
there are any clues there as to why it can't determine a resolver
in my case.</p>
<p>The snippet of shibboleth2.xml for the site in question is <br>
</p>
<p> <ApplicationOverride ...><br>
<AttributeExtractor .../><br>
<br>
<CredentialResolver type="Chaining"><br>
<CredentialResolver type="File" use="signing"<br>
key="/path/to/signing.key"<br>
password="TOPSECRET"<br>
certificate="/path/to/signing.crt"/><br>
<CredentialResolver type="File" use="encryption"<br>
key="/path/to/encryption.key"<br>
password="TOPSECRET"<br>
certificate="/path/to/encryption.crt"/><br>
</CredentialResolver><br>
<br>
</ApplicationOverride><br>
</ApplicationDefaults></p>
<p>I've cranked what I think is the relevant logging:</p>
<p>log4j.category.XMLTooling.Signature.Debugger=DEBUG, sig_log<br>
</p>
<p>but that doesn't seem to yield any more info. I suppose it
doesn't even get to the signing.<br>
<br>
So initially at least my questions are,</p>
<ul>
<li>am I on the right trail, or is the credential resolver thing
likely to be a red herring given the IdP error reported in the
browser?</li>
<li>is there any further logging I can enable to diagnose the
credential resolver issue?</li>
<li>is this likely to be an entirely SP-side configuration issue,
or could it be somehow IdP related, e.g. some fault in the
metadata.xml I provided? (I'm not sure to what extent to involve
the IdP people yet)</li>
<li>is there a way to get more information in the default error
page, or would I need to implement my own error template?<br>
</li>
</ul>
<p>Many thanks for any help or advice.</p>
<p>Sacha<br>
</p>
</body>
</html>