5 Digital Certificates
5.1 Certificate Roles in the UK Federation
The protocols and profiles used within the UK federation make extensive use of X.509 certificates to carry the public keys used for various purposes. These certificates can be broken down into two classes according to their function.
5.1.1 Browser-facing Certificates
Browser-facing certificates are visible only to a user’s browser. The browser-facing certificates are:
The identity provider’s SSL server certificate seen by browsers (for example, on a user login page),
The service provider’s SSL server certificate seen by browsers (for example, on actual site pages being protected by Shibboleth and at assertion consumer service endpoints),
Any SSL server certificates seen by browsers during the discovery process (for example, on local discovery services or at institutional portals, see section 6 below).
Browser-facing certificates are not part of the federation’s trust fabric; this means that they do not appear in federation metadata and that the federation operator is not normally aware of the certificates that you use in this role.
You can use certificates from any source as browser-facing certificates; the main constraint is that the issuer of the certificate (often a commercial Certification Authority, or CA) is accepted as trusted by the user’s browser.
5.1.2 Trust Fabric Certificates
Trust fabric certificates are visible only to the identity provider and service provider software; they are never seen by the user’s browser. The trust fabric certificates are:
The certificate for the identity provider’s XML signing key pair for SAML services,
The certificate for the identity provider’s SSL server key pair for SAML services,
The certificate for the service provider’s SSL client key pair for SAML services,
The certificate for the service provider’s XML signing key pair for SAML requests.
Trust fabric certificates are, as the name implies, part of the federation’s trust fabric. This means that they appear in federation metadata and that you need to include information about your entity’s trust fabric certificates in your entity registration.
Most modern SAML software generates a long-lived, self-signed trust fabric certificate during the installation process. We recommend that you use this automatically generated trust fabric certificate for your entity unless you have a specific reason not to do so.
The federation also accepts metadata registrations making use of trust fabric certificates issued by commercial or private certification authorities. Current information about the options available for trust fabric certificates is available from the UK federation web site.1
5.2 Recovery from Key Compromise
If any of the private keys associated with a federation entity leave the control of the owners of that entity, they should be regarded as permanently compromised. Should this happen, the following steps must be taken immediately:
Any Certification Authorities that have acted as issuers for certificates associated with the compromised key should be notified. This will allow the CAs to revoke all affected certificates.
The federation must be notified of the compromised key, and of all affected certificates. The federation will make an immediate announcement to the federation mailing list, and rebuild the federation metadata to temporarily exclude all affected entities.
Recovering from any system compromise is a complex process, often involving rebuilding the affected systems. After the system has been re-secured, it is then necessary for the compromised entity to at least generate a new key pair and have new certificates signed by the appropriate CA.
Because of the way certificates are handled in the Shibboleth software, recovery may also involve changing the DNS name of the affected entity before generating new certificates. Determination of the exact steps required will be made on a case-by-case basis by the federation operator for each compromise as it occurs.