Using a second signing certificate

[Jason Gauthier]

Thanks, that was extremely helpful!

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, July 15, 2013 1:36 PM
To: Shib Users
Subject: Re: Using a second signing certificate

On 7/15/13 1:16 PM, "Jason Gauthier" <jgauthier at lastar.com> wrote:

>>You can't do key rollover unless the metadata is decoupled from the 
>>configuration so that it can be altered ahead of the change. InCommon 
>>has a >number of wiki pages that describe how this works in some 
>>detail (there are some in the Shibboleth wiki as well, but more 
>>specifically geared to >the software).
>
>Okay. This makes sense, but is still a confusing concept for me.

You can't start signing with a key that you haven't told every system about or one or more of them will break.

In turn, you don't want partners directly consuming a metadata file generated from a system that has to be configured with all of the signing keys it might use in order to generate that metadata, because you're risking violating the first rule (unless you can configure the key but guarantee it won't be used until later of course).

The upshot is that metadata, used correctly, is largely a separate process, and that's why federations like InCommon exist and provide value.

The metadata changes in conjunction with configuration changes, but not in lockstep with them. The specifics depend on the change.

I think you'll understand this better looking at InCommon's documentation.

>Yes, more or less.  I actually had 2 Shib systems break, and two vendor 
>systems.  Those vendors had me supply a certificate for signing.
>On 07/09, my ADFS server "switched" keys, and all the vendors I 
>supplied the signing key to previously just broke.

That is essentially always going to happen with some systems because most systems other than Shibboleth don't understand metadata and won't use it anyway. The specific case of the Shibboleth SPs was self-inflicted failure, perhaps, but probably not the other two.

The double whammy is an SP that can't handle multiple valid keys, in which case you're screwed and have to schedule the change no matter what.

And the sum of all of this is that you should never rely on certificates with periods measured in small numbers of years, avoid software that cares about certificates where possible (ADFS does unfortunately), and above all, never change a key you don't have to.

>Since I don't have control over their systems, I am trying to 
>understand this from the perspective of what I do have control over. 
>Which is my ADFS and a couple Shib instances.

In those cases, you need separately maintained metadata you can manipulate to adjust keys supplied to those systems. Then it just works.

>That makes sense.  I don't really have expectations, but more looking 
>into what process I can use so that next year this doesn't break out 
>without anyone understanding why, or preferably what I can do to put 
>all the pieces in place now for longevity.
>
>I'm still not certain what those pieces are.

The TrustManagement topic in the wiki is about all I can point you to.
There is, again, a reason federations exist, to help with this problem.
Unfortunately, the number of people using this stuff who are diligent enough to ask these questions is fairly small, so most of the time people just don't get why this is useful.

And the fact that nothing but Shibboleth, and to some degree simpleSAML.php, can do any of this at all means that the value proposition behind it is constrained by that. You always have partners running broken software that simply dodges all this and makes it a manual process.

>Okay.  It's comforting to know that editing the metadata is common.  I 
>guess I need to figure out how to handle key roll over with Shib, in my 
>environment... and maybe discuss this with my vendors as well.

I don't think you'll like the answers unfortunately, but we're all struggling with this.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net