====Serverzertifikate==== ===Direkt im cert-manager=== Sie können als eingeloggter RAO oder DRAO direkt im cert-manager Serverzertifikate beantragen und ausstellen. Wählen Sie hierzu unter ☰->Certificates->SSL Certificates den grünen Button "+", und folgen Sie dem Formular. Sie müssen in jedem Fall selbst einen CSR vorbereiten und hochladen. Die theoretisch im cert-manager angebotenen Methoden "Generation of CSR..." stehen in GÉANT TCS nicht zur Verfügung und können nicht angewählt werden. Wählen Sie im Regelfall das Zertifikatprofil ''OV Multi-Domain''. Wählen Sie **nicht** das Zertifikatprofil ''EV Anchor'', es sei denn, Sie wollen den speziellen EV-Prozess starten. Potentielle **Falle** hierbei: Das Zertifikatprofil ''EV Anchor'' ist in der Auswahlliste an erster Stelle und vorausgewählt und es gibt auch noch das Zertifikatprofil ''EV Multi-Domain'', das ebenfalls für Standard-SSL-Zertifikate nicht genutzt werden sollte. ===Über die AAI==== 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 - Mit dem grünen Button "+" oben rechts ein neues Enrollment Form erzeugen - Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist - Als Typ "SSL certificate enrollment form" setzen - Im folgenden Dialog unter Tab "Details" eine URI Extension setzen oder generieren lassen. Diese URI Extension definiert die URL, unter der später Zertifikate beantragt werden kann: ''%%https://cert-manager.com/customer/DFN/ssl/%%'' - Im selben Dialog unter Tab "Configuration" den Authentication Type "Identity Provider" anwählen. - Mit "Save" abspeichern - Das neue Formular auswählen - Oben auf "Accounts" klicken. - Im daraufhin geöffneten Popup-Fenster über mit dem grünen "+"-Button einen neuen Account hinzufügen. - Einen sprechenden Namen für den Account vergeben, der auf Ihre Einrichtung hindeutet. - Als "Organization" Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen). - Bei den Zertifikatprofilen über das kleine "+"-Zeichen aus der Drop-Down-Liste das gewünschte Zertifikatprofil auswählen - 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. Damit muss der CSR vorab erzeugt werden und dann bei Zertifikatantragstellung auf der Web-Seite hochgeladen werden. - 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!** - Dann den Button ''Edit'' anwählen - Hinzufügen von "''schacHomeOrganization'' matches ''''", mit Plus und Save bestätigen. - Wenn Sie diesen Schritt auslassen, können User aus beliebigen Identity-Providern Anträge bei Ihnen einreichen! - Den Account insgesamt mittels "Save"-button abspeichern. Bitte keine fremden ''Enrollment Forms'' löschen! Anträge können nun unter der per "URI-Extension" definierten URL eingereicht werden. ''%%https://cert-manager.com/customer/DFN/ssl/%%'' Die eingereichten Anträge müssen von einem RAO oder DRAO über ☰->Certificates->SSL Certificates->->Approve Button genehmigt werden. ===SSL Web Form=== Mit Web-Formularen können Personen ohne eigenen Login für den cert-manager Zertifikate beantragen. Zur Nutzung eines Web-Formulars ist ein sogenannter "Access Code" notwendig. Jeder, der diesen Access Code kennt, kann Zertifikate beantragen. - Im SCM unter ☰->Enrollment->Enrollment Forms - Mit dem grünen Button "+" oben rechts ein neues Enrollment Form erzeugen - Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist - Als Typ "SSL certificate enrollment form" setzen - Im folgenden Dialog unter Tab "Details" eine URI Extension setzen oder generieren lassen. Diese URI Extension definiert die URL, unter der später Zertifikate beantragt werden kann: ''%%https://cert-manager.com/customer/DFN/ssl/%%'' - Im selben Dialog unter Tab "Configuration" den Authentication Type "Email Confirmation" anwählen. - Mit "Save" abspeichern - Das neue Formular auswählen - Oben auf "Accounts" klicken. - Im daraufhin geöffneten Popup-Fenster über mit dem grünen "+"-Button einen neuen Account hinzufügen. - Einen sprechenden Namen für den Account vergeben, der auf Ihre Einrichtung hindeutet. - Als "Organization" Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen). - 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. Damit muss der CSR vorab erzeugt werden und dann bei Zertifikatantragstellung auf der Web-Seite hochgeladen werden. - 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!** - Einen Access Code eintragen - Den Account mittels "Save"-button abspeichern. Bitte keine fremden ''Enrollment Forms'' löschen! Anträge können nun unter der per "URI-Extension" definierten URL eingereicht werden. ''%%https://cert-manager.com/customer/DFN/ssl/%%'' Antragstellende werden zunächst durch eine E-Mail-Challenge geführt, mit der ihre E-Mail-Adresse verifiziert wird. Anschließend müssen sie den Access Code präsentieren, um dann mit den Parametern des hier angelegten Accounts Zertifikate beantragen zu können. Die eingereichten Anträge müssen von einem RAO oder DRAO über ☰->Certificates->SSL Certificates->->Approve Button genehmigt werden. ===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:tcs:restapi|REST-API]] ====ECC oder RSA?==== Der Algorithmus ist entsprechend den Fähigkeiten der Server-Software zu wählen. In den meisten Fällen kann heutzutage ECC genutzt werden. Benutzen Sie im CSR auf jeden Fall das unkomprimierte EC-Schlüsselformat (z.B. ''openssl''-Option ''-conv_form uncompressed'', was auch eigentlich die Default-Einstellung von ''openssl'' ist). ====Profile für Serverzertifikate==== Die Serverzertifikate aus TCS enthalten sowohl den Zertifikatzweck ''serverAuth'' als auch ''clientAuth''. Es können also prinzipiell alle Zwecke mit dem Standard-Zertifikatprofil abgedeckt werden. 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: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: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)==== 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: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''.) ====OV SSL oder OV Multi Domain?==== Wir empfehlen in jedem Fall OV Multi Domain zu verwenden. Im Zertifikatprofil OV Multi Domain sind mehrere Servernamen im Alternative Name möglich, z.B. ''fachbereich1.example.org'', ''fachbereich2.example.org''. Selbst Wildcard-Zertifikate können mit OV Multi Domain erstellt werden. Im Zertifikatprofil OV SSL wird automatisch jedem Zertifikat ein zweiter, in den meisten Fällen sicherlich unerwünschter Alternativer Name ''www.'' hinzugefügt. Beispiel: Antrag enthält ''fachbereich1.example.org'' => Das ausgestellte Zertifikat enthält die Namen ''fachbereich1.example.org'' und ''www.fachbereich1.example.org''. Es gibt eine Größenbeschränkung des CSR auf 32k. Es gibt Dokumentationsfundstücke bei Sectigo, die ein Limit der Anzahl der alternativen Namen auf 250 beschreiben. Diese Dokumentation ist nicht korrekt, in der Praxis konnten wir auch schon 400 alternative Namen aufnehmen. Die Größe für akzeptierte CSR liegt irgendwo zwischen 15000 und 19000 Byte. ====Wildcard-Zertifikate==== Voraussetzung für ein Wildcard-Zertifikat ist eine im cert-manager eingetragene Domain, die mit den Methoden EMAIL oder CNAME validiert wurde. Für Domains, die per HTTP/HTTPS validiert wurden, können keine Wildcard-Zertifikate ausgestellt werden. Für Wildcard-Zertifikate wählen Sie günstigerweise immer das Profil "OV Multi Domain". In diesem Profil können auch Wildcard-Namen frei sowohl im SubjectAltName als auch im CN verwendet werden. Im Profil "Wildcard SSL" können keine weiteren SubjectAltNames können nicht angegeben werden. Die "Wildcard SSL"-Zertifikate werden ausschließlich mit dem Wildcard-Namen und der Basis-Domain ausgestellt. ====VoIP-Zertifikate für DFNFernsprechen==== 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 ====Extended Validation Zertifikate (EV)==== 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. ====Welches Download-Format soll gewählt werden?==== Zertifikat-E-Mails (und auch SCM selbst) bieten mehrere Download-Formate für die Zertifikate an: - Server-Zertifikate: - ''as Certificate only, PEM encoded'' enthält ausschließlich das Server-Zertifikat im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). - ''as Certificate (w/ issuer after), PEM encoded'' enthält als erstes das Server-Zertifikat, dann das Issuing-CA-Zertifikat und dann weitere Intermediate-CA-Zertifikate der CA-Kette, allerdings nicht das Root-CA-Zertifikat, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). Dieses Format kann gut für die Konfiguration von z.B. **Apache-** und **Nginx-Web-Servern** verwendet werden. - ''as Certificate (w/ chain), PEM encoded'' enthält als erstes das Root-CA-Zertifikat, es folgen die Intermediate-CA-Zertifikate, das Issuing-CA-Zertifikat der CA-Kette und als letztes das Server-Zertifikat, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). - ''as PKCS#7'' enthält eine binäre PKCS#7-Struktur, bestehend aus als erstes dem Server-Zertifikat, dann dem Issuing-CA-Zertifikat und dann weitere Intermediate-CA-Zertifikate der CA-Kette und am Ende dem Root-CA-Zertifikat. Dieses Format kann gut für die Konfiguration von z.B. **Microsoft IIS-Web-Servern** verwendet werden. - ''PKCS#7, PEM encoded'' enthält eine PEM-formatierte PKCS#7-Struktur, bestehend aus als erstes dem Server-Zertifikat, dann dem Issuing-CA-Zertifikat und dann weitere Intermediate-CA-Zertifikate der CA-Kette und am Ende dem Root-CA-Zertifikat. - CA-Zertifikate: - ''as Root/Intermediate(s) only, PEM encoded'' enthält die CA-Zertifikatskette (ohne das Server-Zertifikat) von der Root-CA (zuerst) bis hin zur Issuing-CA des Server-Zertifikats, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). - ''as Intermediate(s)/Root only, PEM encoded'' enthält die CA-Zertifikatskette (ohne das Server-Zertifikat) von der Issuing-CA des Server-Zertifikats (zuerst) bis hin zum Root-CA-Zertifikat, alle Zertifikate jeweils für sich im PEM-Format (''–––––BEGIN CERTIFICATE––––– [...] –––––END CERTIFICATE–––––''). =====Was ist ein "External Requester"?===== 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.