Cert rollover sanity check

[Mike Flynn]

Thanks, Tom.  So, based on your comments, my step 2 will look like this:

        Change old setting FROM:
        
         <!-- Your SP generated these credentials.  They're used to talk to IdP's. -->
         <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/>
        
        TO:

        
        <CredentialResolver type="Chaining">
        <!-- 
             Certificate/Private key pairs are read in sequence.
             Unless specificially defined only the first 
             CredentialResolver is used for attribute requests.
        -->
              <CredentialResolver type="File" keyName="Standby" use="encryption"
                                 key="C:\opt\shibboleth-sp\etc\shibboleth\sp-key-2011.pem" 
                                 certificate="C:\opt\shibboleth-sp\etc\shibboleth\sp-cert-2011.pem"/>
             <CredentialResolver type="File" keyName="Active" 
                                 key="C:\opt\shibboleth-sp\etc\shibboleth\sp-key.pem" 
                                 certificate="C:\opt\shibboleth-sp\etc\shibboleth\sp-cert.pem"/>
        </CredentialResolver>


That about right?  I now need to contact the Canadian CAF to see how to coordinate this change with them at the same time as InCommon <sigh/>



________________________________
From: Tom Scavo <trscavo at gmail.com>
To: Shib Users <users at shibboleth.net>
Sent: Thursday, October 20, 2011 1:48 PM
Subject: Re: Cert rollover sanity check

On Thu, Oct 20, 2011 at 12:50 PM, Mike Flynn <shibbolethlynda at yahoo.com> wrote:
>
> If anyone sees any issues with my process here, any comments are
> appreciated!

Your metadata looks good, but I think you want to take another look at
your software configuration. At your step 2, you want to make sure
that the new key is used as a *decryption key only*. You don't want to
sign with the new key because not all IdPs will have the new metadata.
So I suggest you add use="encryption" to the configuration of the new
key.

Once you do that, you can safely move the new key to be first in the
chain. As the migration proceeds, and the new metadata propagates, the
best decryption key to try first (from an efficiency point of view) is
the new decryption key.

As far as the wait time is concerned, I don't disagree with anything
that Scott said. However, if you make the changes discussed above, you
can wait indefinitely without penalty, so unless you're 100% sure that
all IdPs have refreshed their metadata, there's no harm in waiting.
Keep in mind that InCommon metadata has a three-week lifetime. After
three weeks, the metadata expires and software starts to fail. So I'd
feel pretty confident that all IdPs have refreshed by then.

Tom
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111021/546bc735/attachment.html