Veröffentlicht: 25.03.2024. 🔗 Permalink

Zertifikatsantrag

Zugriffsschutz mittels mTLS

Die durch die SU-TermServ gehostete Instanz ist mittels Mutual-TLS gesichert. Dies bedeutet, dass bei jedem Zugriff auf den Endpunkt ein beidseitiger Zertifikatsaustausch stattfindet, somit ist auch auf Ihrer Seite ein entsprechendes Zertifikat einzurichten und bei jedem Verbindungsaufbau zu präsentieren ist:

Zertifikat-Infrastruktur innerhalb des DFN

Der Großteil der tertiären Bildungseinrichtungen in Deutschland, d.h. Universitäten und Hochschulen, sowie die deutschen Universitätsklinika, sind Partner im Deutschen Forschungsnetz e.V. (DFN). Neben einer leistungsfähigen Glasfaser-Infrastruktur zur Anbindung der Einrichtungen an das Internet betreibt das DFN auch einen Public Key Infrastructure (PKI) zur Ausstellung von Zertifikaten, die DFN-PKI. Diese Zertifikate können für die Absicherung von Webseiten, E-Mail-Verkehr, VPN-Verbindungen und auch für die Authentifizierung von Benutzern verwendet werden. In der Vergangenheit wurden diese Zertifikate durch die DFN-Institutionen eigenverantwortlich ausgestellt und waren über ein Wurzelzertifikat der Deutschen Telekom verankert. Seit 2021 wurde diese PKI sukzessive durch einen Dienst (Trusted Certicate Services, TCS), der durch die pan-europäische GÉANT angeboten und seinerseits durch Sectigo betrieben wird, abgelöst. Nunmehr sind alle Server-Zertifikate aus der alten DFN-PKI abgelaufen, während persönliche Zertifikate, die mit einer Gültigkeit von 3 Jahren ausgestellt wurden, noch einige Monate gültig sein können. Neue Zertifikate werden ausschließlich aus der neuen PKI ausgestellt. Alte Zertifikate können nicht verlängert werden, sofern sie noch nicht abgelaufen sind, werden sie durch unsere Dienste aber weiterhin akzeptiert.

Während die alte DFN-PKI durch die jeweiligen Rechenzentren lokal verantwortet wurde, indem durch die DFN eine Webkonsole und eine sogenannte Intermediate-Zertifizierungsstelle (Intermediate-CA) bereitgestellt wurde, wird innerhalb von TCS nunmehr Selbstbedienung angeboten. Durch die Rechenzentren der DFN-Teilnehmerinnen ist die Bereitstellung einer Authentifizierungs- und Autorisierungslösung erforderlich, durch die sich Nutzer:innen bei der Sectigo-Konsole föderiert anmelden können (es sei auf die Hilfeseiten der DFN verwiesen). Nachdem sich Anwender:innen über die entsprechenden Einstiegspunkte, die durch die Partnereinrichtung bekannt gemacht werden, angemeldet haben, können persönliche Zertifikate und Server-Zertifikate ausgestellt werden. Hier muss differenziert werden, wie die Sicherstellung der Identität der zu zertifizierenden Entität erfolgt:

  • Bei persönlichen Zertifikaten wird dies durch die Authentifizierung der Person durch die Heimateinrichtung sichergestellt (d.h. fĂĽr Mitarbeiter:innen und Studierende bei Einstellung bzw. Immatrikulation durch Vorlage eines amtlichen Ausweises)
  • Bei Server-Zertifikaten wird die Identität des Servers durch die Anmeldung an der Sectigo-Konsole und die Bestätigung der Domaininhaberschaft sichergestellt. Dies wird durch den Mechanismus der Domain Control Validation sichergestellt. Dies bedeutet, dass jede DFN-Partnerinstitution nur Zertifikate unterhalb der ihr zugeordneten Domain(-s) ausstellen kann. Beispiel: Die Universität Beispielstadt hat die Domain uni-beispielstadt.de und kann daher nur Zertifikate fĂĽr www.uni-beispielstadt.de, mail.uni-beispielstadt.de, server1.vpn.uni-beispielstadt.de etc. ausstellen. FĂĽr die Validierung der entsprechenden Top Level Domain(-s) ist das jeweilige, lokale, Rechenzentrum verantwortlich.

Beantragung eines Zertifikates

Grundsätzlich erfolgen alle Prozesse zum Ausstellen eines Zertifikats innerhalb der Web-Konsole des externen Anbieters Sectigo. Neben GÉANT TCS betreibt Sectigo allerdings auch andere kommerzielle Zertifizierungsdienste, sodass der Einstiegspunkt in die Konsole mittels entsprechender Weblinks erfolgt, die den Kunden (der DFN e.V.) gegenüber Sectigo identifiziert. Technisch bedingt kann es zu den unten genannten Links zu Abweichungen kommen. Es sei auf die entsprechenden Hilfeseiten Ihrer lokalen Institution verwiesen.

