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
de:certificates [2023/02/01 15:54] – Wolfgang Pempede:certificates [2025/08/27 11:09] (aktuell) – [Informationen für Service Provider] Andreas Borm
Zeile 5: Zeile 5:
 Bei der SAML-basierten Kommunikation zwischen IdP und SP werden Zertifikate zur Signatur-Validierung sowie zum Verschlüsseln eingesetzt. Diese Zertifikate müssen für die betreffende Entity in der [[de:metadata_admin_tool|Metadatenverwaltung]] eingetragen werden. Bei der SAML-basierten Kommunikation zwischen IdP und SP werden Zertifikate zur Signatur-Validierung sowie zum Verschlüsseln eingesetzt. Diese Zertifikate müssen für die betreffende Entity in der [[de:metadata_admin_tool|Metadatenverwaltung]] eingetragen werden.
  
 +Bei unseren Vorgaben bzgl. Signaturalgorithmus und Schlüssellänge richten wir uns nach dem Empfehlungen des BSI ([[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=publicationFile&v|BSI TR-03116]], Kapitel 3). 
 <callout color="#ff9900" title="Zertifikate müssen gültig sein"> <callout color="#ff9900" title="Zertifikate müssen gültig sein">
 **Generell gilt:** Entities mit ungültigen, d.h. abgelaufenen oder zurückgezogenen Zertifikaten werden automatisch aus der DFN-AAI Produktivföderation entfernt! **Generell gilt:** Entities mit ungültigen, d.h. abgelaufenen oder zurückgezogenen Zertifikaten werden automatisch aus der DFN-AAI Produktivföderation entfernt!
Zeile 22: Zeile 23:
  
 === Zertifikate der DFN-PKI bzw. DFN-Verein Community PKI=== === Zertifikate der DFN-PKI bzw. DFN-Verein Community PKI===
-Für die SAML-basierte Kommunikation empfehlen sich **3 Jahre gültige Zertifikate aus der [[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community PKI]]**.+Für die SAML-basierte Kommunikation empfehlen sich **39 Monate gültige Zertifikate aus der [[de:dfnpki:dfnvereincommunitypki|DFN-Verein Community PKI]] (genauer: max. 1170 Tage)**.
 Wenn Sie berechtigt sind, Zertifikate von der DFN-PKI zu beantragen, wählen Sie bei der Beantragung bitte das Profil "Shibboleth IdP SP" aus. Dieses Zertifikat laden Sie in der Metadatenverwaltung hoch. Wenn Sie berechtigt sind, Zertifikate von der DFN-PKI zu beantragen, wählen Sie bei der Beantragung bitte das Profil "Shibboleth IdP SP" aus. Dieses Zertifikat laden Sie in der Metadatenverwaltung hoch.
  
Zeile 33: Zeile 34:
  
 === Selbst-signierte Zertifikate === === Selbst-signierte Zertifikate ===
