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 [2023/01/09 14:17] – [Überprüfung der Zertifikatskette] Silke Meyerde:certificates [2023/01/23 16:00] – [2. Beschaffung/Generierung eines neuen Zertifikates] kürzer Silke Meyer
Zeile 1: Zeile 1:
-~~NOTOC~~ 
 ====== Zertifikate ====== ====== Zertifikate ======
-{{INLINETOC 2}}+
 ===== Zertifikate für die SAML-basierte Kommunikation ===== ===== Zertifikate für die SAML-basierte Kommunikation =====
  
Zeile 16: Zeile 15:
 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 bzw. DFN-Verein Community PKI=== === Zertifikate der DFN-PKI bzw. DFN-Verein Community PKI===
 Für die SAML-basierte Kommunikation empfehlen sich **3 Jahre gültige Zertifikate aus der [[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community PKI]]**. Für die SAML-basierte Kommunikation empfehlen sich **3 Jahre gültige Zertifikate aus der [[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community 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 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 Zertifikat laden Sie in der Metadatenverwaltung hoch.
- 
-\\ 
  
 === Eigene/lokale CA === === Eigene/lokale CA ===
 Für Zertifikate aus einer eigenen/lokalen CA gelten die selben Regeln wie für selbst-signierte Zertifikate, siehe unten.  Für Zertifikate aus einer eigenen/lokalen CA gelten die selben Regeln wie für selbst-signierte Zertifikate, siehe unten. 
- 
-\\ 
  
 === 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]]. Hierbei ist darauf zu achten, dass die Laufzeit auf 3 Jahre bzw. max. 39 Monate zu setzen ist (keygen Tool: ''-y 3'', openssl: ''-days 1170'').  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 bzw. max. 39 Monate zu setzen ist (keygen Tool: ''-y 3'', openssl: ''-days 1170''). 
- 
-\\  
  
 === Zertifikate gängiger Zertifizierungsstellen === === Zertifikate gängiger Zertifizierungsstellen ===
 Alternativ können Zertifikate aus CAs genutzt werden, die in den gängigen Standardbrowsern (Google Chrome, Firefox, Microsoft Edge) vorinstalliert sind.  Alternativ können Zertifikate aus CAs genutzt werden, die in den gängigen Standardbrowsern (Google Chrome, Firefox, Microsoft Edge) vorinstalliert sind. 
- 
-\\ 
  
 <callout color="#ff9900" title="Ausnahmen"> <callout color="#ff9900" title="Ausnahmen">
Zeile 43: Zeile 33:
 </callout> </callout>
  
-\\ +=== Keine Wildcard-Zertifikate ===
- +
-=== Bitte nicht verwenden === +
- +
-== 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 ==+=== Keine Letsencrypt-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 oder solcher aus der DFN-Verein Community PKI (siehe oben). 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).
  
 **Nächster Schritt:** [[de:functionaltest|Funktionstests]] **Nächster Schritt:** [[de:functionaltest|Funktionstests]]
  
-\\ +===== Zertifikatstausch am IdP =====
- +
-==== 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 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/Generierung eines neuen Zertifikates === +===2Beschaffung eines neuen Zertifikates ==== 
-=== -- DFN-PKI === +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> 
-user@host:~$ openssl genrsa -out idp.example.org.key.pem 4096 
-</code> 
-  * Erstellen Sie einen Zertifikatsantrag (Certificate Signing Request, csr):<code> 
-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. 
  
