Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:certificates [2019/04/16 13:49] – [Schritt 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen] Silke Meyer
+++ de:certificates [2019/04/16 14:01] – [Schritt 3: Ggf. Zertifikat am Webserver tauschen] Silke Meyer
@@ Zeile 71: / Zeile 71: @@
 ==== Schritt 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.
+  * 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.
@@ Zeile 77: / Zeile 77: @@
   * **Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem Termin zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten!**
   * 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>
-# Settings for public/private signing and encryption key(s)
-# During decryption key rollover, point the ".2" properties at a second
-# keypair, uncomment in credentials.xml, then publish it in your metadata.
 idp.signing.key= /etc/ssl/private/idp.example.org.key.pem
 idp.signing.cert= /etc/ssl/localcerts/idp.example.org.crt.pem
@@ Zeile 90: / Zeile 87: @@
 ==== 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. Fügen Sie sie **zusätzlich** in die SP-Konfiguration ''shibboleth2.xml'' ein, und zwar **unter dem noch aktiven alten Zertifikat**:<code xml>
+  * 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>
+# Benutzerkennung feststellen:
+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
+uid=112(_shibd) gid=121(_shibd) groups=121(_shibd),103(ssl-cert)
+# Abgleich mit den neuen Dateien:
+-rw-r--r-- 1 root root 3719 Mar 27 10:43 /etc/ssl/localcerts/2019-sp.example.org.crt.pem
+-rw-r----- 1 root ssl-cert 3243 Mar 27 10:43 /etc/ssl/private/2019-sp.example.org.key.pem
+</code>
+  * Fügen Sie sie **zusätzlich** in die SP-Konfiguration ''shibboleth2.xml'' ein, und zwar **unter dem noch aktiven alten Zertifikat**:<code xml>
     <CredentialResolver type="Chaining">
         <!-- noch aktives altes Zertifikat -->