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 [2021/01/26 09:28] – Wolfgang Pempede:certificates [2021/02/22 10:50] – [Zertifikatstausch] Silke Meyer
Zeile 20: Zeile 20:
  
 === Zertifikate gängiger Zertifizierungsstellen === === Zertifikate gängiger Zertifizierungsstellen ===
-Alternativ können Sie Zertifikate von CAs nutzen, die in den gängigen Standardbrowsern (Google Chrome, Firefox, Microsoft Edge) vorinstalliert sind und deren Gültigkeitsdauer maximal 825 Tage beträgt. \\+Alternativ können Sie Zertifikate von CAs nutzen, die in den gängigen Standardbrowsern (Google Chrome, Firefox, Microsoft Edge) vorinstalliert sind. \\
  
 === Eigene/lokale CA === === Eigene/lokale CA ===
 Für an der DFN-AAI teilnehmende Einrichtungen/Organisationen, die eine größere, zwei- bis dreistellige Anzahl von Entities, z.B. lokale SPs in der DFN-AAI betreiben, kann es sich lohnen, eine lokale CA aufzusetzen, um Zertifikate für die SAML-basierte Kommunikation auszustellen. In solch einem Fall muss nur das zugehörige CA-Zertifikat seitens des DFN-AAI-Teams verifiziert werden. Die Verifizierung erfolgt analog zu der [[#selbst-signierte_zertifikate|selbst-signierter Zertifikate]]. \\ Für an der DFN-AAI teilnehmende Einrichtungen/Organisationen, die eine größere, zwei- bis dreistellige Anzahl von Entities, z.B. lokale SPs in der DFN-AAI betreiben, kann es sich lohnen, eine lokale CA aufzusetzen, um Zertifikate für die SAML-basierte Kommunikation auszustellen. In solch einem Fall muss nur das zugehörige CA-Zertifikat seitens des DFN-AAI-Teams verifiziert werden. Die Verifizierung erfolgt analog zu der [[#selbst-signierte_zertifikate|selbst-signierter Zertifikate]]. \\
 +**Hinweis:** Bei Bedarf können lokale CAs auch von der DFN-PCA gehostet werden (Kontakt: https://www.pki.dfn.de/pkikontakt/). \\
 **Wichtig:** Eine lokale CA will mit großer Sorgfalt betrieben werden! Insbesondere ist sicherzustellen, dass der Private Key, anhand dessen die auszustellenden Zertifikate signiert werden, besonders gut geschützt ist! \\ **Wichtig:** Eine lokale CA will mit großer Sorgfalt betrieben werden! Insbesondere ist sicherzustellen, dass der Private Key, anhand dessen die auszustellenden Zertifikate signiert werden, besonders gut geschützt ist! \\
 Eine gute Anleitung zum Betrieb einer eigenen CA findet sich [[https://networklessons.com/uncategorized/openssl-certification-authority-ca-ubuntu-server|hier]]. \\ Eine gute Anleitung zum Betrieb einer eigenen CA findet sich [[https://networklessons.com/uncategorized/openssl-certification-authority-ca-ubuntu-server|hier]]. \\
Zeile 33: Zeile 34:
   * Signatur-Algorithmus: sha256   * Signatur-Algorithmus: sha256
   * Der CN des ausgestellten Zertifikats entspricht dem FQDN des jeweiligen IdP-/SP-Hosts    * Der CN des ausgestellten Zertifikats entspricht dem FQDN des jeweiligen IdP-/SP-Hosts 
-**Hinweis:** Bei Bedarf können lokale CAs auch von der DFN-PCA gehostet werden (Kontakt: https://www.pki.dfn.de/pkikontakt/).+
 === 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]]. Selbst-signierte Zertifikate müssen vor der Aufnahme in die DFN-AAI Produktivumgebung verifiziert werden. Hierfür stehe folgende Optionen zur Verfügung, nachdem Sie das Server-Zertifikat in der Metadatenverwaltung hochgeladen haben: 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]]. Selbst-signierte Zertifikate müssen vor der Aufnahme in die DFN-AAI Produktivumgebung verifiziert werden. Hierfür stehe folgende Optionen zur Verfügung, nachdem Sie das Server-Zertifikat in der Metadatenverwaltung hochgeladen haben:
Zeile 115: Zeile 116:
 === Schritt 4 beim SP: Zertifikate für SAML-Kommunikation tauschen === === 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. 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: # 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 _shibd   31466  0.1 13.7 1912728 702900 ?      Ssl  Apr15   3:53 /usr/sbin/shibd -f -F
 # Gruppenzugehörigkeiten nachschlagen: # Gruppenzugehörigkeiten nachschlagen:
-root@sp # id _shibd +root@sp:~ # id _shibd 
 uid=112(_shibd) gid=121(_shibd) groups=121(_shibd),103(ssl-cert) uid=112(_shibd) gid=121(_shibd) groups=121(_shibd),103(ssl-cert)
 # Abgleich mit den neuen Dateien: # Abgleich mit den neuen Dateien:
Zeile 137: Zeile 138:
                             certificate="/etc/ssl/localcerts/2019-sp.example.org.crt.pem"/>                             certificate="/etc/ssl/localcerts/2019-sp.example.org.crt.pem"/>
     </CredentialResolver></code>     </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 overall configuration is loadable, check console for non-fatal problems
 </code> </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.   * 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.**+  * **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.**
   * Konfigurieren Sie den SP um, so dass das neue Zertifikat an erster Stelle steht:<code xml>   * Konfigurieren Sie den SP um, so dass das neue Zertifikat an erster Stelle steht:<code xml>
     <CredentialResolver type="Chaining">     <CredentialResolver type="Chaining">
Zeile 155: Zeile 156:
                             certificate="/etc/ssl/localcerts/2016-sp.example.org.crt.pem"/>                             certificate="/etc/ssl/localcerts/2016-sp.example.org.crt.pem"/>
     </CredentialResolver></code>     </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 overall configuration is loadable, check console for non-fatal problems
 </code> </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.   * 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>   * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie entweder löschen oder auskommentieren:<code xml>
Zeile 174: Zeile 175:
         -->         -->
     </CredentialResolver></code>     </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 overall configuration is loadable, check console for non-fatal problems
 </code> </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 === === Direkt verdrahtete IdPs/SPs ===
  • Zuletzt geändert: vor 6 Tagen