IDP 3.4.3 Expiring Signing Certtificate Rollover

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

IDP 3.4.3 Expiring Signing Certtificate Rollover

Rich Thomas
Need to rollover IDP signing cert. Was carry over from IDP V2.

1. Added new signing cert/key pair to idp.properties and defined expiring
certs associated with .2
idp.signing.key= %{idp.home}/credentials/idp-signing.key
idp.signing.cert= %{idp.home}/credentials/idp-signing.crt
idp.signing.key.2 = %{idp.home}/credentials/idp-signing-old.key
idp.signing.cert.2 = %{idp.home}/credentials/idp-signing-old.crt
idp.encryption.key= %{idp.home}/credentials/idp-encryption.key
idp.encryption.cert= %{idp.home}/credentials/idp-encryption.crt

2. Added Cert to IDP metadata

3. Defined additional cert and key in credentials.xml following example for
the encryption key rollover defined in the file

<alias alias="shibboleth.SigningCredentials"
name="shibboleth.DefaultSigningCredential" />
       
        <util:list id="shibboleth.DefaultSigningCredential">
       
        <bean
class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
            p:privateKeyResource="%{idp.signing.key}"
            p:certificateResource="%{idp.signing.cert}"
            p:entityId-ref="entityID" />
       
           
            <bean
class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
            p:privateKeyResource="%{idp.signing.key.2}"
            p:certificateResource="%{idp.signing.cert.2}"
            p:entityId-ref="entityID" />
               
        </util:list>

I have verified that old and new signing cert works but only one at a time
depending on which bean is not commented out or which bean is first within
util:list in credentials.xml

Not seeing any errors in logs. IDP authentication is working.

Haven't found other documentation.



--
Sent from: https://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP 3.4.3 Expiring Signing Certtificate Rollover

Cantor, Scott E.
> I have verified that old and new signing cert works but only one at a time
> depending on which bean is not commented out or which bean is first within
> util:list in credentials.xml

What exactly are you expecting to happen? Any given security and signing configuration is going to use exactly one key, and other than exceptional cases involving different key types, there's no concept of picking a key based on anything other than a local decision over which key to use.
 
> Haven't found other documentation.

Controlling credentials is documented in [1]

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IDP 3.4.3 Expiring Signing Certtificate Rollover

Rich Thomas
Have SPs pointing to expiring signing cert point to new cert when they receive updated IDP metadata.

From: users <[hidden email]> on behalf of Cantor, Scott <[hidden email]>
Sent: Tuesday, February 4, 2020 5:38:35 PM
To: Shib Users <[hidden email]>
Subject: RE: IDP 3.4.3 Expiring Signing Certtificate Rollover
 
WARNING: This email originated from outside of UTMB's email system. Do not click links or open attachments unless you recognize the sender and know the content is safe.


> I have verified that old and new signing cert works but only one at a time
> depending on which bean is not commented out or which bean is first within
> util:list in credentials.xml

What exactly are you expecting to happen? Any given security and signing configuration is going to use exactly one key, and other than exceptional cases involving different key types, there's no concept of picking a key based on anything other than a local decision over which key to use.

> Haven't found other documentation.

Controlling credentials is documented in [1]

-- Scott

[1] https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fdisplay%2FIDP30%2FSecurityConfiguration&amp;data=02%7C01%7Crcthomas%40utmb.edu%7Cc54b14a646ce4c6edb3b08d7a9cb6851%7C7bef256d85db4526a72d31aea2546852%7C0%7C0%7C637164563421032010&amp;sdata=uiDU663bU987Apw%2BR3844t6%2BalVutwtrYy4%2FShk7aJM%3D&amp;reserved=0
--
For Consortium Member technical support, see https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&amp;data=02%7C01%7Crcthomas%40utmb.edu%7Cc54b14a646ce4c6edb3b08d7a9cb6851%7C7bef256d85db4526a72d31aea2546852%7C0%7C0%7C637164563421032010&amp;sdata=JRBAug%2FkBw3XnYYx26YNr9XK5CPFsdO5C3AYeL3lPPU%3D&amp;reserved=0
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP 3.4.3 Expiring Signing Certtificate Rollover

Cantor, Scott E.
> Have SPs pointing to expiring signing cert point to new cert when they receive
> updated IDP metadata.

They do, and either key will be accepted, except by all of the SPs that don't support metadata to begin with.

The fact is that the majority of systems that would support metadata also won't care that your key has "expired". There is no such thing. If the key is in a valid metadata instance accepted by a compliant SP, it hasn't expired by definition. Most of the sysems that would improperly expire such a key have no idea metadata exists, or don't use it correctly.

There are three types of systems:

- metadata capable, including some that don't properly handle it and ignore multiple keys
- self-managed with keys manually updated by you
- manual, with no process or recourse other than contacting the owner and likely ending up with an insecure and socially-engineerable/exploitable mechanism to get them the new key

The first step to any key change is inventorying every SP and knowing which category they're in, followed by pinning all of the second and third set to a specific security configuration bean (doable in many different ways) with the old key. Then rolling the first category via metadata update and flipping the default key to the new one once its propagated, and removing the old key from metadata. And then changing all the other systems, one by one by hand and through vendors, flipping the security configuration for each one as they're updated.

That's the process. The work depends on the size of those second and third categories.

The goal of the process should be to prove to management that it can never be done again without a very good reason, and making sure it doesn't need to happen for any bad reasons, such as large numbers of staff with access to the key, raising risks every time any of those staff turn over.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]