Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| en:certificates [2023/01/06 14:30] – Wolfgang Pempe | en:certificates [2023/02/01 17:42] (current) – Wolfgang Pempe | ||
|---|---|---|---|
| Line 11: | Line 11: | ||
| ==== 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 SAML-based communication, | For SAML-based communication, | ||
| + | |||
| + | \\ | ||
| === 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). 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/HAN. | ||
| + | \\ | ||
| + | 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, e.g. for ''" | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | \\ | ||
| === Own/Local CA === | === Own/Local CA === | ||
| - | For certificates from a local CA the same rues apply as for self-signed certificates, | + | 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 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:// | ||
| + | |||
| + | \\ | ||
| <callout color="# | <callout color="# | ||