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 Metadatenverwaltung eingetragen werden.

Generell gilt: Entities mit ungültigen, d.h. abgelaufenen oder zurückgezogenen Zertifikaten werden automatisch aus der DFN-AAI Produktivföderation entfernt!

Siehe unter Vorbereitung: Zertifikate

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. Shibboleth SP

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.

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.

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 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.
• Wenn Sie keine Möglichkeit haben, uns 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). So lassen Sie sich die Fingerprints ausgeben:

$ openssl x509 -noout -fingerprint -sha1 -in self-signed-server-cert.pem
$ openssl x509 -noout -fingerprint -sha256 -in self-signed-server-cert.pem

• Sie können uns das Zertifikat auch in einer via S/MIME signierten E-Mail an hotline@aai.dfn.de schicken. Die Zertifizierungsstelle, die das S/MIME-Zertifikat ausgestellt hat, muss eine etablierte CA sein.

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.

Nächster Schritt: Funktionstests

Für einen Zertifikatstausch am SP, sehen Sie bitte vorerst in der Dokumentation unserer Schweizer Kolleg*innen nach.

Wenn Sie ablaufende Zertifikate am IdP austauschen müssen, gehen Sie wie folgt vor:

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.

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 Zusammenfassung der wichtigsten OpenSSL-Befehle und ausführliche FAQ rund um Zertifikate. Das folgende Vorgehen müssen Sie möglicherweise Ihre Umgebung anpassen.

Geheimen Schlüssel erstellen:

user@host:~$ openssl genrsa -out idp.example.org.key.pem 4096

Certificate Signing Request erstellen

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 []:

Diesen csr im .pem-Format geben Sie bei der DFN-PKI ein. Wählen Sie das Profil „Shibboleth-IdP/-SP“.

• Ersetzen Sie die alten, in der Webserverkonfiguration eingetragenen Dateien durch das neue Zertifikat, den privaten Schlüssel und die Zertifikatskette.
• Starten Sie den Webserver neu.

• 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.
• 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.

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:

      <CredentialResolver type="Chaining">
          <!-- noch aktives altes Zertifikat -->
          <CredentialResolver type="File"
                              key="/etc/ssl/private/2016-sp.example.org.key.pem" 
                              certificate="/etc/ssl/localcerts/2016-sp.example.org.crt.pem"/>
          <!-- zusätzliches neues Zertifikat -->        
          <CredentialResolver type="File"
                              key="/etc/ssl/private/2019-sp.example.org.key.pem" 
                              certificate="/etc/ssl/localcerts/2019-sp.example.org.crt.pem"/>
      </CredentialResolver>

• Prüfen Sie die SP-Konfiguration:

  root@sp # shibd -tc /etc/shibboleth/shibboleth2.xml
  overall configuration is loadable, check console for non-fatal problems

• Starten Sie den Dienst shibd neu:

  systemctl restart shibd

• 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.
• 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:

      <CredentialResolver type="Chaining">
          <!-- neues Zertifikat -->    
          <CredentialResolver type="File"
                              key="/etc/ssl/private/2019-sp.example.org.key.pem.neu" 
                              certificate="/etc/ssl/localcerts/2019-sp.example.org.crt.pem.neu"/>        
          <!-- altes Zertifikat -->                            
          <CredentialResolver type="File"
                              key="/etc/ssl/private/2016-sp.example.org.key.pem" 
                              certificate="/etc/ssl/localcerts/2016-sp.example.org.crt.pem"/>
      </CredentialResolver>

• Prüfen Sie die SP-Konfiguration:

  root@sp # shibd -tc /etc/shibboleth/shibboleth2.xml
  overall configuration is loadable, check console for non-fatal problems

• Starten Sie den Dienst shibd neu:

  systemctl restart shibd

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).

• 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:
  • Serverzertifikat
  • das/die Zwischenzertifikat(e) (Intermediate)
  • 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.

Ob die einzelnen Zertifikate im chain file wirklich zusammenpassen, können Sie mit OpenSSL überprüfen:

