Changing IDP Metadata Cert

Jason Rotunno jrotunno at
Tue Aug 16 18:11:05 UTC 2022

I'm in the process of setting up SSO with a new service provider but it
won't accept our IdP's metadata because the cert in it is SHA-1. I'm
looking for info on how to update it and I have some questions (our IdP is

According to the 'Signing Key and Certificate' section on this page
"The certificate is communicated via a <md:KeyDescriptor use="signing">
element in SAML metadata." Our metadata doesn't have any reference to
'signing'. Instead it has:

[ CERT ]

Apart from that, though, this sounds like what needs to be changed, given
the fact that it's in the metadata. I do see, however, that the end of that
page has a 'Metadata Signing Keys and Certificates' section. And while the
section title sounds relevant, the contents do not. So my first question is
which key/cert needs to be updated, the signing key/cert or the metadata
signing/key cert?

If the former, that page explains: "This keypair ideally never changes
outside of a catastrophic event. If your policies require you to change it,
you should budget a large amount of time from the IdP operations team and
all of your affected customers to coordinate the change, or you will need
to accept a significant amount of service disruption."

I'm assuming that when SHA-1 went EOL, everyone had to deal with this. Can
someone elaborate on what is involved? Who are the customers, the service
providers? What exactly needs to be coordinated?

Finally, are the steps to update the key/cert documented? I did some
searching but didn't find anything. I was thinking I could just generate
them with openssl, but someone (I can't find the post now) mentioned using
a script in the bin directory. I also notice that there's an
'idp.signing.config' setting in conf/idp.xml (it's commented out in our
config) so I'm wondering if there are other places things need to be



Jason Rotunno
System & Security Administrator
Swarthmore College
500 College Ave
Swarthmore, PA 19081

*VERIFY before you click!!*
  - Attackers make their emails look like they come from someone they don't.
  - Attackers make links look like they go to websites they don't.
  - Attackers disguise malware as receipts, invoices, faxes, etc.

Forward suspicious emails to phishing at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list