shibboleth Idp attributes with vendor SP using Samly

Peter Schober peter.schober at
Wed Jul 15 16:29:27 UTC 2020

* Peter Schober <peter.schober at> [2020-07-15 18:06]:
> So you installed a brand new IDPv4, giving it a separate entityID and
> registered /another/ IDP with the SP?
> Or did you simply install a brand new IDPv4, using the existing
> entityID of your IDPv3 IDP, but using the auto-generated (i.e.,
> completely different) key material that the installer would only
> create for new installs (but not for upgrades) and expect the SP to
> work, even though it only has the public keys for your old IDP
> available?
> I can only guess at the meaning of the error message from the SP.
> To get the precise meaning you'd have to ask the SP or -- more
> likely -- read the source code where that error comes from.
> FWIW, I couldn't find the string "cert_not_accepted" in either the
> "samly" project source code nor in
> its dependency -- maybe I'm looking
> at the wrong code, or maybe the error comes from the applicaton, not
> the libraries I've been referring to.

OK, Github's code search simply sucks. But the issue (and code
reference) below explains the meaning and also confirms my guess that
you've probably misunderstood/botched your IDP upgrade by using
completly new/different keys from the installer. Copying over your old
IDPv3 keys should fix that. Or redoing your IDPv4 instance, really,
because who knows how many other things you've forgotten to carry over?

  "If you search for cert_not_accepted in esaml, you will find that
  this error occurs when the cert fingerprint is not trusted. It is
  possible for this to happen when the certificate in the idp metadata
  file specified in the config does not match the one coming through
  the SAML response."


More information about the users mailing list