Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:certificates [2023/01/23 15:59] – [2. Beschaffung/Generierung eines neuen Zertifikates] oben bereits erwähnte Infos entfernt Silke Meyer | de:certificates [2023/02/01 15:53] – [Informationen für Service Provider] Wolfgang Pempe | ||
---|---|---|---|
Zeile 32: | Zeile 32: | ||
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. | ||
</ | </ | ||
+ | | ||
+ | \\ | ||
+ | | ||
+ | === 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, | ||
+ | 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 ''" | ||
- | === Keine Wildcard-Zertifikate === | + | \\ |
- | Die Nutzung von Wildcards in Zertifikaten ist nur in begründeten Ausnahmefällen gestattet. | + | |
=== Keine Letsencrypt-Zertifikate === | === 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: | **Nächster Schritt:** [[de: | ||
Zeile 51: | Zeile 59: | ||
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. | ||
- | ==== 2. Beschaffung/ | + | ==== 2. Beschaffung eines neuen Zertifikates ==== |
siehe oben | siehe oben | ||
Zeile 134: | Zeile 142: | ||
==== 2. Beschaffung eines neuen Zertifikates ==== | ==== 2. Beschaffung eines neuen Zertifikates ==== | ||
- | === DFN-PKI === | + | siehe oben |
- | Bei Fragen zur Erstellung von privaten Schlüsseln und Zertifikatsanträgen, | + | |
- | + | ||
- | * Sie können Ihren alten privaten Schlüssel weiterverwenden, | + | |
- | user@host: | + | |
- | </ | + | |
- | * Erstellen Sie einen Zertifikatsantrag (Certificate Signing Request, csr):< | + | |
- | user@host: | + | |
- | # Sie werden Folgendes abgefragt, evtl. befüllt mit Vorgaben aus Ihrer / | + | |
- | Country Name (2 letter code) [DE]: | + | |
- | State or Province Name (full name) []: <== Bundesland | + | |
- | Locality Name (eg, city) []: <== Stadt | + | |
- | Organization Name (eg, company) []: < | + | |
- | Organizational Unit Name (eg, section) []: <== ggf. Abteilung o.ä. | + | |
- | Common Name (eg, YOUR name) []: | + | |
- | A challenge password []: | + | |
- | An optional company name []: | + | |
- | </ | + | |
- | * Geben Sie diesen Zertifikatsantrag im .pem-Format bei der DFN-PKI ein. Wählen Sie das Profil " | + | |
- | * Sie bekommen Ihr neues Zertifikat per E-Mail von der DFN-PKI. | + | |
- | + | ||
- | === Sonstige Zertifizierungsstellen bzw. CAs === | + | |
- | Konsultieren Sie hierzu die Dokumentation des [[# | + | |
- | + | ||
- | === 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 '' | + | |
- | * [[https:// | + | |
- | * [[https:// | + | |
- | * [[https:// | + | |
==== 3. Ggf. Zertifikat am Webserver tauschen ==== | ==== 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:// | * 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:// |