Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
de:certificates [2023/01/23 15:48] – [9. zweites Bean auskommentieren] + config snippet Silke Meyerde:certificates [2023/01/23 16:00] – [2. Beschaffung/Generierung eines neuen Zertifikates] kürzer Silke Meyer
Zeile 51: Zeile 51:
 Stellen Sie fest, ob es um die Webserver-Zertifikate oder um die Zertifikate für die SAML-basierte Kommunikation geht. Das kann, muss aber nicht dasselbe Zertifikat sein. Stellen Sie fest, ob es um die Webserver-Zertifikate oder um die Zertifikate für die SAML-basierte Kommunikation geht. Das kann, muss aber nicht dasselbe Zertifikat sein.
  
-==== 2. Beschaffung/Generierung eines neuen Zertifikates ==== +==== 2. Beschaffung eines neuen Zertifikates ==== 
-=== DFN-PKI === +siehe oben
-Bei Fragen zur Erstellung von privaten Schlüsseln und Zertifikatsanträgen, schauen Sie bitte in die Dokumentation der Software, mit der Sie diese generieren. Die DFN-PKI bietet eine [[https://www.pki.dfn.de/fileadmin/PKI/anleitungen/Anleitung_Nutzung_OpenSSL.pdf|Zusammenfassung der wichtigsten OpenSSL-Befehle]] und ausführliche [[https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c15083 | FAQ]] rund um Zertifikate. Das folgende Vorgehen müssen Sie möglicherweise an Ihre Umgebung anpassen. +
- +
-  * Sie können Ihren alten privaten Schlüssel weiterverwenden, wenn er nicht kompromittiert wurde. Oder Sie erstellen einen neuen privaten Schlüssel:<code> +
-user@host:~$ openssl genrsa -out idp.example.org.key.pem 4096 +
-</code> +
-  * Erstellen Sie einen Zertifikatsantrag (Certificate Signing Request, csr):<code> +
-user@host:~$ openssl req -new -key idp.example.org.key.pem -out idp.example.org.csr.pem +
-# Sie werden Folgendes abgefragt, evtl. befüllt mit Vorgaben aus Ihrer /etc/ssl/openssl.cnf +
-Country Name (2 letter code) [DE]: +
-State or Province Name (full name) []:            <== Bundesland +
-Locality Name (eg, city) []:                      <== Stadt +
-Organization Name (eg, company) []:               <== Einrichtung +
-Organizational Unit Name (eg, section) []:        <== ggf. Abteilung o.ä. +
-Common Name (eg, YOUR name) []:SERVERNAME         <== HIER DEN FQDN EINSETZEN! +
-A challenge password []: +
-An optional company name []: +
-</code> +
-  * Geben Sie diesen Zertifikatsantrag im .pem-Format bei der DFN-PKI ein. Wählen Sie das Profil "Shibboleth-IdP/-SP". +
-  * Sie bekommen Ihr neues Zertifikat per E-Mail von der DFN-PKI. +
- +
-=== Sonstige Zertifizierungsstellen bzw. CAs === +
-Konsultieren Sie hierzu die Dokumentation des [[#zertifikate_gaengiger_zertifizierungsstellen|jeweiligen Anbieters]] bzw. dessen Kundensupport.+
  
-=== Selbst-signierte Zertifikate === 
-Selbst-signierte Zertifikate sind ausschließlich für die SAML-basierte Kommunikation geeignet! Sowohl Shibboleth IdP als auch Shibboleth SP werden mit einem ''keygen'' Skript ausgeliefert, mit dessen Hilfe sich selbst-signierte Zertifikate erstellen lassen. Ansonsten ist dies z.B. auch mit OpenSSL möglich. Wichtig hierbei ist dass die Laufzeit 39 Monate nicht übersteigt und die Keylänge mindestens 3072 Bit beträgt (Voreinstellung bei Shibboleth). Siehe hierzu einstweilen die Dokumentation von SWITCH: 
-  * [[https://www.switch.ch/aai/guides/idp/certificate-rollover/|Shibboleth IdP, Step 0]] (Wichtig: Tomcat User muss Leserecht auf den private Key haben.) 
-  * [[https://www.switch.ch/aai/guides/sp/certificate-rollover/|Shibboleth SP, Step 0]] 
-  * [[https://www.switch.ch/aai/support/certificates/embeddedcerts-requirements-appendix-a/|OpenSSL]] 
  
 ==== 3. Ggf. Zertifikat am Webserver tauschen ==== ==== 3. Ggf. Zertifikat am Webserver tauschen ====
Zeile 118: Zeile 91:
  
 ==== 7. Alt und neu in der Konfiguration vertauschen ==== ==== 7. Alt und neu in der Konfiguration vertauschen ====
-  * Nachdem das neue Zertifikat sich über die Metadaten herumgesprochen hat, tauschen Sie in ''conf/idp.properties'' alt und neu:<code>+<callout color="#ff9900" title="24 Stunden Wartezeit"> 
 +**Nach diesem Schritt warten Sie bitte erneut mindestens 24 Stunden, bevor Sie weitermachen.** 
 +</callout> 
 +  * Nachdem das neue Zertifikat sich über die Metadaten herumgesprochen hat, entfernen Sie das alte Zertifikat aus den Föderationsmetadaten. 
 +  * Tauschen Sie in ''conf/idp.properties'' alt und neu:<code>
 idp.signing.key= /etc/ssl/private/idp_neu.example.org.key.pem idp.signing.key= /etc/ssl/private/idp_neu.example.org.key.pem
 idp.signing.cert= /etc/ssl/localcerts/idp_neu.example.org.crt.pem idp.signing.cert= /etc/ssl/localcerts/idp_neu.example.org.crt.pem
Zeile 127: Zeile 104:
 </code> </code>
   * Starten Sie Tomcat neu.   * Starten Sie Tomcat neu.
-  * **Warten Sie erneut 24 Stunden!** 
  
 ==== 8. Alte Zertifikate für SAML-Kommunikation aus Konfiguration entfernen ==== ==== 8. Alte Zertifikate für SAML-Kommunikation aus Konfiguration entfernen ====
Zeile 158: Zeile 134:
  
 ==== 2. Beschaffung eines neuen Zertifikates ==== ==== 2. Beschaffung eines neuen Zertifikates ====
-=== DFN-PKI === +siehe oben
-Bei Fragen zur Erstellung von privaten Schlüsseln und Zertifikatsanträgen, schauen Sie bitte in die Dokumentation der Software, mit der Sie diese generieren. Die DFN-PKI bietet eine [[https://www.pki.dfn.de/fileadmin/PKI/anleitungen/Anleitung_Nutzung_OpenSSL.pdf|Zusammenfassung der wichtigsten OpenSSL-Befehle]] und ausführliche [[https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c15083 | FAQ]] rund um Zertifikate. Das folgende Vorgehen müssen Sie möglicherweise an Ihre Umgebung anpassen. +
- +
-  * Sie können Ihren alten privaten Schlüssel weiterverwenden, wenn er nicht kompromittiert wurde. Oder Sie erstellen einen neuen privaten Schlüssel:<code> +
-user@host:~$ openssl genrsa -out idp.example.org.key.pem 4096 +
-</code> +
-  * Erstellen Sie einen Zertifikatsantrag (Certificate Signing Request, csr):<code> +
-user@host:~$ openssl req -new -key idp.example.org.key.pem -out idp.example.org.csr.pem +
-# Sie werden Folgendes abgefragt, evtl. befüllt mit Vorgaben aus Ihrer /etc/ssl/openssl.cnf +
-Country Name (2 letter code) [DE]: +
-State or Province Name (full name) []:            <== Bundesland +
-Locality Name (eg, city) []:                      <== Stadt +
-Organization Name (eg, company) []:               <== Einrichtung +
-Organizational Unit Name (eg, section) []:        <== ggf. Abteilung o.ä. +
-Common Name (eg, YOUR name) []:SERVERNAME         <== HIER DEN FQDN EINSETZEN! +
-A challenge password []: +
-An optional company name []: +
-</code> +
-  * Geben Sie diesen Zertifikatsantrag im .pem-Format bei der DFN-PKI ein. Wählen Sie das Profil "Shibboleth-IdP/-SP". +
-  * Sie bekommen Ihr neues Zertifikat per E-Mail von der DFN-PKI. +
- +
-=== Sonstige Zertifizierungsstellen bzw. CAs === +
-Konsultieren Sie hierzu die Dokumentation des [[#zertifikate_gaengiger_zertifizierungsstellen|jeweiligen Anbieters]] bzw. dessen Kundensupport. +
- +
-=== Selbst-signierte Zertifikate === +
-Selbst-signierte Zertifikate sind ausschließlich für die SAML-basierte Kommunikation geeignet! Sowohl Shibboleth IdP als auch Shibboleth SP werden mit einem ''keygen'' Skript ausgeliefert, mit dessen Hilfe sich selbst-signierte Zertifikate erstellen lassen. Ansonsten ist dies z.B. auch mit OpenSSL möglich. Wichtig hierbei ist dass die Laufzeit 39 Monate nicht übersteigt und die Keylänge mindestens 3072 Bit beträgt (Voreinstellung bei Shibboleth). Siehe hierzu einstweilen die Dokumentation von SWITCH: +
-  * [[https://www.switch.ch/aai/guides/idp/certificate-rollover/|Shibboleth IdP, Step 0]] (Wichtig: Tomcat User muss Leserecht auf den private Key haben.) +
-  * [[https://www.switch.ch/aai/guides/sp/certificate-rollover/|Shibboleth SP, Step 0]] +
-  * [[https://www.switch.ch/aai/support/certificates/embeddedcerts-requirements-appendix-a/|OpenSSL]] +
 ==== 3. Ggf. Zertifikat am Webserver tauschen ==== ==== 3. Ggf. Zertifikat am Webserver tauschen ====
   * Ersetzen Sie die alten, in der Webserverkonfiguration eingetragenen Dateien durch das neue Zertifikat, den privaten Schlüssel und die Zertifikatskette. (Unten auf dieser Seite ist erklärt, wie Sie die [[https://doku.tid.dfn.de/de:certificates#die_ssl-zertifikatskette_auf_ihrem_webserver|komplette Zertifikatskette]] ausliefern.)   * Ersetzen Sie die alten, in der Webserverkonfiguration eingetragenen Dateien durch das neue Zertifikat, den privaten Schlüssel und die Zertifikatskette. (Unten auf dieser Seite ist erklärt, wie Sie die [[https://doku.tid.dfn.de/de:certificates#die_ssl-zertifikatskette_auf_ihrem_webserver|komplette Zertifikatskette]] ausliefern.)
Zeile 193: Zeile 140:
  
 ==== 4. Zertifikate für SAML-Kommunikation tauschen ==== ==== 4. Zertifikate für SAML-Kommunikation tauschen ====
-Im Gegensatz zum IdP ist beim SP zu beachten, dass der **SP vorübergehend beide Zertifikate bzw. Schlüssel benötigt**, alt und neu, denn er muss in der Lage sein, Authentication Requests zu signieren und SAML Assertions zu entschlüsseln.+Der **SP benötigt vorübergehend beide Zertifikate bzw. Schlüssel**, alt und neu, denn er muss in der Lage sein, Authentication Requests zu signieren und SAML Assertions zu entschlüsseln.
   * Legen Sie das neue Zertifikat, den privaten Schlüssel und ggf. die Zertifikatskette auf den Server. Es ist wichtig, dass der Benutzer, mit dessen Kennung der ''shibd''-Prozess läuft, die Dateien lesen kann.<code bash>   * Legen Sie das neue Zertifikat, den privaten Schlüssel und ggf. die Zertifikatskette auf den Server. Es ist wichtig, dass der Benutzer, mit dessen Kennung der ''shibd''-Prozess läuft, die Dateien lesen kann.<code bash>
 # Benutzerkennung feststellen: # Benutzerkennung feststellen:
  • Zuletzt geändert: vor 9 Tagen