Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
en:certificates [2017/12/04 15:32] – Silke Meyer | en:certificates [2019/07/25 08:42] – Wolfgang Pempe | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Certificates for SAML-based communication | + | ~~NOTOC~~ |
+ | ====== Certificates ====== | ||
+ | {{INLINETOC 2}} | ||
+ | ===== Certificates for SAML-based communication ===== | ||
In the context of SAML-based communication between IdP and SP, certificates are used for purposes of signature validation and encryption. Those certificates must be registered for the respective entity using the [[en: | In the context of SAML-based communication between IdP and SP, certificates are used for purposes of signature validation and encryption. Those certificates must be registered for the respective entity using the [[en: | ||
- | **The general rule is:** Entities with invalid (that is 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: | Cf. [[de: | ||
- | ===== Information for Service Providers | + | ==== Information for Service Providers ==== |
- | All certificates and the respective private keys used for SAML-based communication have to be add 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, | ||
If you are entitled to request certificates issued by DFN-PKI, please select the " | 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, | + | You can use certificates issued by common Certification Authorities (CAs) that are preinstalled in the most common web browsers (Google Chrome, Firefox, |
- | **If an SP is already registered with another federation, the same certificate (i.e. the one registered with the other federation) may be used even if the two aforementioned requirements are not met.** In this case, please drop a note to the DFN-AAI [[mailto:hotline@aai.dfn.de|helpdesk]]. | + | |
- | Service Providers that are already registered in other federations (with different policies) may use the same certificates for DFN-AAI even if they are valid for a longer period of time. | + | === 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 | |
- | ==== Self-signed Certificates | + | |
- | Self-signed certificates may be used as well if they are not valid for longer than 39 months. As for the technical | + | |
* Please offer us a possibility to download the certificate via https (e.g. via your SPs metadata handler or a download link to the file on your webserver). The SSL connection to the webserver has to be secured by a trusted CA certificate. | * Please offer us a possibility to download the certificate via https (e.g. via your SPs metadata handler or a download link to the file on your webserver). The SSL connection to the webserver has to be secured by a trusted CA certificate. | ||
* If you do not have the possibility to send us a download link, we can compare the certificate' | * If you do not have the possibility to send us a download link, we can compare the certificate' | ||
Line 26: | Line 27: | ||
$ openssl x509 -noout -fingerprint -sha256 -in self-signed-server-cert.pem | $ openssl x509 -noout -fingerprint -sha256 -in self-signed-server-cert.pem | ||
</ | </ | ||
- | * As a third option, you can send us the certificate in an S/ | + | * As a third option, you can send us the certificate in an S/ |
- | * 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. | + | |
- | ==== Please avoid the following certificates | + | <callout type=" |
- | === Wildcard certificates | + | **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]]. |
+ | </ | ||
+ | |||
+ | === Please avoid the following certificates === | ||
+ | == Wildcard certificates == | ||
The use of wildcard certificates is only permitted in duly justified cases. | The use of wildcard certificates is only permitted in duly justified cases. | ||
- | === 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 year. | + | 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 | + | ==== Certificate |
- | Whenever you switch | + | For an example of a key rollover procedure please refer to the [[https://wiki.shibboleth.net/confluence/display/SP3/Multiple+Credentials# |
+ | The documentation | ||
- | ====== The SSL certificate chain on your webserver | + | ===== The SSL certificate chain on your webserver ===== |
Your webserver' | Your webserver' | ||
Line 47: | Line 55: | ||
* You need a file containing the private key. On a linux machine, it should be something like / | * You need a file containing the private key. On a linux machine, it should be something like / | ||
* Create a third file containing the complete chain, e.g. / | * Create a third file containing the complete chain, e.g. / | ||
- | * the server certificate | + | |
- | | + | * one or more matching intermediate certificates |
- | | + | * the CA's root certificate |
These certificates are appended to the file in this order. You may add comments in between (beginning with a "#" | These certificates are appended to the file in this order. You may add comments in between (beginning with a "#" | ||
Line 58: | Line 66: | ||
6ded7378 | 6ded7378 | ||
</ | </ | ||
- | * Check the hash of the first intermediate certificate. | + | * Check the hash of the first intermediate certificate. |
< | < | ||
$ openssl x509 -in intermediate1.pem -noout -hash | $ openssl x509 -in intermediate1.pem -noout -hash | ||
Line 70: | Line 78: | ||
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: | + | If you use the Apache webserver, point the SSLCACertificateFile directive to your chain file. (See the example configuration on [[de: |
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: | ||
Line 76: | Line 84: | ||
$ openssl s_client -connect idp.domain.tld: | $ openssl s_client -connect idp.domain.tld: | ||
</ | </ | ||
- | Below you can the answer of dfn.de' | + | Below you can see the answer of dfn.de' |
**Next step:** [[en: | **Next step:** [[en: |