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/02/01 17:02] – Wolfgang Pempe | en:certificates [2024/08/27 08:23] (current) – [Information for Service Providers] Wolfgang Pempe | ||
|---|---|---|---|
| Line 15: | Line 15: | ||
| === DFN-PKI Certificates === | === DFN-PKI Certificates === | ||
| - | For SAML-based communication, | + | For SAML-based communication, |
| \\ | \\ | ||
| Line 28: | Line 28: | ||
| 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. | 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. | + | 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. | + | |
| + | 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 ''" | ||
| Line 41: | Line 43: | ||
| === 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:// |
| \\ | \\ | ||