• Prüfen Sie den Issuer-Hash des Server-Zertifikates, also die Prüfsumme des Ausstellers:

  $ openssl x509 -in idp.domain.tld.pem -noout -issuer_hash
  6ded7378

• Prüfen Sie den Hash des ersten Intermediate-Zertifikates. Er sollte dem Issuer-Hash des Server-Zertifikates entsprechen:

  $ openssl x509 -in intermediate1.pem -noout -hash
  6ded7378

• Prüfen Sie wiederum den Issuer-Hash des ersten Intermediate-Zertifikates:

  $ openssl x509 -in intermediate1.pem -noout -issuer_hash
  6107e209

• 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 IdP 3.x Vorarbeiten: HTTP-Server (IdP), bzw. Shibboleth SP > Konfigurationsbeispiel (SP).

Wenn Sie Ihre Zertifikatskette hinlegt, die Webserver-Konfiguration angepasst und aktiviert haben, können Sie sie mit OpenSSL zur Überprüfung abfragen:

$ openssl s_client -connect idp.domain.tld:443

Unten sehen als Beispiel die Antwort des Webservers von dfn.de. Alternativ können Sie externe Dienste wie z.B. die Website von SSLLabs verwenden.

$ openssl s_client -connect dfn.de:443
CONNECTED(00000003)
depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
verify return:1
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
depth=0 C = DE, ST = Berlin, L = Berlin, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = Geschaeftsstelle, CN = cloud.dfn.de
verify return:1
---
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
   i:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=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
   i:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2
 2 s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2
   i:/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIILADCCCeigAwIBAgIMH1sBXceqcYtKUpghMA0GCSqGSIb3DQEBCwUAMIGNMQsw
CQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVz
IERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4t
UEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE4
MDcwMzE0MTAyNloXDTIwMTAwNTE0MTAyNlowgagxCzAJBgNVBAYTAkRFMQ8wDQYD
VQQIDAZCZXJsaW4xDzANBgNVBAcMBkJlcmxpbjFFMEMGA1UECgw8VmVyZWluIHp1
ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu
IFYuMRkwFwYDVQQLDBBHZXNjaGFlZnRzc3RlbGxlMRUwEwYDVQQDDAxjbG91ZC5k
Zm4uZGUwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDa+P1wLGUrtzxK
Rdk8tD62eqjjVBoM1jfNVuajbVpj4DfiYMOwiejSZ0ZV5Yh/KHUR8qe5T/wjNioR
MsbfycSL2BP2U0t6VwEQDdU9nTHMI7tZIUS9uSHEWRkggOrmR/THriocz1ozqdpg
VH1opFWFUs/uWhZChHdBUlcRCfdhlb+zf8Si3H6os0nHY+/XgBMG9sv2nhAVafUY
vcbpKdzdhaZVdgLlf6ZWkdGqGdfeztUOjzh10S7tkwNJBM/9gJQLbCfh+aifOhOk
AqD3EMNk5SaXHsWohOYDO72SdlxwN+4O14t3LatfMv5PGQ9E++pUsNnauT6GuxEq
VJyz3vr284FRcw8W7R1bExqF1ICfi9E7THwwvDYeZue2tl8Ki6f5ZP83t9pJdVuj
JxrHRwRxpY5vdFSjrU+xWj7/wiWShAM3AsIhIDgdV+Y9CoxLv1yYWxOmIP9E1iZM
kL8Ama38MDblJMoJPhE7Jr6o17mrTAr993/3TvIKGHx2kMEEEyoD/wdFjQPU0mYl
JWM4bmdISLI73wkf8UTvnYR/7VERRXNUZG+gGqek51ax4CLrS/LGoj3mvIIIPjjm
A+0Bwzwaa+jHl1nrCtbVQUnc6F2qn8BsviqbWstA1/RT7VMRq9pCq0VNwxSL3cyT
PwK0LFnh5FVOQyXy27v6xMpqnD4E0wIDAQABo4IGQTCCBj0wWQYDVR0gBFIwUDAI
BgZngQwBAgIwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDARBg8rBgEE
AYGtIYIsAQEEAwgwEQYPKwYBBAGBrSGCLAIBBAMIMAkGA1UdEwQCMAAwDgYDVR0P
AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBQ26+9hXeqO
HzSRjAWBkkRU380gVDAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAp
BgNVHREEIjAgghB3d3cuY2xvdWQuZGZuLmRlggxjbG91ZC5kZm4uZGUwgY0GA1Ud
HwSBhTCBgjA/oD2gO4Y5aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xv
YmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+gPaA7hjlodHRwOi8vY2RwMi5wY2Eu
ZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNybC5jcmwwgdsGCCsG
AQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRl
L09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5k
Zm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYI
KwYBBQUHMAKGPWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1n
Mi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwggPVBgorBgEEAdZ5AgQCBIIDxQSCA8ED
vwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABZGB6+GgAAAQD
AEcwRQIgd3fkPk9o74LcUBwTHWvxvDX+35MBVGxA2jlWAw0jWukCIQCVzbfAhRKW
9xj9kkeSrdllFa91l/y4FkOoYuu6DdT+KwB2AO5Lvbd1zmC64UJpH6vhnmajD35f
sHLYgwDEe4l6qP3LAAABZGB6+GoAAAQDAEcwRQIhANvki+irHTEFedCKATceIstB
cOg92i2BnZZ2gsqDvBZkAiAo2fCCAVVhNsyCrjeAYQXR+5WoeICO1hVDzO82oNb7
6wB1AFWB1MIWkDYBSuoLm1c8U/DA5Dh4cCUIFy+jqh0HE9MMAAABZGB6+LoAAAQD
AEYwRAIgP0Q4ASg+6/5JC1htaQM9yD7SQh77mrwUvC38HZgZlOsCIDiWF+hENcnT
scbdWGd1I7aQhKXcWIQ/9XCY/Inh/D6zAHcAqucLfzy41WbIbC8Wl5yfRF9pqw60
U1WJsvd6AwEE880AAAFkYHr3iwAABAMASDBGAiEA6e4Sbrb9UH7hJMSbmB7YPsl8
ANyLI+ymp5zfrz6LteYCIQCmg1hM2yeZGESX7fGCJLohoNLj5ahCJCNazXTyNPQW
GAB2ALvZ37wfinG1k5Qjl6qSe0c4V5UKq1LoGpCWZDaOHtGFAAABZGB6+qoAAAQD
AEcwRQIhAKwv448AaBJTi+/Vz3X7fd0jj3xnWh/nD8oryywCTpW3AiAl8XROUTBP
vTMdhuzwA507K/APz8/Y63O7nZocxaw11QB2AF6nc/nfVsDntTZIfdBJ4DJ6kZoM
hKESEoQYdZaBcUVYAAABZGB6+1wAAAQDAEcwRQIgDsXtQFLwZyY0r9wiSiJzavqC
06XaTi46GccQu0S+zLQCIQCUZWgZPVq/lQHuaqEvAselE3diktVqFoeQMCI9xWuK
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-----
subject=/C=DE/ST=Berlin/L=Berlin/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=Geschaeftsstelle/CN=cloud.dfn.de
issuer=/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 4096 bits
---
SSL handshake has read 7480 bytes and written 750 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: F552550A1AE3E144892CD0A9F109E1E8987F318E57F448016429819D88B31FDC
    Session-ID-ctx: 
    Master-Key: 85678E83DA6DB1CCE48727EAE8A81E3F0AFCFB9CFADFB87A1D9A37D74FD19FA395DDFE31E38044D265674F97AC7B8922
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - d0 92 ff 13 a3 e8 cd 3f-a3 0f 55 57 47 fa d4 9d   .......?..UWG...
    0010 - cf 72 55 cb 48 3c b4 67-26 10 37 8d db 1e 40 f7   .rU.H<.g&.7...@.
    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
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
read:errno=0

Nächster Schritt: Funktionstests