Process to Manage Embedded Certificates for Federation Metadata

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

Roles

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 with the SWITCHaai Certificate Acceptance Policy.
    If not compliant, the certificate gets rejected.
  3. 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 Home Organisation requires the 'four-eyes principle' and the Resource Administrator is at the same time also RRA, he does not receive that notification.
      If there is no further RRA available, a SWITCH DB Admin, authenticated via AAI with two-step login, can intervene to verify the SHA-1 fingerprint and approve the self-signed certificate.
    2. RRA authenticates via AAI and provides the first eight hex digits of the fingerprint. The Applicant provides them via an alternate channel (e.g. phone, secured chat).
  4. RRA approves resource registration
  5. Resource Administrator can delegate this role to further users with an AAI account.

Recommendations for Home Organisations

A Home Organisation should ask the SWITCHaai team to
  • enforce two-step login for RRA approval actions (available if the Home Organisation adopted edu-ID);
  • enforce the four-eyes principle for RRA approval actions (available for all Home Organisations).

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 notifies the technical contacts of an entity before an embedded certificate expires.

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

According to the SWITCHaai Certificate Acceptance Policy an expired certificate does not get removed from metadata.

Private Key Compromise

Warning: Removing the certificate of a compromised private key from metadata without rollover will break login at the service for the entity for which the certificate is removed. So, it is only suitable for emergency purposes in case of a 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.