Differences

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

--- en:certificates [2022/12/01 15:32] – Wolfgang Pempe
+++ en:certificates [2023/02/01 17:42] (current) – Wolfgang Pempe
@@ Line 11: / Line 11: @@
 ==== 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, no matter which of the options mentioned below you choose. With Shibboleth SP this is the ''CredentialResolver'' element in /etc/shibboleth/shibboleth2.xml (see [[de:shibsp|Shibboleth SP (de)]]).
+\\
 === 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.
+\\
 === 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"''.
+\\
 === Own/Local CA ===
-For institutions/organisations participating in the DFN-AAI that operate a larger, two- to three-digit number of entities (e.g. local SPs) in the DFN-AAI, it may be an option to set up a local CA to issue certificates for SAML-based communication. \\
+For certificates from a local CA the same rules apply as for self-signed certificates, see below.
-**Note:** If required, local CAs can also be hosted by the DFN-PCA (contact: https://www.pki.dfn.de/pkikontakt/). \\
-**Important:** A local CA must be operated with great care! In particular, it must be ensured that the private key, which is used to sign the certificates to be issued, is particularly well protected! \\
+\\
-A good guide to operating your own CA can be found [[https://networklessons.com/uncategorized/openssl-certification-authority-ca-ubuntu-server|here]]. \\
-Parameters to be considered:
-  * Root Private Key: RSA, 4096 Bit
-  * Validity of the root certificate: 20 years (recommended)
-  * Validity of the issued certificates: max. 39 months
-  * Key length of the issued certificates: 4096 bit
-  * Signature algorithm: sha256
-  * The CN of the issued certificate corresponds to the FQDN of the respective IdP/SP host.
 === Self-signed Certificates ===