-Die dritte Möglichkeit ist die Verwendung von selbst-signierten Zertifikaten mit einer Gültigkeitsdauer von maximal 39 Monaten. Wir empfehlen zur korrekten Erstellung die Dokumentation ​der [[https://www.switch.ch/aai/guides/sp/configuration/#4|SWITCHaai]]. Hierbei ist darauf zu achten, dass die Laufzeit auf 3 Jahre bzw. max. 39 Monate zu setzen ist (keygen Tool: ''-y 3'', openssl: ''-days 1170''). +Die dritte Möglichkeit ist die Verwendung von selbst-signierten Zertifikaten mit einer Gültigkeitsdauer von **maximal 39 Monaten**. Wir empfehlen zur korrekten Erstellung die Dokumentation ​der [[https://help.switch.ch/aai/guides/sp/embedded-certificate/?hostname=yourhost.example.org|SWITCHaai]]. Hierbei ist darauf zu achten, dass die Laufzeit auf **3 Jahre** bzw. **max. 39 Monate** zu setzen ist (keygen Tool: ''-y 3'', openssl: ''-days 1170''). Die Schlüssellänge muss **mindestens 3072 Bit** betragen.
  
 \\ \\
Zeile 64: Zeile 65:
 Vielen Dank an die Schweizer Kolleg*innen für die ausführliche englischsprachige [[https://www.switch.ch/aai/guides/sp/certificate-rollover/|Dokumentation]] zur SWITCHaai, die uns beim Erstellen als Vorlage gedient hat! Vielen Dank an die Schweizer Kolleg*innen für die ausführliche englischsprachige [[https://www.switch.ch/aai/guides/sp/certificate-rollover/|Dokumentation]] zur SWITCHaai, die uns beim Erstellen als Vorlage gedient hat!
  
-Wenn Sie ablaufende Zertifikate auf Ihrem AAI-Systemen austauschen müssen, gehen Sie wie folgt vor:+Wenn Sie ablaufende Zertifikate auf Ihren AAI-Systemen austauschen müssen, gehen Sie wie folgt vor:
  
 ==== 1. Was muss getauscht werden? ==== ==== 1. Was muss getauscht werden? ====
Zeile 77: Zeile 78:
   * 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.)
   * Starten Sie den Webserver neu.   * Starten Sie den Webserver neu.
 +  * Falls Sie für die SAML-Kommunikation ein anderes Zertifikat als für den Webserver verwenden (vgl. [[https://doku.tid.dfn.de/de:shibidp:prepare-zert#zertifikate_fuer_webserver_und_saml-basierte_kommunikation]]), tauschen Sie das Zertifikat für Port 8443 ([[https://doku.tid.dfn.de/de:shibidp:prepare-http#besonderheiten_bei_backchannel_requests]]) noch nicht jetzt, sondern erst nach dem letzten Schritt.
 ==== 4. Zertifikatswechsel auf dem IdP ==== ==== 4. Zertifikatswechsel auf dem IdP ====
   * Editieren Sie die Datei ''conf/credentials.xml'': Entfernen Sie dort die Kommentarzeichen um das zweite ''BasicX509CredentialFactoryBean''.<file xml>        <!--   * Editieren Sie die Datei ''conf/credentials.xml'': Entfernen Sie dort die Kommentarzeichen um das zweite ''BasicX509CredentialFactoryBean''.<file xml>        <!--
Zeile 89: Zeile 90:
             p:entityId-ref="entityID" />             p:entityId-ref="entityID" />
 </file> </file>
 +  * **ab IdP Version 4.3**: Editieren Sie die Datei ''conf/credentials.xml'': Entfernen Sie dort die Kommentarzeichen um das zweite ''BasicX509CredentialFactoryBean''.<file xml>        <!-- 
 +        For key rollover, uncomment and point to your original keypair, and use the one above 
 +        to point to your new keypair. Once metadata has propagated, comment this one out again. 
 +        --> 
 +         
 +        <bean parent="shibboleth.BasicX509CredentialFactoryBean" 
 +            p:privateKeyResource="%{idp.encryption.key.2}" 
 +            p:certificateResource="%{idp.encryption.cert.2}" 
 +            p:entityId-ref="entityID" /> 
 +</file>
  
 ==== 5. zweites Zertifikat für SAML-Kommunikation eintragen ==== ==== 5. zweites Zertifikat für SAML-Kommunikation eintragen ====
Zeile 103: Zeile 113:
  
 ==== 6. Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen ==== ==== 6. Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen ====
-<callout color="#ff9900" title="24 Stunden Wartezeit"> +
-**Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem nächsten Schritt zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten!** +
-</callout>+
   * Ein unterbrechungsfreier Betrieb ist nur möglich, wenn alle Service Provider weiterhin mit dem IdP kommunizieren können. Die SPs müssen sich vorab das neue Zertifikat aus den aktualisierten Föderationsmetadaten geholt haben. Besonders, wenn Sie an eduGAIN teilnehmen, müssen Sie davon ausgehen, dass manche SPs dies nur einmal pro Tag tun.   * Ein unterbrechungsfreier Betrieb ist nur möglich, wenn alle Service Provider weiterhin mit dem IdP kommunizieren können. Die SPs müssen sich vorab das neue Zertifikat aus den aktualisierten Föderationsmetadaten geholt haben. Besonders, wenn Sie an eduGAIN teilnehmen, müssen Sie davon ausgehen, dass manche SPs dies nur einmal pro Tag tun.
   * Wenn Sie bei der Erstellung des Zertifikatsantrags denselben privaten Schlüssel verwendet haben, den Sie auch für das ablaufende Zertifikat verwendet haben, ist die Veröffentlichung des neuen Zertifikates in Metadaten nicht so zeitkritisch. Das können Sie machen, wenn der Schlüssel nicht kompromittiert ist und nach wie vor den aktuellen technischen Anforderung entspricht.   * Wenn Sie bei der Erstellung des Zertifikatsantrags denselben privaten Schlüssel verwendet haben, den Sie auch für das ablaufende Zertifikat verwendet haben, ist die Veröffentlichung des neuen Zertifikates in Metadaten nicht so zeitkritisch. Das können Sie machen, wenn der Schlüssel nicht kompromittiert ist und nach wie vor den aktuellen technischen Anforderung entspricht.
- 
-==== 7. Alt und neu in der Konfiguration vertauschen ==== 
 <callout color="#ff9900" title="24 Stunden Wartezeit"> <callout color="#ff9900" title="24 Stunden Wartezeit">
-**Nach diesem Schritt warten Sie bitte erneut mindestens 24 Stunden, bevor Sie weitermachen.**+**Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem nächsten Schritt zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten!**
 </callout> </callout>
 +==== 7. Alt und neu in der Konfiguration vertauschen ====
 +
   * Nachdem das neue Zertifikat sich über die Metadaten herumgesprochen hat, entfernen Sie das alte Zertifikat aus den Föderationsmetadaten.   * 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>+  * In ''conf/idp.properties'' ersetzen Sie beim Signing-Key das alte durch das neue Zertifikat; beim Encryption-Key tauschen Sie 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 123: Zeile 131:
 </code> </code>
   * Starten Sie Tomcat neu.   * Starten Sie Tomcat neu.
 +<callout color="#ff9900" title="24 Stunden Wartezeit"> 
 +**Nach diesem Schritt warten Sie bitte erneut mindestens 24 Stunden, bevor Sie weitermachen.** 
 +</callout>
 ==== 8. Alte Zertifikate für SAML-Kommunikation aus Konfiguration entfernen ==== ==== 8. Alte Zertifikate für SAML-Kommunikation aus Konfiguration entfernen ====
   * Entfernen Sie das alte Zertifikat und den alten privaten Schlüssel aus der ''conf/idp.properties''.<code>   * Entfernen Sie das alte Zertifikat und den alten privaten Schlüssel aus der ''conf/idp.properties''.<code>
Zeile 139: Zeile 149:
         <!--         <!--
         <bean class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"         <bean class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
 +            p:privateKeyResource="%{idp.encryption.key.2}"
 +            p:certificateResource="%{idp.encryption.cert.2}"
 +            p:entityId-ref="entityID" />
 +        -->
 +</file>
 +
 +  * **Ab IdP Version 4.3**: Editieren Sie die Datei ''conf/credentials.xml'' erneut: Fügen Sie die Kommentarzeichen um das zweite ''BasicX509CredentialFactoryBean'' wieder ein.<file xml>        <!--
 +        For key rollover, uncomment and point to your original keypair, and use the one above
 +        to point to your new keypair. Once metadata has propagated, comment this one out again.
 +        -->
 +        <!--
 +        <bean parent="shibboleth.BasicX509CredentialFactoryBean"
             p:privateKeyResource="%{idp.encryption.key.2}"             p:privateKeyResource="%{idp.encryption.key.2}"
             p:certificateResource="%{idp.encryption.cert.2}"             p:certificateResource="%{idp.encryption.cert.2}"
Zeile 145: Zeile 167:
 </file> </file>
   * Starten Sie Tomcat neu.   * Starten Sie Tomcat neu.
 +  * Falls Sie für die SAML-Kommunikation ein anderes Zertifikat als für den Webserver verwenden, tauschen Sie jetzt auch das Zertifikat in der Konfiguration für Port 8443 (siehe [[https://doku.tid.dfn.de/de:shibidp:prepare-http#besonderheiten_bei_backchannel_requests]]).
  
 ===== Zertifikatstausch am SP ===== ===== Zertifikatstausch am SP =====
Zeile 210: Zeile 233:
 </code> </code>
   * Starten Sie den Dienst ''shibd'' neu:<code bash>root@sp:~ # systemctl restart shibd</code>   * Starten Sie den Dienst ''shibd'' neu:<code bash>root@sp:~ # systemctl restart shibd</code>
-  * Jetzt können Sie gleich das alte Zertifikat aus den Metadaten des SP herausnehmen. **Warten** Sie dann erneut bis zu 24 Stunden (sicher ist sicher), bis sich die Änderung in der DFN-AAI bzw. in eduGAIN herumgesprochen hat. 
  
-==== 6. Zertifikate für SAML-Kommunikation tauschen ====+<callout color="#ff9900" title="24 Stunden Wartezeit"> 
 +**Entfernen Sie jetzt das alte Zertifikat aus den Föderationsmetadaten und warten Sie 24 Stunden mit dem nächsten Schritt.** 
 +</callout> 
 +==== 6. Altes Zertifikat aus der SP-Konfiguration entfernen ====
  
   * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie es entweder löschen oder auskommentieren:<code xml>   * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie es entweder löschen oder auskommentieren:<code xml>
  • Zuletzt geändert: vor 3 Jahren