Changes between Version 2 and Version 3 of IdpKeyRollOver


Ignore:
Timestamp:
07/08/11 10:37:48 (13 years ago)
Author:
jpmitchell@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IdpKeyRollOver

    v2 v3  
    33This page documents the process of rolling over the IdP's keys. This includes the process of generating a new certificate for the IdP. The certificate and key are only used for signing the assertions and securing the attribute query back channel that is not user facing. 
    44 
    5 The process from the 10k foot level is to add a second set of key and cert to the IdP and its metadata for distribution ahead of the actual roll over. Once all of the SPs have the new metadata then the IdP can be rolled over to using the new key and cert and the SPs will transparently follow since they have both the new cert and old cert in metadata. 
     5The process from the 10k foot level is to add a second key and cert to the IdP and its metadata for distribution ahead of the actual roll over. Once all of the SPs have the new metadata then the IdP can be rolled over to using the new key and cert and the SPs will transparently follow since they have both the new cert and old cert in metadata. 
    66 
    77**Note**: All operations in this procedure occur under the tomcat user. 
     
    5151}}} 
    5252 
    53 4. Add the new key/certificate to the IdP metadata. There should be two "<!KeyDescriptor>" stanzas after this step in the metadata for the "<IDPSSODescriptor>" stanza and the "<!AttributeAuthorityDescriptor>" stanza. 
     534. Add the new certificate to the IdP metadata. There should be two "<!KeyDescriptor>" stanzas after this step in the metadata for the "<IDPSSODescriptor>" stanza and the "<!AttributeAuthorityDescriptor>" stanza. 
    5454{{{ 
    5555-bash-3.2$ cat idp.new.crt  
     
    1721726. Test config changes according to [[https://iam.alaska.edu/shib/wiki/TestIdPConfig|Test IdP Config Change]] procedure. 
    173173 
    174 7. Wait for SPs to get metadata. SPs in the !InCommon federation should be polling the !InCommon metadata [[http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml|distribution]] point daily. 
    175  
    176 8. Move to the new key/certificate and delete the old key/certificate "security:Credential" stanza in the relying party configuration. After this step there should be //only// one "security:Credential" stanza that points to the key/cert. 
     1747. Notify non-federation SPs of metadata change and instruct them to update. SPs in the !InCommon federation should be polling the !InCommon metadata [[http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml|distribution]] point daily. Wait for SPs to get metadata. 
     175 
     1768. Move to the new key/certificate and delete the old key/certificate "security:Credential" stanza in the relying party configuration. After this step there should be //only// one "security:Credential" stanza that points to the key/cert. **Note**: The id //must// be "IdPCredential".  
    177177{{{ 
    178178-bash-3.2$ svn co svn+ssh://sxjpm@iron.alaska.edu/usr/local/iam/shib-svn/idp/trunk/conf 
     
    188188}}} 
    189189 
    190 9. Move to the new key/certificate in the IdP metadata. There should be one "<!KeyDescriptor>" stanzas after this step in the metadata for the new cert in the "<IDPSSODescriptor>" stanza and the "<!AttributeAuthorityDescriptor>" stanza. 
     1909. Move to the new key/certificate in the IdP metadata. There should be one "<!KeyDescriptor>" stanza after this step in the metadata for the new cert in the "<IDPSSODescriptor>" stanza and the "<!AttributeAuthorityDescriptor>" stanza. 
    191191{{{ 
    192192-bash-3.2$ svn co svn+ssh://sxjpm@iron.alaska.edu/usr/local/iam/shib-svn/idp/trunk/metadata 
     
    196196-bash-3.2$ svn ci metadata/idp-metadata.xml -m "Moved to new IdP cert and deleted old cert." 
    197197 
    198 10. Create a new Java Key Store for Tomcat containing the new key/cert for securing the back channel. 
    199 {{{ 
    200  
    201 }}} 
     19810. Create a new Java Key Store for Tomcat containing the new key/cert for securing the back channel. You will need the ImportKey Java utility for importing a pre-existing cert/key into a Java Key Store. You can get it from: [[ImportKeyUtil|Import Key Utility]]. 
     199{{{ 
     200-bash-3.2$ openssl pkcs8 -topk8 -nocrypt -in idp.new.key -out idp.new.key.der -outform der 
     201-bash-3.2$ openssl x509 -in idp.new.crt -out idp.new.crt.der -outform der 
     202-bash-3.2$ java ImportKey idp.new.key.der idp.new.crt.der  
     203Using keystore-file : /opt/tomcat/temp/keystore.ImportKey 
     204One certificate, no chain. 
     205Key and certificate stored. 
     206Alias:importkey  Password:importkey 
     207-bash-3.2$ keytool -storepasswd -new changeit -keystore keystore.ImportKey -storepass importkey 
     208-bash-3.2$ keytool -keypasswd -alias importkey -new changeit -keystore keystore.ImportKey -keypass importkey -storepass changeit 
     209-bash-3.2$ keytool -changealias -alias importkey -destalias tomcat -storepass changeit -keystore keystore.ImportKey 
     210-bash-3.2$ mv keystore.ImportKey idp.new.jks 
     211-bash-3.2$ cp idp.new.jks /opt/shibboleth-idp/credentials/ 
     212}}}