Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:dfnpki:tcs:servercert [2023/09/11 15:09] – angelegt Juergen Brauckmann
+++ de:dfnpki:tcs:servercert [2024/07/08 12:28] (aktuell) – [VoIP-Zertifikate für DFNFernsprechen] Wolfgang Pempe
@@ Zeile 1: / Zeile 1: @@
 ====Serverzertifikate====
@@ Zeile 12: / Zeile 11: @@
 ===Über die AAI====
-Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe  [[de:dfnpki:tcsfaq#zugriff_per_aai|Zugriff per AAI]]), können Sie ein Formular aufsetzen, über das nach AAI-Authentifizierung Serverzertifikate beantragt werden können.
+Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe  [[de:dfnpki:tcs:zugriffperaai|Zugriff per AAI]]), können Sie ein Formular aufsetzen, über das nach AAI-Authentifizierung Serverzertifikate beantragt werden können.
   - Im SCM unter ☰->Enrollment->Enrollment Forms
@@ Zeile 29: / Zeile 28: @@
          - meist "OV Multi-Domain"
          - "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird.
-     - Als "CSR Generation Method" üblicherweise den Wert "Provided by User" auswählen.
+     - Als "CSR Generation Method" üblicherweise den Wert "''Provided by User''" auswählen. Damit muss der CSR vorab erzeugt werden und dann bei Zertifikatantragstellung auf der Web-Seite hochgeladen werden.
-         - "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird.
+         - Bei Auswahl der Methode "''Browser''" wird der Schlüssel während der Zertifikatantragstellung im Browser des Antragsstellenden erzeugt. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden im Browser vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird.
      - "Automatically Approve Request" **nicht** anwählen
      - Als "Authorization Method" den Wert "IdP Assertions Mapping" auswählen. **Nicht ''none'' verwenden!**
@@ Zeile 63: / Zeile 62: @@
      - Bei den Zertifikatprofilen über das kleine "+"-Zeichen aus der Drop-Down-Liste das gewünschte Zertifikatprofil auswhlen
          - meist "OV Multi-Domain"
-     - Als "CSR Generation Method" üblicherweise den Wert "Provided by User" auswählen.
+     - Als "CSR Generation Method" üblicherweise den Wert "''Provided by User''" auswählen. Damit muss der CSR vorab erzeugt werden und dann bei Zertifikatantragstellung auf der Web-Seite hochgeladen werden.
-         - "Browser" erzeugt den Schlüssel im Browser des Antragsstellenden. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird.
+         - Bei Auswahl der Methode "''Browser''" wird der Schlüssel während der Zertifikatantragstellung im Browser des Antragsstellenden erzeugt. **Achtung**: Diese Methode erfordert eine enge zeitliche Synchronisation mit dem genehmigenden RAO/DRAO, da der Schlüssel nur temporär, sehr flüchtig beim Antragsstellenden im Browser vorliegt. Des Weiteren ist die Methode nicht ohne weiteres für Apache oder nginx geeignet, da das Zertifikat nur als PKCS12-Datei zum Download angeboten wird.
      - "Automatically Approve Request" **auf keinen Fall** anwählen.
      - Als "Authorization Method" den Wert "Access Code" auswählen. **Nicht ''none'' verwenden!**
@@ Zeile 80: / Zeile 79: @@
 ===ACME===
-Es stehen Endpunkte für das ACME-Protokoll zur Verfügung, mit denen mit Standard-Clients automatisiert Serverzertifikate bezogen werden können. Hinweise hierzu unter [[de:dfnpki:tcsfaq#acme1|ACME]]
+Es stehen Endpunkte für das ACME-Protokoll zur Verfügung, mit denen mit Standard-Clients automatisiert Serverzertifikate bezogen werden können. Hinweise hierzu unter [[de:dfnpki:tcs:servercert_acme|ACME]]
 ===REST-API für Serverzertifikate===
-Über das REST API können mit selbst erstellter Software oder Skripten Serverzertifikate erstellt werden. Hinweise hierzu unter [[de:dfnpki:tcsfaq#rest-api|REST-API]]
+Über das REST API können mit selbst erstellter Software oder Skripten Serverzertifikate erstellt werden. Hinweise hierzu unter [[de:dfnpki:tcs:restapi|REST-API]]
@@ Zeile 98: / Zeile 97: @@
 Dies gilt für alle Profile  (OV Multi-Domain, OV SSL, usw.) und alle Bezugswege (cert-manager, auch ACME).
-Wählen Sie auf keinen Fall das Zertifikatprofil ''EV Anchor'', es sei denn, Sie wollen den [[de:dfnpki:tcsfaq#extended_validation_zertifikate_ev|speziellen EV-Prozess]] starten.
+Wählen Sie auf keinen Fall das Zertifikatprofil ''EV Anchor'', es sei denn, Sie wollen den [[de:dfnpki:tcs:servercert#extended_validation_zertifikate_ev|speziellen EV-Prozess]] starten.
 **Nicht verfügbar** sind die Funktionalitäten aus den folgenden Profilen der DFN-PKI Global: ''Webserver mustStaple'', ''DomainController'' und ''Exchange Server''. Sofern für einen Exchange-Server oder Domänen-Controller //zusätzliche// Zertifikatzwecke (''extendedKeyUsage'' bzw. andere Zertifikaterweiterungen) außer ''serverAuth'' und ''clientAuth'' zwingend benötigt werden, können Sie auf die Zertifikate aus der ''[[https://www.pki.dfn.de/dfn-verein-community-pki|DFN-Verein Community PKI]]'' zurückgreifen, die allerdings ohne Browser- und Betriebssystemverankerung daherkommen.
-[[de:dfnpki:tcsfaq#ip-adressen_in_zertifikaten|IP-Adressen können in Serverzertifikate aus TCS aufgenommen werden.]]
+[[de:dfnpki:tcs:domains#ip-adressen_in_zertifikaten|IP-Adressen können in Serverzertifikate aus TCS aufgenommen werden.]]
 ====Signaturalgorithmen in Serverzertifikaten mit RSA-Schlüsseln (sha256WithRSAEncryption, sha384WithRSAEncryption)====
@@ Zeile 109: / Zeile 108: @@
 Sofern Serverzertifikate mit einen RSA-Schlüssel beantragt werden, werden diese standardmäßig mit dem Signaturalgorithmus ''sha384WithRSAEncryption'' signiert. Das betrifft u.a. das Zertifikatprofil ''OV Multi Domain''. Es gibt keine explizite Möglichkeit, den Signaturalgorithmus' für ein Zertifikat zu beeinflussen.
-Falls aus technischen Gründen für ein RSA-basiertes Serverzertifikat der Signaturalgorithmus ''sha256WithRSAEncryption'' zwingend erforderlich ist, kann dieses mittels [[de:dfnpki:tcsfaq#acme|ACME]] im Endpunkt "OV" beantragt werden. Per ACME im Endpunkt "OV" ausgestellte Serverzertifikate mit RSA-Schlüsseln werden aktuell mit dem Signaturalgorithmus ''sha256WithRSAEncryption'' signiert.
+Falls aus technischen Gründen für ein RSA-basiertes Serverzertifikat der Signaturalgorithmus ''sha256WithRSAEncryption'' zwingend erforderlich ist, kann dieses mittels [[de:dfnpki:tcs:servercert_acme|ACME]] im Endpunkt "OV" beantragt werden. Per ACME im Endpunkt "OV" ausgestellte Serverzertifikate mit RSA-Schlüsseln werden aktuell mit dem Signaturalgorithmus ''sha256WithRSAEncryption'' signiert.
 (**Achtung:** Wirklich nur Endpunkt "OV". Der Endpunkt "GEANTOV" arbeitet mit ''sha384WithRSAEncryption''.)
@@ Zeile 136: / Zeile 135: @@
 GÉANT TCS Zertifikate sind **nicht** für die Verschlüsselung von VoIP-Anschlüssen im Rahmen von DFNFernsprechen vorgesehen.
-Die SBCs des DFNFernsprechen-Dienstleisters akzeptieren sowohl Zertifikate aus der DFN-PKI Global als auch Zertifikate aus der **DFN-Verein Community PKI**, siehe https://www2.dfn.de/dienstleistungen/dfnfernsprechen/voip/verschluesselung
+Die SBCs des DFNFernsprechen-Dienstleisters akzeptieren sowohl Zertifikate aus der DFN-PKI Global als auch Zertifikate aus der **DFN-Verein Community PKI**, siehe [[https://www.dfn.de/wp-content/uploads/2023/04/DFNFernsprechen_Verschluesselung_Stand_Dezember_2022.pdf|Dokumentation DFN-Fernsprechen]].
 ====Extended Validation Zertifikate (EV)====
-EV-Zertifikate können nur erstellt werden, nachdem in cert-manager ein sog. EV Anchor angelegt wurde. Dies ist ein spezielles administratives Zertifikat, dessen Ausstellung von allen Prozeduren zur besonderen Prüfung nach EV-Standard begleitet wurde.
+EV-Zertifikate stehen nur auf Anfrage zur Verfügung. Bitte bedenken Sie vor einer Anfrage, dass Sie durch die EV-Zertifikate keinen zusätzlichen praktischen Nutzen, aber einen hohen Aufwand haben.
-  * Bitte versuchen Sie auf keinen Fall, ein normales EV-Zertifikat vor der Erstellung eines EV Anchors zu beantragen.
-  * Vor der Erstellung eines EV-Anchors müssen die EV-Informationen unter ☰->Organizations-><Auswahl>->Edit Tab "EV Details" korrekt sein. Diese EV Details müssen von der DFN-PCA gesetzt werden, allerdings benötigen wir Ihre Mithilfe.
-Die Anleitung im GÉANT FAQ ist zu finden unter: [[https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ#TCS2020FAQ-Q:HowdoIcreateanEVAnchor?]]
-Versuchen Sie auf keinen Fall mehrere EV Anchor zu erstellen.
 ====Welches Download-Format soll gewählt werden?====
@@ Zeile 169: / Zeile 162: @@
 Ein External Requester wird optional bei den Antragsformularen für Serverzertifikate abgefragt. Hier kann schlicht eine zusätzliche Mailadresse angegeben werden, die Benachrichtigungen zum Zertifikat erhält.
+=====Auswahl des "Key protection Algorithms" in Formularen für .p12-Dateien=====
+Sofern bei der Beantragung von Serverzertifikaten die Schlüsselerzeugung durch TCS (entweder direkt im Browser der Antrags-Web-Seiten) ausgeführt wird, kann aus einer Drop-Down-Liste das kryptografische Verfahren zur Sicherung des privaten Schlüssels (''Choose key protection algorithm'') ausgewählt werden.
+Vorausgewählt ist dabei die modernere und sicherere Methode ''Secure AES256-SHA256'', alternativ steht auch die zu älteren Systemen kompatible Methode ''Compatible TripleDES-SHA1'' zur Auswahl.
+Bei ''Secure AES256-SHA256'' kann es dann auf einigen Systemen (z.B. Windows, iOS) beim Import zu Fehlern kommen. Beispiele:
+  * "//Das eingegebene Kennwort ist falsch.//"
+  * "//Fehler im zugrunde liegenden Sicherheitssystem. Ungültigen Anbietertyp angegeben//"
+  * Aufforderung zum Einstecken einer Smartcard
+In so einem Fehlerfall hilft es, die betroffene .p12-Datei zunächst in den Zertifikat-Manager vom Firefox-Browser zu importieren und dann von dort direkt wieder in eine //neue// .p12-Datei zu exportieren. Danach sollte dieses Zertfikat dann aus dem Firefox wieder gelöscht werden. Eine [[https://www.ca.kit.edu/p/faq/de/fix-tcs-p12|bebilderte Anleitung dafür gibt es vom KIT]].
+Die neue .p12-Datei ist dann nach unserer Erfahrung problemlos in die betroffenen Systeme zu importieren.
+Alternativ zu dieser Konvertierung der .p12-Datei kann auch das Kommandozeilenwerkzeug ''openssl'' genutzt werden, um die Datei in ein kompatibles PKCS#12-Format umzukodieren oder es kann auch einfach ein neues Zertifikat beantragt werden, wobei dann bereits bei der Beantragung auf den Antrags-Web-Seiten die Methode ''Compatible TripleDES-SHA1'' ausgewählt werden muss.
+Die organisations-spezifische Dokumentation und Anleitung zur Serverzertifikatbeantragung sollte ggf. einen Hinweis auf diese möglichen Inkompatibilitäten enthalten.