Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
en:certificates [2021/08/04 09:22] – Wolfgang Pempeen:certificates [2024/08/27 08:23] (current) – [Information for Service Providers] 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, 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)]]). 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 === === DFN-PKI Certificates ===
-For general information, please refer to https://www.pki.dfn.de/dfn-aai-zertifikate/ \\ +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. 
-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 === === 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]].  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 === === 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. In such a case, only the respective root certificate of the CA must be verified by the DFN-AAI team. Verification is carried out in the same way as for self-signed certificates (see below). \\ +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: at least 3072 bit +
-  * Signature algorithm: sha256 +
-  * The CN of the issued certificate corresponds to the FQDN of the respective IdP/SP host.+
  
 === 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://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.  
-Before joining the DFN-AAI production federation, self-signed certificates have to be verified by the DFN-AAI operations team. For this purpose, the following options are available after you uploaded your certificate in the metadata administration tool: + 
-  * Send us the certificate in an S/MIME-signed (signing cert form a well known CA) email to [[hotline@aai.dfn.de|hotline@aai.dfn.de]]. For us, it works best if you copy the content of the .pem file into the signed email. +\\
-  * An alternative way is to 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 none of these options works for you, please get in touch with us (+49 30 884299-9124, [[hotline@aai.dfn.de|hotline@aai.dfn.de]]).+
  
-<callout type="danger" title="Exceptions">+<callout color="#ff9900" title="Exceptions">
 **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]]. **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]].
 </callout> </callout>
Line 89: Line 97:
 If there is another intermediate certificate, compare the above issuer hash with its hash and so on. Like this, you crawl up to the root certificate step by step. If there is another intermediate certificate, compare the above issuer hash with its hash and so on. Like this, you crawl up to the root certificate step by step.
  
-If you use the Apache webserver, point the SSLCACertificateFile directive to your chain file. (See the example configuration on [[de:shibidp3prepare-http#konfiguration|IdP Preparations: HTTPServer]] resp. [[de:shibsp#konfigurationsbeispiel|Shibboleth SP configuration example]]).+If you use the Apache webserver, point the SSLCACertificateFile directive to your chain file. (See the example configuration on [[de:shibidp:prepare-http#vhost-konfiguration|IdP Preparations: Webserver]] (de) resp. [[de:shibsp#konfigurationsbeispiel|Shibboleth SP configuration example]]).
  
 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:
  • Last modified: 4 years ago