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:

Cloudflare: Was ist mutual TLS (mTLS)?

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.

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:

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

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

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

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 []:

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:

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

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:

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!

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:

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.

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.

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