Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revisionLast revisionBoth sides next revision | ||
en:certificates [2019/07/25 08:42] – Wolfgang Pempe | en:certificates [2023/02/01 17:02] – Wolfgang Pempe | ||
---|---|---|---|
Line 7: | Line 7: | ||
**The general rule is:** Entities with invalid (i.e. expired or revoked) certificates are automatically removed from the productive DFN-AAI federation! | **The general rule is:** Entities with invalid (i.e. expired or revoked) certificates are automatically removed from the productive DFN-AAI federation! | ||
==== Information for Identity Providers / Attribute Authorities ==== | ==== Information for Identity Providers / Attribute Authorities ==== | ||
- | Cf. [[de:shibidp3prepare-zert# | + | Cf. [[de:shibidp: |
==== Information for Service Providers ==== | ==== Information for Service Providers ==== | ||
All certificates and the respective private keys used for SAML-based communication have to be added to your SP's configuration, | All certificates and the respective private keys used for SAML-based communication have to be added to your SP's configuration, | ||
+ | |||
+ | \\ | ||
=== DFN-PKI Certificates === | === DFN-PKI Certificates === | ||
- | For general information, please refer to https:// | + | For SAML-based communication, 3-year valid certificates from the [[https:// |
- | If you are entitled to request certificates issued by DFN-PKI, please select the " | + | |
+ | \\ | ||
=== Common Trusted CA Certificates === | === Common Trusted CA Certificates === | ||
- | You can use certificates issued by common Certification Authorities (CAs) that are preinstalled in the most common web browsers (Google Chrome, Firefox, Microsoft Edge). They must not exceed a validity of 39 months. If you get an " | + | You can use certificates issued by common Certification Authorities (CAs) that are preinstalled in the most common web browsers (Google Chrome, Firefox, Microsoft Edge). If you get an " |
+ | |||
+ | \\ | ||
+ | |||
+ | === Be careful with wildcard certificates! === | ||
+ | |||
+ | Since wildcard certificates are valid for an entire subdomain and can therefore be used for several entities at the same time, the potential damage in the event of a compromise of the private key is significantly higher than with certificates for precisely specified FQDNs. Therefore, wildcard certificates should only be used in the DFN-AAI if the usage scenario technically requires it. For example, there are software systems, especially in the library context, which dynamically generate host names and which do not work with conventional certificates. Examples of such software: EZProxy, Netman/ | ||
+ | \\ | ||
+ | One and the same wildcard certificate should not be used on different servers with different services, purposes or protection classes. Due to the higher potential for damage in the event of compromise, wildcard certificates are not a proven means of saving work when applying for and deploying certificates. | ||
+ | Wildcard certificates are therefore only accepted in the DFN-AAI below sub-domains or second-level domains that are used exclusively for a clearly defined purpose. | ||
+ | |||
+ | |||
+ | |||
+ | \\ | ||
+ | |||
+ | === Own/Local CA === | ||
+ | For certificates from a local CA the same rules apply as for self-signed certificates, | ||
+ | |||
+ | \\ | ||
=== Self-signed Certificates === | === Self-signed Certificates === | ||
- | Self-signed certificates may be used as well if they are not valid for longer than 39 months. For production, the CN (or the subject alternative names) of the certificate must at least contain the domain name of the SP. Ideally it should contain the complete host name. As for the technical details, please refer to the online documentation of [[https:// | + | Self-signed certificates may be used if they are not valid for longer than 39 months. For production, the CN (or the subject alternative names) of the certificate must at least contain the domain name of the SP. Ideally it should contain the complete host name. As for the technical details, please refer to the online documentation of [[https:// |
- | * Please | + | |
- | * If you do not have the possibility to send us a download link, we can compare the certificate' | + | |
- | < | + | |
- | $ openssl x509 -noout -fingerprint -sha1 -in self-signed-server-cert.pem | + | |
- | $ openssl | + | |
- | </ | + | |
- | * As a third option, you can send us the certificate in an S/ | + | |
- | < | + | \\ |
+ | |||
+ | < | ||
**As for Service Providers that are already registered with another federation, the same certificate (i.e. the one registered with the other federation) may be used even if the aforementioned requirements are not met.** In this case, please drop a note to the DFN-AAI [[hotline@aai.dfn.de|helpdesk]]. | **As for Service Providers that are already registered with another federation, the same certificate (i.e. the one registered with the other federation) may be used even if the aforementioned requirements are not met.** In this case, please drop a note to the DFN-AAI [[hotline@aai.dfn.de|helpdesk]]. | ||
</ | </ | ||
Line 39: | Line 55: | ||
== Letsencrypt == | == Letsencrypt == | ||
We strongly advise against the use of Letsencrypt certificates for SAML-based communication as they expire after 90 days. Every time, you would have to do a manual certificate rollover in the metadata administration tool. The SP configuration has to be adapted twice for a rollover, too. That is why we recommend self-signed certificates with a validity of 3 years. (If you are securing your webserver with Letsencrypt certificates, | We strongly advise against the use of Letsencrypt certificates for SAML-based communication as they expire after 90 days. Every time, you would have to do a manual certificate rollover in the metadata administration tool. The SP configuration has to be adapted twice for a rollover, too. That is why we recommend self-signed certificates with a validity of 3 years. (If you are securing your webserver with Letsencrypt certificates, | ||
- | |||
- | === Certificate rollover === | ||
- | Whenever you switch to a new certificate, | ||
**Next step:** [[en: | **Next step:** [[en: | ||
- | ==== Certificate / Key Rollover ==== | + | ==== Certificate / Key Rollover |
- | For an example of a key rollover procedure please refer to the [[https://wiki.shibboleth.net/confluence/display/SP3/Multiple+Credentials# | + | |
- | The documentation provided by SWITCH is a bit more detailed: https:// | + | Whenever you switch |
+ | * [[https://www.switch.ch/aai/guides/idp/certificate-rollover/|Shibboleth | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | Note: When their documentation tells you to wait two hours, you should wait a whole day as the distribution of metadata to all DFN-AAI participants can take that long. If you have a DFN-PKI certificate, | ||
===== The SSL certificate chain on your webserver ===== | ===== The SSL certificate chain on your webserver ===== | ||
Line 78: | Line 95: | ||
If there is another intermediate certificate, | If there is another intermediate certificate, | ||
- | If you use the Apache webserver, point the SSLCACertificateFile directive to your chain file. (See the example configuration on [[de:shibidp3prepare-http# | + | If you use the Apache webserver, point the SSLCACertificateFile directive to your chain file. (See the example configuration on [[de:shibidp: |
Once you have added you certificate chain, adapted your configuration and activated it you can verify it with OpenSSL: | Once you have added you certificate chain, adapted your configuration and activated it you can verify it with OpenSSL: |