SWITCHaai Certificate Acceptance Policy

Whenever a SAML entity communicates with another entity, it first verifies the partners' identity by means of an X.509 server certificate. Such a certificate gets verified against the entities' embedded certificate in the SAML metadata file.


For more details on certificates involved and their validation see the certificates overview page.

SWITCHaai Certificate Acceptance Policy


  • The use of long-lived, self-signed certificates in Federation metadata is strongly RECOMMENDED.
    • Certificates with lifetimes of at least 10 years are RECOMMENDED to avoid unnecessary technically-imposed deadlines on key rollover.
    • RSA keys with a minimum size of 2048 bits MUST be used for all new certificates introduced into Federation metadata.
    • The RECOMMENDED key size is 3072 bits.
    • New certificates with key sizes less than 2048 bits are not allowed in Federation metadata.
  • Expired certificates SHOULD NOT be introduced into Federation metadata. An expired certificate in metadata SHOULD be removed once a certificate migration process to a new certificate has been completed.
    • A certificate's expiration date has nothing to do with the security of the corresponding private key, which is an ongoing concern.
  • If a private key is lost or stolen, immediate steps MUST be taken to configure a new private key and to introduce the corresponding public key certificate into metadata.
    Since there are no other known attacks on RSA 2048-bit keys, generating a new private key for any other purpose is NOT RECOMMENDED.
  • Service providers MUST include an encryption key in SP metadata.
    • The encryption key is used by IdPs to encrypt SAML V2.0 assertions transmitted to the SP.
  • SWITCH as Federation Operator does not validate Subject information in self-signed certificates because this information is irrelevant from a security perspective. However, at its discretion, SWITCH will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresented Subject information as decided by SWITCH on a case-by-case basis.
    Generally, Subject information should express a somewhat reasonable relationship between the certificate and the organization.


  • From a certificate embedded in SAML metadata only its public key matters. A conforming SAML implementation will ignore all other certificate content. Therefore, the certificate serves as a container for the public key.
    The guide How to create an Embedded Certificate with OpenSSL may be useful if your SAML implementation is not able to create a conforming self-signed certificate.
  • Certificates signed by a Certification Authority (CA) are allowed, and in most situations will work just fine, but the use of certificates other than self-signed certificates is discouraged.

History & Acknowledgement

In Q1 2021, SWITCH revised the Certificate Acceptance Policy for the SWITCHaai Federation. It is now less strict than beforehand but it upholds the high security standard.
The revised policy is mostly based on the one from the InCommon Federation in the US, with some updates based on operational experience in other major federations. Many thanks to all contributors!