Generelle Anweisung...

In diesem Hilfe-Artikel wird der grundlegende Antragsprozess am Beispiel der Universität zu Lübeck beschrieben. Alle getroffenen Aussagen und der Prozess warem zum Zeitpunkt des Verfassens dieses Artikels am 25.03.2024 für den Antragsprozess innerhalb des Netzwerkes der Universität zu Lübeck korrekt. Bitte prüfen Sie selbsständig, ob durch das Rechenzentrum Ihrer Organisation anderslautende Anweisungen zum Beantragen eines Zertifikats verfügbar sind.
Auch kann und wird die SU-TermServ keine Hilfestellung für die Beantragung eines geeigneten Zertifikates leisten. Im Falle von Problemen wenden Sie sich bitte selbstständig an Ihr Rechenzentrum!

Persönliche Zertifikate

Persönliche Zertifikate können grundsätzlich für Mitarbeiter:innen und Studierende beantragt werden. Hierzu ist die Anmeldung an der Sectigo-Konsole erforderlich. Nach erfolgreicher Anmeldung kann ein Zertifikat beantragt werden. Die Identität der Person wird durch die Heimateinrichtung sichergestellt. Die Zertifikate haben eine Gültigkeit von 3 Jahren.

Im Regelfall ist die entsprechende Konsole ĂĽber den Link https://cert-manager.com/customer/DFN/idp/clientgeant erreichbar, es kann fĂĽr Ihre Institution jedoch auch abweichende Links geben.

Melden Sie sich nun ĂĽber den Identity Provider (IdP) Ihrer Institution an:

Auswahl der eigenen Institution
Anmeldung im hauseigenen IdP

Je nach Konfiguration Ihres IdP kann es sein, dass Sie die Übermittlung Ihrer persönlichen Informationen bestätigen müssen:

Bestätigung der Übermittlung von persönlichen Informationen

Nach der Anmeldung können Sie nun Ihr Zertifikat beantragen, indem Sie den Antrag sukzessive ausfüllen:

Wichtige Einstellungen

  • Sofern Ihnen die Laufzeit von 730 Tagen angeboten wird, sollten Sie diese auch wählen.
  • Als Enrollment Method sollten Sie Key Generation wählen, sofern Sie nicht durch Ihre Institution aufgefordert werden, einen eigenen SchlĂĽssel zu generieren und ein Certificate Signing Request (CSR) hochzuladen. Die Verwendung eines CSR ist natĂĽrlich trotzdem möglich, erfordert aber Expertise im Umgang mit Zertifikaten. Mittels der Key Generation wird der SchlĂĽssel direkt in Ihrem Browser generiert und an Sectigo ĂĽbermittelt.
  • Wichtig: Wählen Sie als Key Type , RSA mit mindestens 2048 Bit aus, 4096 Bit werden empfohlen. Die Verwendung von Eliptic-Curve-SchlĂĽsseln (EC) kann problematisch im Verbindungsaufbau mit dem Ontoserver sein, nur RSA ist aktuell vollständig unterstĂĽtzt.
  • Wichtig: Wählen Sie als Key protection algorithm Compatible TripleDES-SHA1 aus, da Betriebssysteme und Java mit den moderneren Algorithmen gravierende Probleme haben. Grundsätzlich können Sie auch Secure AES256-SHA256 wählen, mĂĽssen dann aber ggf. das SchlĂĽsselpaar in das kompatible Format umwandeln. Dies ist mit OpenSSL möglich, der Konvertierungsprozess ist in dieser Antwort auf StackOverflow beschrieben.

Zertifikatanfrage-Formular

Nach einer kurzen Wartezeit wird das Zertifikat im PKCS-12-Format mit der Dateiendung .p12 bereitgestellt. Dieses Zertifikat kann in den meisten Betriebssystemen und Anwendungen importiert werden. FĂĽr die Verwendung im Browser sei auf diesen FAQ-Eintrag verwiesen, die Einrichtung innerhalb von Ontoserver fĂĽr Syndication (wobei hierzu die Verwendung eines Server-Zertifikates angeraten wird) ist im FAQ-Eintrag Syndication (-Zertifikat) einrichten beschrieben.

Server-Zertifikate

