Dies ist eine alte Version des Dokuments!


Zertifikate

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.

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!

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

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.

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.

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-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!
Eine gute Anleitung zum Betrieb einer eigenen CA findet sich hier.
Zu berücksichtigende Parameter:

  • Root Private Key: RSA, 4096 Bit
  • Gültigkeit des Root Zertifikats: 20 Jahre (empfohlen)
  • Gültigkeit der ausgestellten Zertifikate: max. 39 Monate
  • Key-Länge der ausgestellten Zertifikate: mindestens 3072 Bit
  • Signatur-Algorithmus: sha256
  • Der CN des ausgestellten Zertifikats entspricht dem FQDN des jeweiligen IdP-/SP-Hosts

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

  • Schicken Sie uns das Zertifikat in einer via S/MIME signierten E-Mail an hotline@aai.dfn.de. Die Zertifizierungsstelle, die das S/MIME-Zertifikat ausgestellt hat, muss eine etablierte CA sein. Für uns ist es am einfachsten, wenn Sie den Inhalt der .pem-Datei direkt in die signierte E-Mail hineinkopieren.
  • Alternativ können Sie uns das Zertifikat auf Ihrem Webserver zum Download via https bereitstellen (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.
  • Sollte keine der genannten Möglichkeiten infrage kommen, kontaktieren Sie uns bitte direkt (+49 30 884299-9124, hotline@aai.dfn.de).

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.

Bitte nicht verwenden

Wildcard-Zertifikate

Die Nutzung von Wildcards in Zertifikaten ist nur in begründeten Ausnahmefällen gestattet.

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: Funktionstests

Vielen Dank an die Schweizer Kolleg*innen für die ausführliche englischsprachige 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:

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.

Schritt 2: Beschaffung/Generierung eines neuen Zertifikates

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

  • Erstellen Sie einen privaten Schlüssel:
    user@host:~$ openssl genrsa -out idp.example.org.key.pem 4096
  • Erstellen Sie einen Zertifikatsantrag (Certificate Signing Request, csr):
    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 []:
  • 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.

-- Sonstige Zertifizierungsstellen bzw. CAs

Konsultieren Sie hierzu die Dokumentation des jeweiligen Anbieters bzw. dessen Kundensupport.

-- Selbst-signierte Zertifikate

Selbst-signierte Zertifikate sind ausschließlich für die SAML-basierte Kommunikation geeignet! Sowohl Shibboleth IdP als auch Shibboleth SP werden mit einem keygen Skript ausgeliefert, mit dessen Hilfe sich selbst-signierte Zertifikate erstellen lassen. Ansonsten ist dies z.B. auch mit OpenSSL möglich. Wichtig hierbei ist dass die Laufzeit 39 Monate nicht übersteigt und die Keylänge mindestens 3072 Bit beträgt (Voreinstellung bei Shibboleth). Siehe hierzu einstweilen die Dokumentation von SWITCH:

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. (Unten auf dieser Seite ist erklärt, wie Sie die komplette Zertifikatskette ausliefern.)
  • Starten Sie den Webserver neu.

Schritt 4 beim IdP: Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen

24 Stunden Wartezeit

Veröffentlichen Sie das neue Zertifikat mindestens 24 Stunden vor dem eigentlichen Tausch zusätzlich zu dem alten Zertifikat in den Föderationsmetadaten!
  • 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 5 beim IdP: Zertifikate für SAML-Kommunikation tauschen

  • 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.
    idp.signing.key= /etc/ssl/private/idp.example.org.key.pem
    idp.signing.cert= /etc/ssl/localcerts/idp.example.org.crt.pem
    idp.encryption.key= /etc/ssl/private/idp.example.org.key.pem
    idp.encryption.cert= /etc/ssl/localcerts/idp.example.org.crt.pem
  • 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

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.
    # 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
  • 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:
    root@sp:~ # systemctl restart shibd
  • 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.

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.

Schritt 5 beim SP: Zertifikate für SAML-Kommunikation tauschen

  • 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" 
                                certificate="/etc/ssl/localcerts/2019-sp.example.org.crt.pem"/>        
            <!-- 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:
    root@sp:~ # systemctl restart shibd
  • 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:
        <CredentialResolver type="Chaining">
            <!-- 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"/>        
            <!-- 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:
    root@sp:~ # systemctl restart shibd

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-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
  • Zuletzt geändert: vor 3 Jahren