-=== -- Sonstige Zertifizierungsstellen bzw. CAs === +==== 3. Ggf. Zertifikat am Webserver tauschen ====
-Konsultieren Sie hierzu die Dokumentation des [[#zertifikate_gaengiger_zertifizierungsstellen|jeweiligen Anbieters]] bzwdessen 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: +
-  * [[https://www.switch.ch/aai/guides/idp/certificate-rollover/|Shibboleth IdP, Step 0]] (Wichtig: Tomcat User muss Leserecht auf den private Key haben) +
-  * [[https://www.switch.ch/aai/guides/sp/certificate-rollover/|Shibboleth SP, Step 0]] +
-  * [[https://www.switch.ch/aai/support/certificates/embeddedcerts-requirements-appendix-a/|OpenSSL]] +
- +
-=== 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 [[https://doku.tid.dfn.de/de:certificates#die_ssl-zertifikatskette_auf_ihrem_webserver|komplette Zertifikatskette]] ausliefern.)   * 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 beim Zertifikatswechel des IdP: Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen ===+===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> 
 +  * Starten Sie Tomcat neu. 
 + 
 +==== 6. Zertifikat für SAML-Kommunikation in Metadatenverwaltung eintragen ====
 <callout color="#ff9900" title="24 Stunden Wartezeit"> <callout color="#ff9900" title="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!**+**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> </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.   * 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.   * 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 Zertifikatswechel des IdP: Zertifikate für SAML-Kommunikation tauschen === +==== 7. Alt und neu in der Konfiguration vertauschen ==== 
-  * 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> +<callout color="#ff9900" title="24 Stunden Wartezeit"> 
-idp.signing.key= /etc/ssl/private/idp.example.org.key.pem +**Nach diesem Schritt warten Sie bitte erneut mindestens 24 Stunden, bevor Sie weitermachen.** 
-idp.signing.cert= /etc/ssl/localcerts/idp.example.org.crt.pem +</callout> 
-idp.encryption.key= /etc/ssl/private/idp.example.org.key.pem +  * Nachdem das neue Zertifikat sich über die Metadaten herumgesprochen hat, entfernen Sie das alte Zertifikat aus den Föderationsmetadaten. 
-idp.encryption.cert= /etc/ssl/localcerts/idp.example.org.crt.pem+  * Tauschen Sie in ''conf/idp.properties'' alt und neu:<code> 
 +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 
 +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 Zertifikatswechel des 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> 
 +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>   * Legen Sie das neue Zertifikat, den privaten Schlüssel und ggf. die Zertifikatskette auf den Server. Es ist wichtig, dass der Benutzer, mit dessen Kennung der ''shibd''-Prozess läuft, die Dateien lesen kann.<code bash>
 # Benutzerkennung feststellen: # Benutzerkennung feststellen:
Zeile 154: Zeile 173:
 </callout> </callout>
  
-=== Schritt beim Zertifikatswechel des SP: Zertifikate für SAML-Kommunikation tauschen ===+===5Zertifikate 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>
Zeile 174: Zeile 193:
   * Jetzt können Sie gleich das alte Zertifikat aus den Metadaten des SP herausnehmen. **Warten** Sie dann erneut bis zu 24 Stunden (sicher ist sicher), bis sich die Änderung in der DFN-AAI bzw. in eduGAIN herumgesprochen hat.   * Jetzt können Sie gleich das alte Zertifikat aus den Metadaten des SP herausnehmen. **Warten** Sie dann erneut bis zu 24 Stunden (sicher ist sicher), bis sich die Änderung in der DFN-AAI bzw. in eduGAIN herumgesprochen hat.
  
-=== Schritt beim Zertifikatswechel des SP: Zertifikate für SAML-Kommunikation tauschen ===+===6Zertifikate für SAML-Kommunikation tauschen ====
  
   * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie es entweder löschen oder auskommentieren:<code xml>   * Entfernen Sie das alte Zertifikat aus der SP-Konfiguration, indem Sie es entweder löschen oder auskommentieren:<code xml>
Zeile 195: Zeile 214:
   * Starten Sie den Dienst ''shibd'' neu:<code bash>root@sp:~ # systemctl restart shibd</code>   * Starten Sie den Dienst ''shibd'' neu:<code bash>root@sp:~ # systemctl restart shibd</code>
  
-=== Direkt verdrahtete IdPs/SPs ===+==== Direkt verdrahtete IdPs/SPs ====
 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. 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-Zertifikatskette auf Ihrem Webserver =====
  • Zuletzt geändert: vor 4 Tagen