Differences

This shows you the differences between two versions of the page.

--- en:certificates [2023/01/06 14:31] – Wolfgang Pempe
+++ en:certificates [2024/08/27 08:23] (current) – [Information for Service Providers] Wolfgang Pempe
@@ Line 15: / Line 15: @@
 === DFN-PKI Certificates ===
-For SAML-based communication, 3-year valid certificates from the [[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community PKI]] are recommended. If you are entitled to request certificates issued by DFN-PKI, please select the "Shibboleth IdP SP" profile when submitting your CSR. Upload the server certificate in the metadata administration tool.
+For SAML-based communication, 3-year valid certificates from the [[de:dfnpki:dfnvereincommunitypki|DFN-Verein Community PKI]] are recommended. If you are entitled to request certificates issued by DFN-PKI, please select the "Shibboleth IdP SP" profile when submitting your CSR. Upload the server certificate in the metadata administration tool.
 \\
@@ Line 21: / Line 21: @@
 === 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 "Issuer not found" warning for such a certificate please contact our [[hotline@aai.dfn.de|helpdesk]].
+\\
+=== 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 ''"*.ub.uni-example.de"'' or for ''"*.medizin.uni-example.de"'', but not for ''"*.uni-example.de"''.
 \\
@@ Line 30: / Line 43: @@
 === 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://www.switch.ch/aai/guides/sp/configuration/#4|SWITCHaai]]. Please note that the period of validity must be set at 3 years or a maximum of 39 months (keygen tool: ''-y 3'', openssl: ''-days 1170'').
+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://www.switch.ch/aai/guides/sp/configuration/#4|SWITCHaai]]. Please note that the period of validity must be set at 3 years or a maximum of 39 months (keygen tool: ''-y 3'', openssl: ''-days 1170''). The key length must be at least 3072 bits.
 \\