You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

The term key rollover refers to a process whereby one key is systematically replaced by another key in SAML metadata. Since SAML entities (and therefore SAML metadata) are distributed, key rollover must be deliberate, so as not to break the key operations of a relying party. 

The general process of rolling over a metadata key in an IdP without causing unnecessary downtime is as follows. The following describes the process in detail for Shibboleth IdPs. The information can be used as inspiration for other IdP implementations.

  1. Create a new key pair for signing metadata
  2. Add the new KeyDescriptor to your metadata
  3. Send the new metadata to Operations and wait for the newly updated metadata to propagate throughout the Federation
  4. Reconfigure the IdP software to use the new key (instead of the old key) as the signing key
  5. Remove the old KeyDescriptor from your metadata and send the new metadata to Operations

If you need to replace the front end SSL/TLS key, you do not need to send anything to Operations. If you have a Apache front-end then you need to create the key, CSR and import the signed certificate into Apache's configuration. If you use Tomcat or another Java container, use keytool and update the server.xml. Restart Apache/Tomcat.


Shibboleth IdP metadata key roller suitable for both Apache HTTP or Apache Tomcat as front end.

The following is designed to work on in a Linux environment. Read carefully before proceeding so that you understand the process. Several restarts of tomcat and/or apache are required. Backup your entire Shibboleth installation (and snapshot your server if possible) before proceeding.

The following instructions are pretty much untested at present. Your mileage may vary...

Specify your IdP server name and path to shibboleth-idp in two shell variables (e.g. idp2.kau.se and /usr/local/shibboleth-idp)

FQDN=<enter your IdP FQDN>
IDP_HOME=<enter the path to your shibboleth-idp directory> 

Use the temp directory to generate new key and certificate

cd /tmp

Copy the current key file to the temp directory in order to preserve the file permissions

cp -p ${IDP_HOME}/shibboleth-idp/credentials/idp.key idp.new.key

Create configuration file

cat > idp-cert.cnf <<EOF
sudo OpenSSL configuration file for creating idp-cert.pem
[req]
prompt=no
default_bits=2048
encrypt_key=yes
default_md=sha1
distinguished_name=dn
sudo PrintableStrings only
string_mask=MASK:0002
x509_extensions=ext
[dn]
CN=${FQDN}
[ext]
subjectAltName=DNS:${FQDN},URI:https://${FQDN}/idp/shibboleth
subjectKeyIdentifier=hash
EOF

Generate a new pair of certificate and key files (in the current directory). This generates a key/certificate pair that are valid for three (3) years.

openssl req -config idp-cert.cnf -new -x509 -days 1095 -keyout idp.new.key -out idp.new.crt 2> /dev/null

If you use Tomcat alone, you need to create a java keystore, otherwise ignore the .jks files and the next two commands. Export to a pkcs12 file (temporarily)

openssl pkcs12 -export -in idp.new.crt -inkey idp.new.key -out idp.new.pkcs12 -name tomcat

Import pkcs12 file into a java keystore

keytool -importkeystore -destkeystore idp.new.jks -srckeystore idp.new.pkcs12 -srcstoretype PKCS12 -alias tomcat

Cleanup files that are no longer required

rm idp-cert.cnf
rm idp.new.pkcs12

Output the new IdP certificate ready for copy/paste

cat ${IDP_HOME}/shibboleth-idp/credentials/idp.new.crt

Move new files to the live certificate directory in your Shibboleth installation. Check permissions and ownership after moving.

sudo mv idp.new.key ${IDP_HOME}/shibboleth-idp/credentials/idp.new.key
sudo mv idp.new.crt ${IDP_HOME}/shibboleth-idp/credentials/idp.new.crt
sudo mv idp.new.jks ${IDP_HOME}/shibboleth-idp/credentials/idp.new.jks

Backup your metadata file

sudo cp ${IDP_HOME}/shibboleth-idp/metadata/idp-metadata.xml ${IDP_HOME}/shibboleth-idp/metadata/idp-metadata.xml.bak.0

Paste the new certificate in, omitting the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. Do this two times, once in the IDPSSODescriptor and once in the AttributeAuthorityDescriptor element.

<KeyDescriptor>
  <ds:KeyInfo>
    <ds:X509Data>
      <ds:X509Certificate>
      </ds:X509Certificate>
    </ds:X509Data>
  </ds:KeyInfo>
</KeyDescriptor>

Restart apache and/or tomcat, Send the metadata file to operations@swamid.se. Wait for operations to add the metadata into the appropriate stream. 

Once the stream has updated (allow 24 hours), switch the metadata used by the IdP. Backup the old files.

sudo mv ${IDP_HOME}/shibboleth-idp/credentials/idp.key ${IDP_HOME}/shibboleth-idp/credentials/idp.key.bak.0
sudo mv ${IDP_HOME}/shibboleth-idp/credentials/idp.crt ${IDP_HOME}/shibboleth-idp/credentials/idp.crt.bak.0
sudo mv ${IDP_HOME}/shibboleth-idp/credentials/idp.jks ${IDP_HOME}/shibboleth-idp/credentials/idp.jks.bak.0

Activate the new files

sudo mv ${IDP_HOME}/shibboleth-idp/credentials/idp.new.key ${IDP_HOME}/shibboleth-idp/credentials/idp.key
sudo mv ${IDP_HOME}/shibboleth-idp/credentials/idp.new.crt ${IDP_HOME}/shibboleth-idp/credentials/idp.crt
sudo mv ${IDP_HOME}/shibboleth-idp/credentials/idp.new.jks ${IDP_HOME}/shibboleth-idp/credentials/idp.jks

If you use tomcat alone, make sure it can access the idp.jks file. If you have an Apache front, check the VirtualHost configuration for port 8443 can access the key and crt files. Restart apache and/or tomcat and test. If everything works, you can remove the old certificate from the IdP's metadata and re-submit the metadata to operations@swamid.se so that the old certificate is removed from the stream.


  • No labels