Process to Manage Embedded Certificates for the Federation Metadata

The process described herein, is implemented in the program logic of the Resource Registry to ensure compatibility with the requirements defined.


Resource administrator
Registers and manages one or more Resource Descriptions.
RRA administrator (Resource Registration Authority administrator)
At least one person per Home Organization. Approves or rejects new or modified Resource Descriptions.

For more details, consult to the Resource Registry Guide

Certificate Addition

  1. A Resource administrator registers a resource on the Resource Registry website
    The Resource administrator authenticates with AAI and submits a certificate to embed as part of the resource description.
  2. Resource Registry checks certificate for compliance.
    If not fully compliant, the certificate gets rejected.
    1. Only if not self-signed certificate:
      1. Is the certificate 'Organisation Validated'?
      2. Is the certificate issued under a well-known Root CA?
        Root CA has to be either a member of the Microsoft Root Certificate Program or has been accepted by the Mozilla Foundation for inclusion in their browser family.
        The Resource Registry keeps track of these two sources and compares each certificate provided against these lists of CAs.
    2. The FQDN of the entityID MUST either match with a CN or a subjectAltName of the certificate.
    3. Is the fingerprint of the key unique?
      It MUST be unique, key reuse is not allowed.
      Use same method as for keyIdentifier extension (a SHA1 hash of the key). All the hash values get stored in the RR database to prevent key reuse.
  3. Only for a self-signed certificate:

    Out of band verification of the possession of the private key, by means of a fingerprint:

    1. RRAs receive notification that they should verify a self-signed certificate. If the Resource Administrator is at the same time also RRA, he does not receive that notification - 'Four eyes principle'.
      If there is no further RRA available, a SWITCH DB Admin, authenticated via AAI with a user certificate, can step in to verify the fingerprint and approve the self-signed certificate.
    2. RRA authenticates via AAI and has to provide the first eight hex digits of the fingerprint. The Applicant provides them via a 'secure' channel (e.g. phone, fax).
  4. RRA approves resource registration
    [ - Strong authentication for the RRA on the Resource Registry SHOULD be implemented ]
  5. Resource Administrator can delegate this role to further users with an AAI account.

Certificate Rollover at a Service Provider

Check out the Shibboleth Service Provider Certificate Rollover Guide for the detailed steps of this process.

Certificate Rollover at an Identity Provider

Check out the Shibboleth Identity Provider Certificate Rollover Guide for the detailed steps of this process.

Certificate Expiry

Resource Registry warns the tech contacts involved when an embedded certificate will soon expire.

For all validities of the certificates: An e-mail is sent 30 and 7 days in advance as well as on the day of certificate expiration.

If the certificate gets not replaced by rollover, the Resource gets removed from metadata by setting the 'valid until' date in the Resource Registry.

Certificate Compromise

Warning: Removing a compromised certificate from metadata without rollover will break the service of the entity for which the certificate gets removed. So it is only suitable for emergency purposes in case of likely private key compromise.

  1. Remove certificate from Resource Registry
  2. Optionally alert the administrators of IdPs or SPs based on 'intended audience' settings in order to have them update the metadata immediately.

No Process Defined Yet

  • What to do if a well-known CA disappears, but one or more of its certificates are still embedded?