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 [2019/04/16 13:49] – [Schritt 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen] Silke Meyerde:certificates [2020/10/15 11:39] Silke Meyer
Zeile 1: Zeile 1:
-====== Zertifikate für die SAML-basierte Kommunikation ======+~~NOTOC~~ 
 +====== Zertifikate ====== 
 +{{INLINETOC 2}} 
 +===== Zertifikate für die SAML-basierte Kommunikation ===== 
 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.
  
 +<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!
 +</callout>
  
-===== Informationen für Identity Provider / Attribute Authorities ===== +==== Informationen für Identity Provider / Attribute Authorities ==== 
-Siehe unter [[de:shibidp3prepare-zert#dfn-pki-zertifikate|Vorbereitung: Zertifikate]]+Siehe unter [[de:shibidp:prepare-zert|Vorbereitung: Zertifikate]]
  
-===== Informationen für Service Provider =====+==== Informationen für Service Provider ====
 Unabhängig davon, welche der u.g. Varianten zum Einsatz kommen, müssen das für die SAML-basierte Kommunikation verwendete Zertifikat und der zugehörige Private Key in der SP-Konfiguration hinterlegt werden. Beim Shibboleth SP ist dies das Element ''CredentialResolver'' in /etc/shibboleth/shibboleth2.xml, s.u. [[de:shibsp|Shibboleth SP]] Unabhängig davon, welche der u.g. Varianten zum Einsatz kommen, müssen das für die SAML-basierte Kommunikation verwendete Zertifikat und der zugehörige Private Key in der SP-Konfiguration hinterlegt werden. Beim Shibboleth SP ist dies das Element ''CredentialResolver'' in /etc/shibboleth/shibboleth2.xml, s.u. [[de:shibsp|Shibboleth SP]]
-==== Zertifikate der DFN-PKI ====+=== Zertifikate der DFN-PKI === 
 +Siehe hierzu unter https://www.pki.dfn.de/dfn-aai-zertifikate/ \\
 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 Server-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 Server-Zertifikat laden Sie in der Metadatenverwaltung hoch.
  
-==== 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 und deren Gültigkeitsdauer maximal 825 Tage beträgt. \\
  
-==== 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:
   * Stellen Sie uns dasselbe Zertifikat auf Ihrem Webserver zum Download via https bereit (z.B. über den Metadata Handler Ihres Shibboleth SP oder über einen Download-Link zu der Datei). Der SSL-Download-Link muss von einer vertrauenswürdigen Zertifizierungsstelle abgesichert sein.   * Stellen Sie uns dasselbe Zertifikat auf Ihrem Webserver zum Download via https bereit (z.B. über den Metadata Handler Ihres Shibboleth SP oder über einen Download-Link zu der Datei). Der SSL-Download-Link muss von einer vertrauenswürdigen Zertifizierungsstelle abgesichert sein.
Zeile 25: Zeile 32:
   * Sie können uns das Zertifikat auch in einer via S/MIME signierten E-Mail an [[hotline@aai.dfn.de|hotline@aai.dfn.de]] schicken. Die Zertifizierungsstelle, die das S/MIME-Zertifikat ausgestellt hat, muss eine etablierte CA sein.   * Sie können uns das Zertifikat auch in einer via S/MIME signierten E-Mail an [[hotline@aai.dfn.de|hotline@aai.dfn.de]] schicken. Die Zertifizierungsstelle, die das S/MIME-Zertifikat ausgestellt hat, muss eine etablierte CA sein.
      
-<callout type="danger" title="Ausnahmen">+<callout color="#ff9900" title="Ausnahmen">
 Eine Ausnahme von den o.g. Regeln gilt bei SPs, die bereits in anderen Föderationen (mit anderen Zertifikats-Policies) registriert sind. In diesem Fall können die dort verwendeten Zertifikate auch für die DFN-AAI genutzt werden, auch wenn diese länger gültig sind. Eine Ausnahme von den o.g. Regeln gilt bei SPs, die bereits in anderen Föderationen (mit anderen Zertifikats-Policies) registriert sind. In diesem Fall können die dort verwendeten Zertifikate auch für die DFN-AAI genutzt werden, auch wenn diese länger gültig sind.
 </callout> </callout>
  
-==== Bitte nicht verwenden ====+=== Bitte nicht verwenden ===
  
-=== Wildcard-Zertifikate ===+== Wildcard-Zertifikate ==
 Die Nutzung von Wildcards in Zertifikaten ist nur in begründeten Ausnahmefällen gestattet.  Die Nutzung von Wildcards in Zertifikaten ist nur in begründeten Ausnahmefällen gestattet. 
  
-=== Letsencrypt ===+== Letsencrypt ==
 Für die Signierung und Verschlüsselung der SAML-Komunikation raten wir dringend von Letsenycrpt-Zertifikaten ab, da diese nur eine Gültigkeit von 90 Tagen haben. Ein Zertifikats-Rollover müsste jedes Mal manuell in der Metadatenverwaltung erfolgen. Auch die SP-Konfiguration muss beim Rollover 2x geändert werden. Wir empfehlen daher den Einsatz selbst-signierter Zertifikate. Für die Signierung und Verschlüsselung der SAML-Komunikation raten wir dringend von Letsenycrpt-Zertifikaten ab, da diese nur eine Gültigkeit von 90 Tagen haben. Ein Zertifikats-Rollover müsste jedes Mal manuell in der Metadatenverwaltung erfolgen. Auch die SP-Konfiguration muss beim Rollover 2x geändert werden. Wir empfehlen daher den Einsatz selbst-signierter Zertifikate.
  
 **Nächster Schritt:** [[de:functionaltest|Funktionstests]] **Nächster Schritt:** [[de:functionaltest|Funktionstests]]
  
-===== Zertifikatstausch =====+==== Zertifikatstausch ====
 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 Ihrem AAI-Systemen austauschen müssen, gehen Sie wie folgt vor:
  
-==== Schritt 1: Was muss getauscht werden? ====+=== Schritt 1: Was muss getauscht werden? ===
  
 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.
  
-==== Schritt 2: Beschaffung eines neuen Zertifikates bei der DFN-PKI ====+=== Schritt 2: Beschaffung eines neuen Zertifikates bei der DFN-PKI ===
  
 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. 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.
Zeile 70: Zeile 77:
   * Sie bekommen Ihr neues Zertifikat per E-Mail von der DFN-PKI.   * Sie bekommen Ihr neues Zertifikat per E-Mail von der DFN-PKI.
  
-==== Schritt 3: Ggf. Zertifikat am Webserver tauschen ==== +=== 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.   * Starten Sie den Webserver neu.
  
-==== Schritt 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen ====+=== Schritt 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen ===
   * **Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem Termin zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten!**   * **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>   * 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.key= /etc/ssl/private/idp.example.org.key.pem
 idp.signing.cert= /etc/ssl/localcerts/idp.example.org.crt.pem idp.signing.cert= /etc/ssl/localcerts/idp.example.org.crt.pem
Zeile 88: Zeile 92:
   * Sollten Sie nach dem Rollover Probleme mit einzelnen anderen Systemen in der DFN-AAI oder in eduGAIN haben, kann es sich um temporäre Probleme handeln, die darauf zurückzuführen sind, dass nicht alle Teilnehmenden die Föderationsmetadaten bei sich im selben Intervall aktualisieren.   * Sollten Sie nach dem Rollover Probleme mit einzelnen anderen Systemen in der DFN-AAI oder in eduGAIN haben, kann es sich um temporäre Probleme handeln, die darauf zurückzuführen sind, dass nicht alle Teilnehmenden die Föderationsmetadaten bei sich im selben Intervall aktualisieren.
  
-==== 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. 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">     <CredentialResolver type="Chaining">
         <!-- noch aktives altes Zertifikat -->         <!-- noch aktives altes Zertifikat -->
Zeile 106: Zeile 121:
 </code> </code>
   * Starten Sie den Dienst ''shibd'' neu:<code>systemctl restart shibd</code>   * Starten Sie den Dienst ''shibd'' neu:<code>systemctl restart shibd</code>
-  * Der Zwischenstand ist nun folgender: Der Service Provider can 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 auch hier vorsichtshalber 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>
Zeile 143: Zeile 158:
 </code> </code>
   * Starten Sie den Dienst ''shibd'' neu:<code>systemctl restart shibd</code>   * Starten Sie den Dienst ''shibd'' neu:<code>systemctl restart shibd</code>
-====== Die SSL-Zertifikatskette auf Ihrem Webserver ======+ 
 +=== Direkt verdrahtete IdPs/SPs === 
 +Wenn Sie SPs in der DFN-AAI vorbei direkt mit Ihrem IdP verbunden haben, haben Sie die Metadaten von IdP und SP manuell im jeweils anderen hinterlegt. Diese Metadatensätze müssen sie prüfen und ggf. manuell aktualisieren, wenn Sie auf einem oder beiden Systemen das Zertifikat getauscht haben. 
 + 
 +===== Die SSL-Zertifikatskette auf Ihrem Webserver =====
  
 Die SSL-Konfiguration Ihres Webservers hat direkt nichts mit der Zertifikat-Konfiguration für SAML-basierte Kommunikation in der DFN-AAI zu tun. Da aber sowohl die Binding URLs über SSL/TLS abgesichert werden (https), als auch der Aufruf der im Browser angezeigten IdP-/SP-Seiten, muss der Webserver in der Lage sein, eine vollständige Zertifikatskette ausliefern. Ist das nicht gegeben, wird Ihre Seite (IdP/SP) von Geräten, die die Kette validieren, nicht aufrufbar sein. Das bedeutet, dass etwa Android-Geräte die Login-Seite Ihres IdP nicht ohne Warnung besuchen können ("Dieser Verbindung wird nicht vertraut"). Sie können dies  beim Shibboleth IdP z.B. über den Aufruf der Statusseite prüfen (https://idp.domain.tld/idp/status), beim Shibboleth SP empfiehlt sich hierfür der Session Handler (https://sp.domain.tld/Shibboleth.sso/Session). Die SSL-Konfiguration Ihres Webservers hat direkt nichts mit der Zertifikat-Konfiguration für SAML-basierte Kommunikation in der DFN-AAI zu tun. Da aber sowohl die Binding URLs über SSL/TLS abgesichert werden (https), als auch der Aufruf der im Browser angezeigten IdP-/SP-Seiten, muss der Webserver in der Lage sein, eine vollständige Zertifikatskette ausliefern. Ist das nicht gegeben, wird Ihre Seite (IdP/SP) von Geräten, die die Kette validieren, nicht aufrufbar sein. Das bedeutet, dass etwa Android-Geräte die Login-Seite Ihres IdP nicht ohne Warnung besuchen können ("Dieser Verbindung wird nicht vertraut"). Sie können dies  beim Shibboleth IdP z.B. über den Aufruf der Statusseite prüfen (https://idp.domain.tld/idp/status), beim Shibboleth SP empfiehlt sich hierfür der Session Handler (https://sp.domain.tld/Shibboleth.sso/Session).
  
-===== Einrichtung der vollständigen Zertifikatskette auf dem Webserver =====+==== Einrichtung der vollständigen Zertifikatskette auf dem Webserver ====
  
   * Sie benötigen in jedem Fall zunächst eine Datei mit dem privaten Schlüssel (Private Key), z.B. unter Linux /etc/ssl/private/idp.domain.tld.key, sowie eine Datei, die das zum privaten Schlüssel passende Serverzertifikat enthält, z.B. unter Linux /etc/ssl/localcerts/idp.domain.tld.pem.   * Sie benötigen in jedem Fall zunächst eine Datei mit dem privaten Schlüssel (Private Key), z.B. unter Linux /etc/ssl/private/idp.domain.tld.key, sowie eine Datei, die das zum privaten Schlüssel passende Serverzertifikat enthält, z.B. unter Linux /etc/ssl/localcerts/idp.domain.tld.pem.
Zeile 170: Zeile 189:
 Beim Apache Webserver wird der Pfad zu dieser Datei als ''SSLCACertificateFile'' hinterlegt, siehe hierzu unter [[de:shibidp3prepare-http#konfiguration|IdP 3.x Vorarbeiten: HTTP-Server]] (IdP), bzw. [[de:shibsp#konfigurationsbeispiel|Shibboleth SP > Konfigurationsbeispiel]] (SP). Beim Apache Webserver wird der Pfad zu dieser Datei als ''SSLCACertificateFile'' hinterlegt, siehe hierzu unter [[de:shibidp3prepare-http#konfiguration|IdP 3.x Vorarbeiten: HTTP-Server]] (IdP), bzw. [[de:shibsp#konfigurationsbeispiel|Shibboleth SP > Konfigurationsbeispiel]] (SP).
  
-===== Überprüfung der Zertifikatskette =====+==== Überprüfung der Zertifikatskette ====
  
 Wenn Sie Ihre Zertifikatskette hinlegt, die Webserver-Konfiguration angepasst und aktiviert haben, können Sie sie mit OpenSSL zur Überprüfung abfragen: Wenn Sie Ihre Zertifikatskette hinlegt, die Webserver-Konfiguration angepasst und aktiviert haben, können Sie sie mit OpenSSL zur Überprüfung abfragen:
Zeile 307: Zeile 326:
 read:errno=0 read:errno=0
 </code> </code>
-**Nächster Schritt:** [[de:functionaltest|Funktionstests]]+
  • Zuletzt geändert: vor 12 Monaten