"no signing credential resolved, leaving message unsigned"

[sacha+shibboleth at ssl.co.uk]

Afternoon,

I'm using shibboleth SP 3.5.0 on Linux.

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.

However, the SSO dance ends with this in the browser:

    opensaml::FatalProfileException at
    (https://nsm-test.collectionsindex.com/Shibboleth.sso/SAML2/POST)

    SAML response reported an IdP error.

    Error from identity provider:

    *Status:* urn:oasis:names:tc:SAML:2.0:status:Requester

Looking through the logs, I see this pair in shibd_warn.log which I 
assume are indicative of the problem:

    no signing credential resolved, leaving message unsigned
    error processing incoming assertion: SAML response reported an IdP
    error.

(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.)

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

  * I didn't change anything else
  * the key and certificate files exist
  * the password is correct

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.

The snippet of shibboleth2.xml for the site in question is

         <ApplicationOverride ...>
             <AttributeExtractor .../>

             <CredentialResolver type="Chaining">
             <CredentialResolver type="File" use="signing"
                 key="/path/to/signing.key"
                 password="TOPSECRET"
                 certificate="/path/to/signing.crt"/>
             <CredentialResolver type="File" use="encryption"
                 key="/path/to/encryption.key"
                 password="TOPSECRET"
                 certificate="/path/to/encryption.crt"/>
             </CredentialResolver>

         </ApplicationOverride>
     </ApplicationDefaults>

I've cranked what I think is the relevant logging:

log4j.category.XMLTooling.Signature.Debugger=DEBUG, sig_log

but that doesn't seem to yield any more info. I suppose it doesn't even 
get to the signing.

So initially at least my questions are,

  * 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?
  * is there any further logging I can enable to diagnose the credential
    resolver issue?
  * 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)
  * is there a way to get more information in the default error page, or
    would I need to implement my own error template?

Many thanks for any help or advice.

Sacha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250618/7ee50103/attachment.htm>