...
From week to week we add new Metadata files and configure the release of attributes to new applications. Occasionally we defined new Attributes or get the same Attribute from a new database. That is the routine maintenance and it is documented in a different page. It is probably a good idea to read the Shibboleth Configuration page first before reading this page because it is more important, and because I assume you understand a little about Spring Bean configuration already.
...
The Certificate, however, is just a convenient format to distribute a public key. It is self-signed and is never issued by a real CA. The only information it contains is the Public Key. If there was some other widely supported file format for distributing public keys, we might never use Certificates for the purpose. It goes without saying that this has nothing to do with the SSL certificate of the server, and it is not and cannot in general be validated with a Trust chain.
As a result, it does not matter what Crypto digest algorithm is specified in the Certificate. The only thing that matters is the 2048 bit RSA key. No matter what the certificate says, Shibboleth will choose SHA1 or SHA256 for its digital signature based on the other Shibboleth security configuration files. There is a default digest algorithm and then there can be exceptions based on the Metadata or explict configuration based on EntityID. Therefore, this key and certificate only need to be replaced if 2048 bit RSA becomes vulnerable.
I believe that Shibboleth 2 defaulted to SHA1, and I know that Shibboleth 3 defaults to SHA256. The exact syntax for configuring exceptions is not clearly documented in the Wiki, so we hope either that it is not needed or that partners that do need it give us correctly configured MetadataWe are in the middle of a shift from old SSL Certificates that used SHA1 digest information to SHA256, because the old SHA1 algorithm is no longer regarded as secure. Shibboleth has an entirely different problem. In SSL Certificates, the digest is used to validate the content of the Certificate itself and verify that it was issued by the CA it claims to come from. SAML certificates are all self-signed, so there is no CA validation. Instead, SAML uses the XML Digital Signature standard to validate that the SAML message was sent by the IdP it claims to have come from. Here a digest is calculated on the XML and not the Certificate. It is still true that SHA1 is now regarded as insecure.
Shibboleth 2 defaulted to using SHA1 and Shibboleth 3 defaults to using SHA256. Unlike SSL, there is no negotiation. Shibboleth will use whichever digest mechanism is configured for the Relying Party to which the message is being sent. Normally it uses the default. If a particular Relying Party cannot support SHA256, then the Metadata of that RP can be changed to force SHA1. It is not clear if this is a real requirement for any RP. SAML has only been widely used for five years now, and SHA256 was universally supported at that time.
Each Yale environment (DEV, TEST, and PROD) has its own private key (and public key certificate, and Metadata file, and EntityID). InCommon and most partners only configure the PROD information and therefore only trust SAML generated by PROD. When the Shibboleth VMs change, then the idp.key and idp.crt files have to be copied from the old DEV to the new DEV, from the old TEST to the new TEST, and from the old PROD to the new PROD.
...