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 [2019/04/16 13:49] – [Schritt 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen] Silke Meyerde:certificates [2023/04/13 17:49] (aktuell) Wolfgang Pempe
Zeile 1: Zeile 1:
-====== Zertifikate für die SAML-basierte Kommunikation ======+====== Zertifikate ====== 
 + 
 +===== 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 ===== +\\
-Siehe unter [[de:shibidp3prepare-zert#dfn-pki-zertifikate|Vorbereitung: Zertifikate]]+
  
-===== Informationen für Service Provider =====+==== Informationen für Identity Provider / Attribute Authorities ==== 
 +Siehe unter [[de:shibidp:prepare-zert|Vorbereitung: Zertifikate]] 
 + 
 +\\ 
 + 
 +==== 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 ==== 
-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 ==== +\\
-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 ==== +=== Zertifikate der DFN-PKI bzw. DFN-Verein Community PKI=== 
-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: +Für die SAML-basierte Kommunikation empfehlen sich **39 Monate gültige Zertifikate aus der [[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community PKI]] (genauer: max. 1170 Tage)**. 
-  * 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. +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 keine Möglichkeit habenuns einen Download-Link zur Verfügung zu stellen, können Sie den Fingerprint des Server-Zertifikates telefonisch oder per Fax mit uns vergleichen. Kontaktieren Sie hierzu bitte die DFN-AAI Hotline (+49-711-63314-215, [[hotline@aai.dfn.de|hotline@aai.dfn.de]]). So lassen Sie sich die Fingerprints ausgeben: + 
-<code> +\\ 
-$ openssl x509 -noout -fingerprint -sha1 -in self-signed-server-cert.pem + 
-$ openssl x509 -noout -fingerprint -sha256 -in self-signed-server-cert.pem +=== Eigene/lokale CA === 
-</code> +Für Zertifikate aus einer eigenen/lokalen CA gelten die selben Regeln wie für selbst-signierte Zertifikate, siehe unten.  
-  * 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 hatmuss eine etablierte CA sein+ 
-   +\\ 
-<callout type="danger" title="Ausnahmen">+ 
 +=== 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 bzwmax39 Monate zu setzen ist (keygen Tool: ''-y 3''openssl: ''-days 1170'').  
 + 
 +\\ 
 + 
 +=== Zertifikate gängiger Zertifizierungsstellen === 
 +Alternativ können Zertifikate aus CAs genutzt werden, die in den gängigen Standardbrowsern (Google ChromeFirefox, Microsoft Edge) vorinstalliert sind.  
 + 
 +<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>
 +  
 +\\  
 +  
 +=== Vorsicht bei der Verwendung von Wildcard-Zertifikaten! ===
 +Da Wildcard-Zertifikate für eine ganze Subdomain gelten und daher für mehrere Entities gleichzeitig verwendet werden können, ist der potentielle Schaden bei einer Kompromittierung des privaten Schlüssels deutlich höher als bei Zertifikaten für genau spezifizierte FQDNs. Daher sollten Wildcard-Zertifikate in der DFN-AAI nur verwendet werden, wenn das Einsatzszenario dies technisch erzwingt. Beispielsweise existieren insbesondere im Bibliotheksumfeld Softwaresysteme, die dynamisch Host-Names erzeugen und die mit herkömmlichen Zertifikaten nicht funktionieren. Beispiele für solche Software: EZProxy, Netman/HAN. \\
 +Ein und dasselbe Wildcard-Zertifikat sollte nicht auf verschiedenen Servern mit unterschiedlichen Diensten, Einsatzzwecken oder Schutzklassen verwendet werden. Aufgrund des höheren Schadenspotentials bei Kompromittierung sind Wildcard-Zertifikate kein probates Mittel der Arbeitsersparnis bei der Beantragung und dem Deployment von Zertifikaten.
 +\\
 +Wildcard-Zertifikat werden in der DFN-AAI daher nur unterhalb von Sub-Domains oder Second-Level-Domains akzeptiert, die ausschließlich für einen klar abgegrenzten Zweck genutzt werden, also beispielsweise entweder für ''"*.ub.uni-example.de"'' oder für ''"*.medizin.uni-example.de"'', nicht aber für ''"*.uni-example.de"''.
  
-==== Bitte nicht verwenden ====+\\
  
-=== Wildcard-Zertifikate === +=== Keine Letsencrypt-Zertifikate === 
-Die Nutzung von Wildcards in Zertifikaten ist nur in begründeten Ausnahmefällen gestattet+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 oder solcher aus der DFN-Verein Community PKI (siehe oben).
  
-=== 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.+
  
 **Nächster Schritt:** [[de:functionaltest|Funktionstests]] **Nächster Schritt:** [[de:functionaltest|Funktionstests]]
  
-===== Zertifikatstausch =====+===== Zertifikatstausch am IdP =====
 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 1Was muss getauscht werden? ====+==== 1Was 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 2Beschaffung eines neuen Zertifikates bei der DFN-PKI ====+==== 2Beschaffung eines neuen Zertifikates ==== 
 +siehe oben
  
-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. 
  
-  Erstellen Sie einen privaten Schlüssel:<code+==== 3. Ggf. Zertifikat am Webserver tauschen ==== 
-user@host:~$ openssl genrsa -out idp.example.org.key.pem 4096+  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. 
 + 
 +==== 4. Zertifikatswechsel auf dem IdP ==== 
 +  * 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 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> 
 + 
 + 
 +==== 5. zweites Zertifikat für SAML-Kommunikation eintragen ==== 
 +  * Tragen Sie das neue Zertifikat und den dazugehörigen privaten Schlüssel zusätzlich in ''conf/idp.properties'' ein:<code> 
 +idp.signing.key= /etc/ssl/private/idp_alt.example.org.key.pem 
 +idp.signing.cert= /etc/ssl/localcerts/idp_alt.example.org.crt.pem 
 +idp.encryption.key= /etc/ssl/private/idp_alt.example.org.key.pem 
 +idp.encryption.cert= /etc/ssl/localcerts/idp_alt.example.org.crt.pem 
 +idp.encryption.key.2= /etc/ssl/private/idp_neu.example.org.key.pem 
 +idp.encryption.cert.2= /etc/ssl/localcerts/idp_neu.example.org.crt.pem
 </code> </code>
-  * Erstellen Sie einen Zertifikatsantrag (Certificate Signing Request, csr):<code> +  * Starten Sie Tomcat neu.
-user@host:~$ openssl req -new -key idp.example.org.key.pem -out idp.example.org.csr.pem +
-# Sie werden Folgendes abgefragt, evtl. befüllt mit Vorgaben aus Ihrer /etc/ssl/openssl.cnf +
-Country Name (2 letter code) [DE]: +
-State or Province Name (full name) []:            <== Bundesland +
-Locality Name (eg, city) []:                      <== Stadt +
-Organization Name (eg, company) []:               <== Einrichtung +
-Organizational Unit Name (eg, section) []:        <== ggf. Abteilung o.ä. +
-Common Name (eg, YOUR name) []:SERVERNAME         <== HIER DEN FQDN EINSETZEN! +
-A challenge password []: +
-An optional company name []: +
-</code> +
-  * Geben Sie diesen Zertifikatsantrag im .pem-Format bei der DFN-PKI ein. Wählen Sie das Profil "Shibboleth-IdP/-SP"+
-  * Sie bekommen Ihr neues Zertifikat per E-Mail von der DFN-PKI.+
  
-==== Schritt 3: Ggf. Zertifikat am Webserver tauschen ==== +==== 6. Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen ==== 
-  Ersetzen Sie die altenin der Webserverkonfiguration eingetragenen Dateien durch das neue Zertifikatden privaten Schlüssel und die Zertifikatskette+<callout color="#ff9900" title="24 Stunden Wartezeit"> 
-  * Starten Sie den Webserver neu.+**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
 +  * 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 4 beim IdP: Zertifikate für SAML-Kommunikation tauschen ==== +==== 7. Alt und neu in der Konfiguration vertauschen ==== 
-  * **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"> 
-  * Aktualisieren Sie Zertifikat und privaten Schlüssel auf Ihrem IdPPrüfen Sie, ob die Links in ''conf/idp.properties'' auf die neuen Dateien zeigen.<code> +**Nach diesem Schritt warten Sie bitte erneut mindestens 24 Stunden, bevor Sie weitermachen.** 
-# Settings for public/private signing and encryption key(s) +</callout> 
-# During decryption key rollover, point the ".2" properties at a second +  * Nachdem das neue Zertifikat sich über die Metadaten herumgesprochen hat, entfernen Sie das alte Zertifikat aus den Föderationsmetadaten. 
-# keypair, uncomment in credentials.xml, then publish it in your metadata+  * Tauschen Sie in ''conf/idp.properties'' alt und neu:<code> 
-idp.signing.key= /etc/ssl/private/idp.example.org.key.pem +idp.signing.key= /etc/ssl/private/idp_neu.example.org.key.pem 
-idp.signing.cert= /etc/ssl/localcerts/idp.example.org.crt.pem +idp.signing.cert= /etc/ssl/localcerts/idp_neu.example.org.crt.pem 
-idp.encryption.key= /etc/ssl/private/idp.example.org.key.pem +idp.encryption.key= /etc/ssl/private/idp_neu.example.org.key.pem 
-idp.encryption.cert= /etc/ssl/localcerts/idp.example.org.crt.pem+idp.encryption.cert= /etc/ssl/localcerts/idp_neu.example.org.crt.pem 
 +idp.encryption.key.2= /etc/ssl/private/idp_alt.example.org.key.pem 
 +idp.encryption.cert.2= /etc/ssl/localcerts/idp_alt.example.org.crt.pem
 </code> </code>
   * Starten Sie Tomcat neu.   * Starten Sie Tomcat neu.
-  * 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 ==== +==== 8. Alte Zertifikate für SAML-Kommunikation aus Konfiguration entfernen ==== 
-Im Gegensatz zum IdP ist beim SP zu beachtendass 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. +  * Entfernen Sie das alte Zertifikat und den alten privaten Schlüssel aus der ''conf/idp.properties''.<code> 
-  * 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>+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.encryption.key= /etc/ssl/private/idp_neu.example.org.key.pem 
 +idp.encryption.cert= /etc/ssl/localcerts/idp_neu.example.org.crt.pem 
 +</code> 
 + 
 +==== 9. zweites Bean auskommentieren === 
 +  * Editieren Sie die Datei ''conf/credentials.xml'' erneutFü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 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> 
 +  * Starten Sie Tomcat neu. 
 + 
 +===== Zertifikatstausch am SP ===== 
 + 
 +==== 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. 
 + 
 +==== 2. Beschaffung eines neuen Zertifikates ==== 
 +siehe oben 
 +==== 3. Ggf. Zertifikat am Webserver tauschen ==== 
 +  * Ersetzen Sie die altenin 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. 
 + 
 +==== 4. Zertifikate für SAML-Kommunikation tauschen ==== 
 +Der **SP benötigt vorübergehend beide Zertifikate bzw. Schlüssel**, 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 bash> 
 +# 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 101: Zeile 182:
                             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 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.**+<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> 
 + 
 +==== 5. Zertifikate für SAML-Kommunikation tauschen ==== 
   * 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 119: Zeile 205:
                             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 bzwin eduGAIN herumgesprochen hat+ 
-  * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie entweder löschen oder auskommentieren:<code xml>+<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> 
 +==== 6Altes 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>
     <CredentialResolver type="Chaining">     <CredentialResolver type="Chaining">
         <!-- neues Zertifikat -->             <!-- neues Zertifikat -->    
Zeile 138: Zeile 229:
         -->         -->
     </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> 
-====== Die SSL-Zertifikatskette auf Ihrem Webserver ======+ 
 +==== Direkt verdrahtete IdPs/SPs ==== 
 +Wenn Sie SPs an 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.
   * Sie erstellen eine dritte Datei mit der kompletten Zertifikatskette. z.B. /etc/ssl/certs/idp.domain.tld.pem. Diese Datei hinterlegen in der Webserver-Konfiguration als SSL-Zertifikat. Sie enthält:   * Sie erstellen eine dritte Datei mit der kompletten Zertifikatskette. z.B. /etc/ssl/certs/idp.domain.tld.pem. Diese Datei hinterlegen in der Webserver-Konfiguration als SSL-Zertifikat. Sie enthält:
     * Serverzertifikat     * Serverzertifikat
-    * das/die Zwischenzertifikat(e) (Intermediate) +    * das Zwischenzertifikat (Intermediate) bzw. alle Zwischenzertifikate
-    * Root-Zertifikat der CA+
 Die Zertifikate werden in dieser Reihenfolge direkt untereinander gehängt. Dazwischen dürfen Kommentare eingefügt werden (mit "#" beginnend). Die Kette darf keine zusätzlichen Zertifikate enthalten. Unten sehen Sie als Beispiel die Kette der Domain dfn.de. Die Zertifikate werden in dieser Reihenfolge direkt untereinander gehängt. Dazwischen dürfen Kommentare eingefügt werden (mit "#" beginnend). Die Kette darf keine zusätzlichen Zertifikate enthalten. Unten sehen Sie als Beispiel die Kette der Domain dfn.de.
  
Zeile 168: Zeile 264:
   * Wenn es ein weiteres Intermediate-Zertifikat gibt, vergleichen Sie obigen Issuer-Hash mit dem Hash des zweiten Intermediate-Zertifikates und so weiter. Auf diese Weise arbeiten Sie sich durch die Kette "hoch" bis zum Root-Zertifikat.   * Wenn es ein weiteres Intermediate-Zertifikat gibt, vergleichen Sie obigen Issuer-Hash mit dem Hash des zweiten Intermediate-Zertifikates und so weiter. Auf diese Weise arbeiten Sie sich durch die Kette "hoch" bis zum Root-Zertifikat.
  
-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:shibidp:prepare-http#vhost-konfiguration|IdP-Vorarbeiten: Webserver]] (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 176: Zeile 272:
 $ openssl s_client -connect idp.domain.tld:443 $ openssl s_client -connect idp.domain.tld:443
 </code> </code>
-Unten sehen als Beispiel die Antwort des Webservers von dfn.de. Alternativ können Sie externe Dienste wie z.B. die Website von [[https://www.ssllabs.com/ssltest/|SSLLabs]] verwenden.+Unten sehen als Beispiel die Antwort des Webservers von wayf.aai.dfn.de. Alternativ können Sie externe Dienste wie z.B. die Website von [[https://www.ssllabs.com/ssltest/|SSLLabs]] verwenden.
  
 <code> <code>
-$ openssl s_client -connect dfn.de:443+$ openssl s_client -connect wayf.aai.dfn.de:443
 CONNECTED(00000003) CONNECTED(00000003)
 depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2 depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
Zeile 187: Zeile 283:
 depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
 verify return:1 verify return:1
-depth=0 C = DE, ST = Berlin, L = Berlin, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = Geschaeftsstelle, CN = cloud.dfn.de+depth=0 C = DE, ST = Berlin, L = Berlin, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., CN = wayf.aai.dfn.de
 verify return:1 verify return:1
 --- ---
 Certificate chain Certificate chain
- 0 s:/C=DE/ST=Berlin/L=Berlin/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=Geschaeftsstelle/CN=cloud.dfn.de + 0 s:C = DEST = BerlinL = BerlinO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.CN = wayf.aai.dfn.de 
-   i:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA +   i:C = DEO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.OU = DFN-PKICN = DFN-Verein Global Issuing CA 
- 1 s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA +   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 
-   i:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2 +   v:NotBefore: Aug 17 09:11:20 2022 GMT; NotAfter: Sep 17 09:11:20 2023 GMT 
- 2 s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2 + 1 s:C = DEO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.OU = DFN-PKICN = DFN-Verein Global Issuing CA 
-   i:/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2+   i:C = DEO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.OU = DFN-PKICN = DFN-Verein Certification Authority 2 
 +   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 
 +   v:NotBefore: May 24 11:38:40 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT 
 + 2 s:C = DEO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.OU = DFN-PKICN = DFN-Verein Certification Authority 2 
 +   i:C = DEO = T-Systems Enterprise Services GmbHOU = T-Systems Trust CenterCN = T-TeleSec GlobalRoot Class 2 
 +   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 
 +   v:NotBefore: Feb 22 13:38:22 2016 GMT; NotAfter: Feb 22 23:59:59 2031 GMT
 --- ---
 Server certificate Server certificate
 -----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
-MIILADCCCeigAwIBAgIMH1sBXceqcYtKUpghMA0GCSqGSIb3DQEBCwUAMIGNMQsw+MIII9jCCB96gAwIBAgIMJxwuQghQ6vPgo0CGMA0GCSqGSIb3DQEBCwUAMIGNMQsw
 CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVz CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVz
 IERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4t IERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4t
-UEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE4 +UEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTIy 
-MDcwMzE0MTAyNloXDTIwMTAwNTE0MTAyNlowgagxCzAJBgNVBAYTAkRFMQ8wDQYD+MDgxNzA5MTEyMFoXDTIzMDkxNzA5MTEyMFowgZAxCzAJBgNVBAYTAkRFMQ8wDQYD
 VQQIDAZCZXJsaW4xDzANBgNVBAcMBkJlcmxpbjFFMEMGA1UECgw8VmVyZWluIHp1 VQQIDAZCZXJsaW4xDzANBgNVBAcMBkJlcmxpbjFFMEMGA1UECgw8VmVyZWluIHp1
 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu
-IFYuMRkwFwYDVQQLDBBHZXNjaGFlZnRzc3RlbGxlMRUwEwYDVQQDDAxjbG91ZC5k +IFYuMRgwFgYDVQQDDA93YXlmLmFhaS5kZm4uZGUwggIiMA0GCSqGSIb3DQEBAQUA 
-Zm4uZGUwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDa+P1wLGUrtzxK +A4ICDwAwggIKAoICAQDTgelyxRfx9V5DF5tNGrWEud9NAKFLJ6AtT2sH9k+9hIUb 
-Rdk8tD62eqjjVBoM1jfNVuajbVpj4DfiYMOwiejSZ0ZV5Yh/KHUR8qe5T/wjNioR +LQq2JsX9u8FpxMb8aE/g8aFmDkqqYqHAfkSW5Z8KvV++YS+TvJppBOQnXKx8JbIM 
-MsbfycSL2BP2U0t6VwEQDdU9nTHMI7tZIUS9uSHEWRkggOrmR/THriocz1ozqdpg +OPi/PZblPerLXooBd30akjA3f+9PEX5Hb8ufl7p4JBPo1hJ8LE6tZi0aqoRElNJj 
-VH1opFWFUs/uWhZChHdBUlcRCfdhlb+zf8Si3H6os0nHY+/XgBMG9sv2nhAVafUY +me0iiu7eboF6AVyH0vYSC9NQs1dbJ7GnS4dfagYjWMquqmJnwvYIWCtCkNypsXeZ 
-vcbpKdzdhaZVdgLlf6ZWkdGqGdfeztUOjzh10S7tkwNJBM/9gJQLbCfh+aifOhOk +MbEYmDGuI+K2+74j4p8gr2Y9odOK/Tx544R0VeYaMyl9xdje2eT78PScMl/0uHKF 
-AqD3EMNk5SaXHsWohOYDO72SdlxwN+4O14t3LatfMv5PGQ9E++pUsNnauT6GuxEq +sR7rz9sVFOeCv5LxWAr+drzRMGZRaLPalJWGulhVgCO9y0/9FJ7+mw/Bx8fbIzWi 
-VJyz3vr284FRcw8W7R1bExqF1ICfi9E7THwwvDYeZue2tl8Ki6f5ZP83t9pJdVuj +4R6Pie5Cj2Uo8LtMScCnFnj6kooZNTKetC+/zUeYxPpCpTJB3vtKuoImwY+BY9Fa 
-JxrHRwRxpY5vdFSjrU+xWj7/wiWShAM3AsIhIDgdV+Y9CoxLv1yYWxOmIP9E1iZM +HAqlD30LbRc16ULxI67+NH/pFbKfwlNVYp5X/wSN1UuU02BRLHvAeEcxuNlG50Mj 
-kL8Ama38MDblJMoJPhE7Jr6o17mrTAr993/3TvIKGHx2kMEEEyoD/wdFjQPU0mYl +OI4etFfkI443cXnTB9EGkdAS/P6aOoh3A2BhtXRFkQ5udbNYe2SCRXpZ+m+4XOIy 
-JWM4bmdISLI73wkf8UTvnYR/7VERRXNUZG+gGqek51ax4CLrS/LGoj3mvIIIPjjm +ZEzpvB0d3L+nKKjJ5qJVnCcOqWNb8wn2INtxSpFU7Vdcm16zeXsRh7SjcYQqdeh6 
-A+0Bwzwaa+jHl1nrCtbVQUnc6F2qn8BsviqbWstA1/RT7VMRq9pCq0VNwxSL3cyT +v761ePDMy3ERYyyrtKJh7Lp+YD1Jjw100X0axMwUb/oz41KjA8qTvRkn5YSIZwID 
-PwK0LFnh5FVOQyXy27v6xMpqnD4E0wIDAQABo4IGQTCCBj0wWQYDVR0gBFIwUDAI +AQABo4IETzCCBEswVwYDVR0gBFAwTjAIBgZngQwBAgIwDQYLKwYBBAGBrSGCLB4w 
-BgZngQwBAgIwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDARBg8rBgEE +DwYNKwYBBAGBrSGCLAEBBDAQBg4rBgEEAYGtIYIsAQEECjAQBg4rBgEEAYGtIYIs 
-AYGtIYIsAQEEAwgwEQYPKwYBBAGBrSGCLAIBBAMIMAkGA1UdEwQCMAAwDgYDVR0P +AgEECjAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEF 
-AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBQ26+9hXeqO +BQcDATAdBgNVHQ4EFgQUrrmPRRWUYepArAkbkrf8yvHli9wwHwYDVR0jBBgwFoAU 
-HzSRjAWBkkRU380gVDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAp +azqYi/nyU4na4K2yMh4JH+iqO3QwGgYDVR0RBBMwEYIPd2F5Zi5hYWkuZGZuLmRl 
-BgNVHREEIjAgghB3d3cuY2xvdWQuZGZuLmRlggxjbG91ZC5kZm4uZGUwgY0GA1Ud +MIGNBgNVHR8EgYUwgYIwP6A9oDuGOWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZu 
-HwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xv +LWNhLWdsb2JhbC1nMi9wdWIvY3JsL2NhY3JsLmNybDA/oD2gO4Y5aHR0cDovL2Nk 
-YmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu +cDIucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3Js 
-ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsG +MIHbBggrBgEFBQcBAQSBzjCByzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNh 
-AQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRl +LmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEkGCCsGAQUFBzAChj1odHRwOi8vY2Rw 
-L09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5k +MS5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NhY2VydC9jYWNlcnQu 
-Zm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYI +Y3J0MEkGCCsGAQUFBzAChj1odHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1n 
-KwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1n +bG9iYWwtZzIvcHViL2NhY2VydC9jYWNlcnQuY3J0MIIB9AYKKwYBBAHWeQIEAgSC 
-Mi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwggPVBgorBgEEAdZ5AgQCBIIDxQSCA8ED +AeQEggHgAd4AdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yCigAAAYKr 
-vwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABZGB6+GgAAAQD +EmbRAAAEAwBHMEUCIQDSmTwCWlCZATCfLURkGOxyR6pgKvj4d+TlKaMPXifttQIg 
-AEcwRQIgd3fkPk9o74LcUBwTHWvxvDX+35MBVGxA2jlWAw0jWukCIQCVzbfAhRKW +JOOE+3NXWghkYUJ36/Q+vSbxeRlS5FACic+kyzbAyQUAdQDoPtDaPvUGNTLnVyi8 
-9xj9kkeSrdllFa91l/y4FkOoYuu6DdT+KwB2AO5Lvbd1zmC64UJpH6vhnmajD35f +iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYKrEmhKAAAEAwBGMEQCIDHPHuRKGYvrzd69 
-sHLYgwDEe4l6qP3LAAABZGB6+GoAAAQDAEcwRQIhANvki+irHTEFedCKATceIstB +GBjuuuPfW3PGKOvY5yPd47ulHifCAiAfmBQHB5LIex3DO17m3aQlT+cgV01eLykK 
-cOg92i2BnZZ2gsqDvBZkAiAo2fCCAVVhNsyCrjeAYQXR+5WoeICO1hVDzO82oNb7 +EjF1mtq9qwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABgqsS 
-6wB1AFWB1MIWkDYBSuoLm1c8U/DA5Dh4cCUIFy+jqh0HE9MMAAABZGB6+LoAAAQD +ZMUAAAQDAEcwRQIhAJ3/1gN+37V04DsHihKJH0Ireh04yaOHx3EWnqLXsaGMAiBy 
-AEYwRAIgP0Q4ASg+6/5JC1htaQM9yD7SQh77mrwUvC38HZgZlOsCIDiWF+hENcnT +8/C02kJgI5SLeFlJZghoIIT2rqy/iu8M8v+F0Cnq2wB1AFWB1MIWkDYBSuoLm1c8 
-scbdWGd1I7aQhKXcWIQ/9XCY/Inh/D6zAHcAqucLfzy41WbIbC8Wl5yfRF9pqw60 +U/DA5Dh4cCUIFy+jqh0HE9MMAAABgqsSZTQAAAQDAEYwRAIgDY0Wn4W8l8W7Jw8T 
-U1WJsvd6AwEE880AAAFkYHr3iwAABAMASDBGAiEA6e4Sbrb9UH7hJMSbmB7YPsl8 +cy8rYjYCDc8j/opI+EsDK8+Q4OMCICGxPKaWwV04+7QOh5bdi0vNgm38V9RHP9F/ 
-ANyLI+ymp5zfrz6LteYCIQCmg1hM2yeZGESX7fGCJLohoNLj5ahCJCNazXTyNPQW +ps1wheNyMA0GCSqGSIb3DQEBCwUAA4IBAQBsn0WeEePbkHi0/RRCzFS8HDg4AIXV 
-GAB2ALvZ37wfinG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaOHtGFAAABZGB6+qoAAAQD +nk7R3x0XsgnHFpMJEM2mRJlMJrjYNjYa/X6ynsXg78yGqRvPhdqRX1oqUI1lDaLa 
-AEcwRQIhAKwv448AaBJTi+/Vz3X7fd0jj3xnWh/nD8oryywCTpW3AiAl8XROUTBP +Znj9+ZMfcfcTaDL74yE0jTbPGz4ayBA7dJJ9w2kSKwF0Mc0VLYNfuekSmqQJ1i4G 
-vTMdhuzwA507K/APz8/Y63O7nZocxaw11QB2AF6nc/nfVsDntTZIfdBJ4DJ6kZoM +T1Z6ThTm3gNdv5tOnhImwOVYT62BwyzY6/wB4dPo32R9hdQjMETh9oREQ4NyKXPw 
-hKESEoQYdZaBcUVYAAABZGB6+1wAAAQDAEcwRQIgDsXtQFLwZyY0r9wiSiJzavqC +nrJ8a6vsyPKkyDjTh88AdxAdlozqXQrYC8/hGsbQcrdbSHxXuYAWF8ErW4HuZ+PZ 
-06XaTi46GccQu0S+zLQCIQCUZWgZPVq/lQHuaqEvAselE3diktVqFoeQMCI9xWuK +jiH9LG5qUw6EIvaYgiuxm8HVU4NOvF2cqwbtLfft1klxpqywN2jTIJEy
-bAB1AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABZGB6+v0AAAQD +
-AEYwRAIgZLf0wwR8C5ZHxC7ulDIELpD9HH1osZnWHifnNl3pm+gCIEH6Gaua3Ajw +
-A3UKVZIyCcHvz9WZcxDjeCSdKwnp7l7SAHYAsh4FzIuizYogTodm+Su5iiUgZ2va +
-+nDnsklTLe+LkF4AAAFkYHr50QAABAMARzBFAiEA/BXqVMfACv8Qw4WCyHMqLkK4 +
-fcZDVvTeKT1tGGVdSOYCICjbxC1/Da5WUmOT8qegrULrn+S3L3zEG9z/ClYZnvz7 +
-MA0GCSqGSIb3DQEBCwUAA4IBAQA89lw9hf3GUonrM10rvyEY3LmnrCcopSaPmmZ2 +
-FUkXLjDvRLY5ZDz3QCxdB5Hpvd3TFquVw4c3txpzy+lK6eUFEOd8oueyjiFKr8Up +
-a1zMbuIIi/8/+gYhvgAo1Yl++Ey4gLXLq5jg7qLvMoTo/FLHmFyB7ShdyTNvNqH+ +
-WG1k2UmmZGU6M9/SrathKRBS8zXMPHM8Pi4P8O+30Q7lYxVWK8+BoM8nGlp8AfSl +
-jipzpp8akIAhs1KnXFEg93Lz+13hrKciPTQg+RPQEYBnLi6+m49VbjYXzssgbAg/ +
-4wvpsOXAr0oxEHrg1NBax0xdcWQwdX2guinJ1l3h0X9AwZAa+
 -----END CERTIFICATE----- -----END CERTIFICATE-----
-subject=/C=DE/ST=Berlin/L=Berlin/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=Geschaeftsstelle/CN=cloud.dfn.de +subject=C = DEST = BerlinL = BerlinO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.CN = wayf.aai.dfn.de 
-issuer=/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA+issuer=C = DEO = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.OU = DFN-PKICN = DFN-Verein Global Issuing CA
 --- ---
 No client certificate CA names sent No client certificate CA names sent
-Peer signing digest: SHA512 +Peer signing digest: SHA256 
-Server Temp Key: DH4096 bits+Peer signature type: RSA-PSS 
 +Server Temp Key: X25519253 bits
 --- ---
-SSL handshake has read 7480 bytes and written 750 bytes+SSL handshake has read 5882 bytes and written 397 bytes
 Verification: OK Verification: OK
 --- ---
-New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384+New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
 Server public key is 4096 bit Server public key is 4096 bit
-Secure Renegotiation IS supported+Secure Renegotiation IS NOT supported
 Compression: NONE Compression: NONE
 Expansion: NONE Expansion: NONE
 No ALPN negotiated No ALPN negotiated
 +Early data was not sent
 +Verify return code: 0 (ok)
 +---
 +---
 +Post-Handshake New Session Ticket arrived:
 SSL-Session: SSL-Session:
-    Protocol  : TLSv1.2 +    Protocol  : TLSv1.3 
-    Cipher    : DHE-RSA-AES256-GCM-SHA384 +    Cipher    : TLS_AES_256_GCM_SHA384 
-    Session-ID: F552550A1AE3E144892CD0A9F109E1E8987F318E57F448016429819D88B31FDC+    Session-ID: 284526F924E23FFDDA8286A63996DBB7EECBEBBCADAE3EAEB6DCD94A97ECCC64
     Session-ID-ctx:      Session-ID-ctx: 
-    Master-Key85678E83DA6DB1CCE48727EAE8A81E3F0AFCFB9CFADFB87A1D9A37D74FD19FA395DDFE31E38044D265674F97AC7B8922+    Resumption PSK57A5B30716BB320C1D53CAF09D667C1D08AE179DB450063ED7305CBBD15B29C49AAFC7C8E381640717BA7FF6F3789F99
     PSK identity: None     PSK identity: None
     PSK identity hint: None     PSK identity hint: None
     SRP username: None     SRP username: None
-    TLS session ticket lifetime hint: 300 (seconds)+    TLS session ticket lifetime hint: 7200 (seconds)
     TLS session ticket:     TLS session ticket:
-    0000 - d0 92 ff 13 a3 e8 cd 3f-a3 0f 55 57 47 fa d4 9d   .......?..UWG... +    0000 - 83 6b 3a c5 50 ec c5 be-ab d4 49 ed 95 80 48 21   .k:.P.....I...H! 
-    0010 - cf 72 55 cb 48 3c b4 67-26 10 37 8d db 1e 40 f7   .rU.H<.g&.7...@. +    0010 - 4d c7 ff 8f 8d 0c cb 63-a4 1d 11 9f 7b 86 0c 65   M......c....{..e
-    0020 - 4a 6f cc 57 6c 02 74 6d-f9 d7 a6 8c d0 2a d7 f9   Jo.Wl.tm.....*.. +
-    0030 - 50 67 6f 4a 63 44 73 64-66 d9 86 0f 19 fa 68 fe   PgoJcDsdf.....h. +
-    0040 - 7c 67 7e 9c 18 13 07 26-84 e9 6f 60 2a a5 5c 70   |g~....&..o`*.\p +
-    0050 - 70 6d e8 a5 56 11 67 2d-3c 5d 44 b6 5b ef 06 12   pm..V.g-<]D.[... +
-    0060 - 27 dd 0d 10 4b 0a c1 04-98 2b 1b 03 c5 e0 7b 25   '...K....+....{% +
-    0070 - 0e b1 3c 7c 05 68 48 2a-32 80 aa 69 92 bd 7f 52   ..<|.hH*2..i...R +
-    0080 - 4d 1a 81 f0 8b 2a 2c c3-00 12 13 c3 65 7a df 37   M....*,.....ez.7 +
-    0090 - 13 4b 22 03 70 a3 56 5d-ba 16 58 0e 15 cf 07 e5   .K".p.V]..X..... +
-    00a0 - 2c f8 69 70 52 de e9 4e-4e cc 87 cd 0d 2f a9 56   ,.ipR..NN..../.V +
-    00b0 - 2b 92 2d 6f 10 0b 44 7a-81 0d d4 5f 7a 47 7e 0d   +.-o..Dz..._zG~.+
  
-    Start Time: 1555333603+    Start Time: 1673270213
     Timeout   : 7200 (sec)     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)     Verify return code: 0 (ok)
     Extended master secret: no     Extended master secret: no
 +    Max Early Data: 0
 --- ---
-read:errno=0+read R BLOCK 
 +--- 
 +Post-Handshake New Session Ticket arrived: 
 +SSL-Session: 
 +    Protocol  : TLSv1.3 
 +    Cipher    : TLS_AES_256_GCM_SHA384 
 +    Session-ID: F0E581A89E7A0103398D4984082F5967E5B26079DD86D41499719A72237B3A2D 
 +    Session-ID-ctx:  
 +    Resumption PSK: 0EED21E37A6873AC74CEE4F17DFD953850966D0AC73CD2B76FDA0C8995052DB66D489DCD07E464E492755BC8212ACD3B 
 +    PSK identity: None 
 +    PSK identity hint: None 
 +    SRP username: None 
 +    TLS session ticket lifetime hint: 7200 (seconds) 
 +    TLS session ticket: 
 +    0000 - a8 d0 1b 2e ca e6 70 cb-61 72 45 45 b7 e4 76 3e   ......p.arEE..v> 
 +    0010 - f7 59 ad 02 e7 8a 50 39-11 a7 81 8a 78 36 6b d6   .Y....P9....x6k. 
 + 
 +    Start Time: 1673270213 
 +    Timeout   : 7200 (sec) 
 +    Verify return code: 0 (ok) 
 +    Extended master secret: no 
 +    Max Early Data: 0 
 +--- 
 +read R BLOCK
 </code> </code>
-**Nächster Schritt:** [[de:functionaltest|Funktionstests]]+
  • Zuletzt geändert: vor 5 Jahren