Für die Beantragung von Server-Zertifikaten kann leider keine einheitliche Anleitung bereitgestellt werden, sondern nur das Beispiel für den Antrag eines Zertifikats an der Universität zu Lübeck gezeigt werden (die Anleitung ist hier zu finden, aber eben so auch nur für die Universität zu Lübeck gültig).

Es kann sogar sein, dass Ihr Rechenzentrum die Beantragung von Server-Zertifikaten durch Selbstbedienung in der Sectigo-Konsole noch nicht ermöglicht. In diesem Fall wenden Sie sich bitte an Ihr Rechenzentrum, um die Beantragung zu klären!

Zur Beantragung eines Server-Zertifikates werden durch die Rechenzentren Kenntnisse mit dem Umgang in der Kommandozeile sowie eine aktuelle Installation von OpenSSL vorausgesetzt. Eine ALternative kann die Verwendung des graphischen Tools Keystore Explorer (KSE) darstellen, dessen Nutzung hier auch beschrieben wird. Dies wird eher empfohlen, wenn Sie das Zertifikat nicht ebenfalls zur HTTPS-Verschlüsselung mittels eines Reverse Proxy verwenden wollen, sondern nur zur Authentifizierung uns gegenüber, oder zur direkten HTTPS-Umsetzung in Ihrem Ontoserver. Ein Export des Schlüsselpaares im PEM-Format aus KSE heraus ist aber auch möglich.

Die Beantragung erfolgt in mehreren Schritten:

  1. Erstellen eines SchlĂĽsselpaares
  2. Erstellen eines Certificate Signing Requests (CSR)
  3. Einreichen des CSR bei Sectigo
  4. Validierung der Domaininhaberschaft (durch Ihr Rechenzentrum)
  5. Erhalt des Zertifikats durch Sectigo

Zertifikate fĂĽr nicht-existente Domains

Grundsätzlich kann ein Zertifikat auch für einen Server ausgestellt werden, der nicht existiert. Durch Ihr Rechenzentrum wurde die Top-Level-Domain (z.B. uni-beispielstadt.de) per Domain Verification bereits bestätigt, und Ihre Anfrage für test.uni-beispielstadt.de wird dann durch das Team im RZ geprüft. Es kann sein, dass Ihr RZ nur Anträge für existente Domains bearbeitet, hier ist ggf. Rücksprache zu halten. Wir verifizieren die Erreichbarkeit Ihres Servers natürlich nicht.

CSR-Erstellung unter Verwendung von OpenSSL

Mittels OpenSSL muss zuerst der private SchlĂĽssel erstellt werden:

openssl genrsa -out su-termserv-test.imi.uni-luebeck.de.key 4096

Als nächstes muss eine Zertifikatsanfrage erstellt werden:

openssl req -sha256 -key su-termserv-test.imi.uni-luebeck.de.key -new -out su-termserv-test.imi.uni-luebeck.de_csr.pem

Dabei wird Sie OpenSSL nach einigen Eingaben fragen, die durch Ihre Institution vorgegeben werden. Für die Universität zu Lübeck sieht dies mit den Eingaben so aus:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Schleswig-Holstein
Locality Name (eg, city) []:Luebeck
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Universitaet zu Luebeck
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:su-termserv-test.imi.uni-luebeck.de
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Nicht zu setzende Attribute

Die Attribute Challenge password und Company Name sollen (in der Regel) leer gelasssen werden. Das Attribut Organizational Unit Name wird nunmehr nicht mehr durch Sectigo verwendet und kann leer gelassen werden.

Sollten Sie weitere Subject Alternate Names benötigen, können diese Einstellungen in eine Datei geschrieben und mit -config an OpenSSL übergeben werden. Hierzu sei an die Dokumentation Ihres Rechenzentrums und die von OpenSSL verwiesen.

CSR-Erstellung unter Verwendung von Keystore Explorer

Mittels Keystore Explorer lassen sich die notwendigen Schritte ebenfalls durchführen. Nach dem Start des Programms wählen Sie “Neuen Schlüsselspeicher erstellen”. Im folgenden Dialog wählen Sie “PKCS#12” als Typ des neuen Schlüsselspeichers:

Erstellen des Keystores in KSE

Als nächstes wählen Sie “Schlüsselpaar erstellen” aus und wählen dann RSA mit 4096 Bit aus:

Erstellen eines SchlĂĽsselpaares in KSE

Als nächstes ist oben auf Version 1 umzustellen und der Distinguished Name (DN) des auszustellenden Zertifikats inzugeben, der hier auch strukturiert erfasst werden kann:

Eingabe des DN in KSE

E-Mail

Es muss auch eine E-Mail-Adresse angegeben werden, unter der Sie erreichbar sind. Dazu muss auf das + im DN-Dialog geklickt werden, dann Email (E) ausgewählt werden. Dies ist für die Beantragung Ihres Zertifikats notwendig, damit Sie das Zertifikat von Sectigo erhalten können.

