FEDURUS Certificate Acceptance Policy
Whenever a Shibboleth 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 SAML2 metadata.
More details on involved certificates and validation on the certificate overview page
Embedded Certificates in SAML2 Metadata
- Use a self-signed certificate for embedding into metadata [1].
- Use a certificate with a three-year validity, the maximum duration.
- Web browser access to the web server shall be protected by https.
For that purpose, use a 'pop-up-free' certificate from a well-known CA.
Following these recommendations may be a bit more cumbersome than just using a single certificate from a well-known CA, but it pays off with better overall security!
Embedded certificates have to fulfil the criteria listed below in order to be acceptable for inclusion into the FEDURUS Federation Metadata.
In exceptional cases, FEDURUS may accept non-conforming certificates for inclusion in the FEDURUS Federation Metadata,
provided that they improve compatibility and interoperability with metadata of other major federations.
Validity Duration for Embedded Certificates
When a certificate reaches the end of its validity, it has to be replaced by a new certificate. This process is known as 'rollover'. It is a multi step process and has to be completed carefully. Longer validity reduces the rollover efforts required. However, a validity of more than three years is not acceptable for security reasons.
Which certificates are accepted for embedding?
Self-signed certificate
A self-signed certificate has to fulfil the minimal requirements defined in [2] to be accepted as embedded certificate. Before it is added to the metadata, the fingerprint of the private key will be verified via an independent channel (e.g. phone, fax).
- Pros
-
- It is free! You generate it yourself.
- It is independent of any Root or intermediary CA. You use a 2048 bit key and are sure that no weaker element like an intermediary or Root CA with a shorter key could ease a compromise.
- Cons
-
- It is not 'pop-up-free' when used for https access to your web server. For that you have to get one from a well-known CA (see below).
- To embed your self-signed certificate into metadata, the Resource Registry requires an off-line (phone, fax) fingerprint check. That could slightly delay the embedding.
Certificates issued under a well-known CA
The certificate needs to be 'Organization Validated' (OV) and issued by a CA that is either a member of the Microsoft Root Certificate Program or has been accepted by the Mozilla Foundation for inclusion in their browser family.
'Organization Validated' means that the legal existence of the organization has been verified at the time the certificate was issued, and that its name is included in the subject name of the certificate (O= attribute).
In addition, it has to meet minimal requirements defined in [1].
- Pros
-
- It is 'pop-up-free' when used for https access to your web server.
You can reuse the certificate for SAML communication. - You can easily add it to the Resource Registry, no special off-line fingerprint check required.
- It is 'pop-up-free' when used for https access to your web server.
- Cons
-
- It costs some money.