Renewing certificates on windows installation

[Cantor, Scott]

On 3/1/13 10:12 AM, "Morris, Andi" <amorris at cardiffmet.ac.uk> wrote:

>Initially both, but I've worked out now that my external facing
>certificate is separate, and as such have renewed this successfully. I
>have generated the internal SAML certificate, replaced the existing
>private key and public crt files with the new ones (exactly the same file
>names and locations) and restarted both apache and tomcat services.

You really can't just go changing a signing key, that has operational
implications and you'll break all kinds of things.

>I then remembered that I need to put the contents of the crt file inside
>my idp-metadata.xml file and replace this on any relevant SPs. After
>doing this I everything seems to be ok.

I guess you just dealt with the operational implications. As a rule,
people don't take kindly to having their apps broken, so this causes a lot
of grief.

You have to manage key changes with metadata and configuration strategies
that avoid breakage, and usually combine that with a ton of hand holding
of commercial partners that have to change keys on a fixed schedule.

>I am interested in the what has been said since I've been typing this
>though. Are you saying that the internal shibboleth certificate does not
>necessarily affect the service if it has expired? The person that setup
>Shibboleth at this site has since left, and he set this up with public
>certs, rather than the auto-generated self-signed certificates that last
>20 years (according to the docs).

There's no one answer to that question. Every deployment has specific
trust models and partners to deal with that influence whether or not an
expired signing cert will work, and what the implications of using
non-self-signed certs will be. Coming in after the fact, you have no real
way to get all that information except for a lot of legwork.

-- Scott