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.

Wenn Ihre Einrichtung in die DFN-AAI eingebunden ist und Ihr IdP die Voraussetzungen erfüllt (siehe Zugriff per AAI), können Sie ein Formular aufsetzen, über das nach AAI-Authentifizierung Serverzertifikate beantragt werden können.

1. Im SCM unter ☰→Enrollment→Enrollment Forms
   1. Mit dem grünen Button „+“ oben rechts ein neues Enrollment Form erzeugen
      1. Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist
      2. Als Typ „SSL certificate enrollment form“ setzen
      3. 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/<URI Extension>
      4. Im selben Dialog unter Tab „Configuration“ den Authentication Type „Identity Provider“ anwählen.
      5. Mit „Save“ abspeichern
   2. Das neue Formular auswählen
   3. Oben auf „Accounts“ klicken.
   4. Im daraufhin geöffneten Popup-Fenster über mit dem grünen „+“-Button einen neuen Account hinzufügen.
   5. Einen sprechenden Namen für den Account vergeben, der auf Ihre Einrichtung hindeutet.
   6. Als „Organization“ Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen).
   7. Bei den Zertifikatprofilen über das kleine „+“-Zeichen aus der Drop-Down-Liste das gewünschte Zertifikatprofil auswählen
      1. meist „OV Multi-Domain“
      2. „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.
   8. 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.
      1. 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.
   9. „Automatically Approve Request“ nicht anwählen
   10. Als „Authorization Method“ den Wert „IdP Assertions Mapping“ auswählen. Nicht none verwenden!
   11. Dann den Button Edit anwählen
       1. Hinzufügen von „schacHomeOrganization matches <xyz.de>“, mit Plus und Save bestätigen.
       2. Wenn Sie diesen Schritt auslassen, können User aus beliebigen Identity-Providern Anträge bei Ihnen einreichen!
   12. 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/<URI Extension>

Die eingereichten Anträge müssen von einem RAO oder DRAO über ☰→Certificates→SSL Certificates→<Auswahl>→Approve Button genehmigt werden.

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.

1. Im SCM unter ☰→Enrollment→Enrollment Forms
   1. Mit dem grünen Button „+“ oben rechts ein neues Enrollment Form erzeugen
      1. Einen sprechenden Namen vergeben, der auf Ihre Einrichtung hinweist
      2. Als Typ „SSL certificate enrollment form“ setzen
      3. 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/<URI Extension>
      4. Im selben Dialog unter Tab „Configuration“ den Authentication Type „Email Confirmation“ anwählen.
      5. Mit „Save“ abspeichern
   2. Das neue Formular auswählen
   3. Oben auf „Accounts“ klicken.
   4. Im daraufhin geöffneten Popup-Fenster über mit dem grünen „+“-Button einen neuen Account hinzufügen.
   5. Einen sprechenden Namen für den Account vergeben, der auf Ihre Einrichtung hindeutet.
   6. Als „Organization“ Ihre Einrichtung aus der Drop-Down-Liste auswählen (und ggf. auch ein Department setzen).
   7. Bei den Zertifikatprofilen über das kleine „+“-Zeichen aus der Drop-Down-Liste das gewünschte Zertifikatprofil auswhlen
      1. meist „OV Multi-Domain“
   8. 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.
      1. 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.
   9. „Automatically Approve Request“ auf keinen Fall anwählen.
   10. Als „Authorization Method“ den Wert „Access Code“ auswählen. Nicht none verwenden!
   11. Einen Access Code eintragen
   12. 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/<URI Extension>

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→<Auswahl>→Approve Button genehmigt werden.

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 ACME

Über das REST API können mit selbst erstellter Software oder Skripten Serverzertifikate erstellt werden. Hinweise hierzu unter REST-API

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).

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 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 DFN-Verein Community PKI zurückgreifen, die allerdings ohne Browser- und Betriebssystemverankerung daherkommen.

IP-Adressen können in Serverzertifikate aus TCS aufgenommen werden.

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 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.)

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.

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.

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 Dokumentation DFN-Fernsprechen.

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.

Zertifikat-E-Mails (und auch SCM selbst) bieten mehrere Download-Formate für die Zertifikate an:

1. Server-Zertifikate:
   1. as Certificate only, PEM encoded enthält ausschließlich das Server-Zertifikat im PEM-Format (–––––BEGIN CERTIFICATE––––– […] –––––END CERTIFICATE–––––).
   2. 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.
   3. 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–––––).
   4. 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.
   5. 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.

1. CA-Zertifikate:
   1. 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–––––).
   2. 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–––––).

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.

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