Skip to Content.
Sympa Menu

metadata-support - [Metadata-Support] RE: Question on updating metadata with new certificates

Subject: InCommon metadata support

List archive

[Metadata-Support] RE: Question on updating metadata with new certificates


Chronological Thread 
  • From: "Cantor, Scott" <>
  • To: "" <>
  • Subject: [Metadata-Support] RE: Question on updating metadata with new certificates
  • Date: Thu, 26 May 2016 15:01:22 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=osu.edu; incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=bestguesspass action=none header.from=osu.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

> I've been reading the documentation on the site for a few days now but I'm
> still not sure how we can update our certificates successfully without
> potentially causing a service interruption to our clients.

If you're running Shibboleth or software with similar features, then the
answer is you can do that for IdPs that are consuming metadata correctly and
cannot do it otherwise. For most SPs, that means they can do it for some and
not others. That's just reality, and is why you should in general never
change them unless forced to.

> We currently have one certificate that used for both signing and
> encryption. We would like to
> replace this with two new certificates, one for signing and another for
> encryption. It seems as though all the documentation around this points to
> replacing one cert for another, not how to replace one certificate with two.

Can I ask why? In fact, what are you using the signing key for as an SP?

In general, a SAML 2 SP may not need a signing key at all, and you may be
better off just avoiding it. If you don't do queries or support artifacts or
logout, you don't need one.

But doing both is just a generalization of the problem and I would probably
break it into two parts, and do one part before the other. I don't know
offhand which makes sense to do first, probably the signing half. I would
generate the new signing pair, register that into the metadata as
use="signing", and then switch to it with use="signing" in the Shibboleth SP
config (again, I can only speak to how Shibboleth works) while leaving the
original in place with use="encryption".

But in the middle of that, you have the huge manual mess of dealing with all
the rest of the IdPs not using metadata and many of them will be totally
broken and not support multiple signing keys. So you probably end up having
to set up special rules to tie the old key or new key to specific IdPs.

Once that's all done, the old keypair is basically an encryption key and can
be rolled over using the procedure for that.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page