Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:certificates [2021/02/10 09:19] – alte Version wiederhergestellt (2021/01/26 09:32) Silke Meyer
+++ de:certificates [2021/07/13 10:21] – [Zertifikatstausch] Nochmal zum Mitschreiben: Zert. muss erst in MDV Silke Meyer
@@ Zeile 103: / Zeile 103: @@
   * Starten Sie den Webserver neu.
-=== Schritt 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen ===
+=== Schritt 4 beim IdP: Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen ===
-  * **Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem Termin zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten!**
+<callout color="#ff9900" title="24 Stunden Wartezeit">
+**Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem eigentlichen Tausch 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.
+  * 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.
+=== Schritt 5 beim IdP: Zertifikate für SAML-Kommunikation tauschen ===
   * Aktualisieren Sie Zertifikat und privaten Schlüssel auf Ihrem IdP. Prüfen Sie, ob die Links in ''conf/idp.properties'' auf die neuen Dateien zeigen.<code>
 idp.signing.key= /etc/ssl/private/idp.example.org.key.pem
@@ Zeile 116: / Zeile 122: @@
 === Schritt 4 beim SP: 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.
-  * 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>
+  * 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:
-root@sp # ps aux | grep shib | grep -v grep
+root@sp:~ # ps aux | grep shib | grep -v grep
 _shibd   31466  0.1 13.7 1912728 702900 ?      Ssl  Apr15   3:53 /usr/sbin/shibd -f -F
 # Gruppenzugehörigkeiten nachschlagen:
-root@sp # id _shibd
+root@sp:~ # id _shibd
 uid=112(_shibd) gid=121(_shibd) groups=121(_shibd),103(ssl-cert)
 # Abgleich mit den neuen Dateien:
@@ Zeile 138: / Zeile 144: @@
                             certificate="/etc/ssl/localcerts/2019-sp.example.org.crt.pem"/>
     </CredentialResolver></code>
-  * Prüfen Sie die SP-Konfiguration:<code>
+  * Prüfen Sie die SP-Konfiguration:<code bash>
-root@sp # shibd -tc /etc/shibboleth/shibboleth2.xml
+root@sp:~ # shibd -tc /etc/shibboleth/shibboleth2.xml
 overall configuration is loadable, check console for non-fatal problems
 </code>
-  * Starten Sie den Dienst ''shibd'' neu:<code>systemctl restart shibd</code>
+  * Starten Sie den Dienst ''shibd'' neu:<code bash>root@sp:~ # systemctl restart shibd</code>
   * Der Zwischenstand ist nun folgender: Der Service Provider kann SAML-Assertions entschlüsseln, die mit dem alten *oder* dem neuen Zertifikat verschlüsselt wurden. Er nutzt für Attribute Queries noch das alte Zertifikat.
-  * **Veröffentlichen Sie das neue Zertifikat zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten und warten Sie auch hier vorsichtshalber 24 Stunden mit dem nächsten Schritt.**
+<callout color="#ff9900" title="24 Stunden Wartezeit">
+**Veröffentlichen Sie das neue Zertifikat zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten und warten Sie 24 Stunden mit dem nächsten Schritt.**
+</callout>
+=== Schritt 5 beim SP: Zertifikate für SAML-Kommunikation tauschen ===
   * Konfigurieren Sie den SP um, so dass das neue Zertifikat an erster Stelle steht:<code xml>
     <CredentialResolver type="Chaining">
@@ Zeile 156: / Zeile 167: @@
                             certificate="/etc/ssl/localcerts/2016-sp.example.org.crt.pem"/>
     </CredentialResolver></code>
-  * Prüfen Sie die SP-Konfiguration:<code>
+  * Prüfen Sie die SP-Konfiguration:<code bash>
-root@sp # shibd -tc /etc/shibboleth/shibboleth2.xml
+root@sp:~ # shibd -tc /etc/shibboleth/shibboleth2.xml
 overall configuration is loadable, check console for non-fatal problems
 </code>
-  * Starten Sie den Dienst ''shibd'' neu:<code>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.
   * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie entweder löschen oder auskommentieren:<code xml>
@@ Zeile 175: / Zeile 186: @@
         -->
     </CredentialResolver></code>
-  * Prüfen Sie die SP-Konfiguration:<code>
+  * Prüfen Sie die SP-Konfiguration:<code bash>
-root@sp # shibd -tc /etc/shibboleth/shibboleth2.xml
+root@sp:~ # shibd -tc /etc/shibboleth/shibboleth2.xml
 overall configuration is loadable, check console for non-fatal problems
 </code>
-  * Starten Sie den Dienst ''shibd'' neu:<code>systemctl restart shibd</code>
+  * Starten Sie den Dienst ''shibd'' neu:<code bash>root@sp:~ # systemctl restart shibd</code>
 === Direkt verdrahtete IdPs/SPs ===