Die Gültigkeitsdauer von einem Jahr ist dabei vorausgewählt und so passend. Nach Bestätigung wird noch nach dem Aliasnamen gefragt, dessen Vorbelegung der CN aus dem Zertifikatsnamen entspricht, das kann so übernommen werden.

Als letztes ist ein Passwort für den Schutz des privaten Schlüssels zu vergeben, dieses kann frei gewählt werden. Anschließend erscheint der neue Zertifikatseintrag in der Liste. Speichern Sie nun den Schlüsselspeicher ab, indem Sie auf “Speichern” klicken. Hierbei werden Sie ebenfalls nach einem zu vergebenden Passwort gefragt, dieses sollte pragmatisch identisch zum Passwort für das Schlüsselpaar gewählt werden!

Speichern des Keystores in KSE

Als nächstes muss ebenfalls ein Certificate Signing Request (CSR) erstellt werden. Hierzu wählen Sie den Eintrag des Schlüsselpaares aus und klicken auf “Zertifikatsanfrage erstellen”. Die Standard-Einstellungen sollten so bereits passend gewählt sein:

Erstellen des CSR
Erstellen des CSR - Standardeinstellungen zum Export

Mit den Standard-Einstellungen wird der CSR im gleichen Ordner wie Ihr Keystore erstellt.

Beantragung des Zertifikats

Nachdem Sie den CSR erstellt haben, können Sie diesen nun über die Konsole von Sectigo einreichen. Nach erfolgreicher Validierung der Domaininhaberschaft durch Ihr Rechenzentrum wird das Zertifikat von Sectigo ausgestellt und Ihnen bereitgestellt.

Melden Sie sich in der Konsole an, indem Sie die Anleitung Ihres Rechenzentrums befolgen.

Ansicht in der Sectigo-Konsole mit einigen Zertifikaten

Laden Sie nun im Fenster “Enroll Certificate” das CSR hoch. Im Falle der Universität zu Lübeck lassen sich Zertifikat-Profil und Term nicht auswählen, eventuell sieht das bei Ihnen anders aus. Die Felder “External Requesters” und “Auto Renew” sind besonders interessant. Mit External Requesters lassen sich weitere E-Mails hinterlegen, die über den Status der Anfrage informatiert werden sollen und auch Benachrichtigungen zum Ablauf bekommen.

Außerdem kann durch “Auto Renew” bereits im Vorraus die Verlängerung des Zertifikats beantragt werden, sodass der Antrag automatisch mit einer zu wählenden Vorlaufzeit gestellt wird, sodass Sie rechtzeitig die notwendige Server-Wartung etc. planen können.

Requesting certificates in Sectigo

Nachdem Sie den Antrag eingereicht haben, erhalten Sie an die im CSR angegebene und alle weiteren unter External Requests vermerkten Adressen eine Benachrichtigung, dass das Zertifikat in PrĂĽfung ist. Ihr Rechenzentrum muss dan den Antrag prĂĽfen und freigeben, woraufhin das Zertifikat von Sectigo ausgeliefert wird. Dieses erhalten Sie ebenfalls per E-Mail. FĂĽr die Verwendung des Zertifikats fĂĽr die Verbindung mit der SU-TermServ ist die weitere Einrichtung in der FAQ Syndication (-Zertifikat) einrichten beschrieben.

Erstellung eines P12-Bundles mit OpenSSL

Nachdem Sie das Zertifikat erhalten haben, können Sie dieses in ein P12-Bundle umwandeln, um es in den Ontoserver zu importieren. In der E-Mail von Sectigo klicken Sie auf den Link unter as Certificate (w/chain), PEM encoded, und laden Sie die Datei herunter (hier: su-termserv-test.imi.uni-luebeck.de.cert).

Danach können Sie mit OpenSSL das P12-Bundle erstellen:

openssl pkcs12 -export -legacy -inkey su-termserv-test.imi.uni-luebeck.de.key -in su-termserv-test.imi.uni-luebeck.de.cert -name su-termserv-test.imi.uni-luebeck.de -out su-termserv-test.imi.uni-luebeck.de.p12

Wie oben erwähnt ist der -legacy-Switch notwendig um die Kompatibilität mit Betriebssystemen und Java zu gewährleisten. Das Passwort, das Sie hier vergeben, wird beim Import des Zertifikats in den Ontoserver benötigt.

Import des Zertifikats in KSE

Der Import in KSE wird demonstriert, sobald wir das Zertifikat durch Sectigo erhalten haben