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.
Although you may use any certificate as part of the trust fabric, 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.
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 about the compromised key, and about all affected trust fabric certificates and the entities they are associated with. In consultation with the owner of the entity or entities, the federation operator will make a determination as to appropriate steps necessary to secure the federation, which may include:
-
Rebuilding the federation metadata to temporarily exclude all affected entities,
-
An announcement to the federation mailing list.
-
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.
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.