Server-Zertifikate (außer GRID)

1. Einleitung

  • In diesem Dokument geht es um Server-Zertifikate für am LRZ gehostete Einheiten (Web-Hosting oder Server-Hosting). Für Server, die weder dem LRZ (bzw. der BAdW) gehören, noch am LRZ gehostet sind, können Sie vom LRZ keine Zertifikate beziehen.
  • Zu beachten: IP-Adressen können in Zertifikaten nicht verwendet werden.

2. Kurz-Übersicht

2.1. Web-Hosting

  1. Wenn Sie für Ihren Web-Server einen eigenen Namen verwenden, müssen Sie sicherstellen, daß dieser Name bzw. die Domain validiert ist. Siehe unten → Domainvalidierung.
  2. Wenn die Domain validiert ist, müssen Sie nichts weiter machen. Ihr Web-Server bekommt von uns sein Zertifikat automatisch.


2.2. Server-Hosting

Da Sie als Server-Administrator für das Zertifikat selbst verantwortlich sind, haben Sie die Wahl, von wem Sie es beziehen wollen. Im Wesentlichen gibt es folgende Möglichkeiten:

  1. von Ihrer Institution (für die TUM: https://www.it.tum.de/it/zertifikate/ oder TUM-Serverzertifikate, für die LMU: pki@lmu.de)
  2. vom LRZ (das ist insbesondere nötig, wenn der Server-Name auf srv.mwn.de oder mhn.de endet, weil außer dem LRZ sonst niemand Zertifikate für diese Domains ausstellen kann)
  3. vom freien Markt, z.B. Let's Encrypt https://collab.dvb.bayern/display/TUMdocs/Serverzertifikat+beantragen

Im Fall 2 gilt nun folgendes:

  • Wenn Sie für Ihren Web-Server einen eigenen Namen verwenden, müssen Sie sicherstellen, daß dieser Name bzw. die Domain validiert ist. Siehe unten → Domainvalidierung.
  • Wenn die Domain validiert ist, erstellen Sie einen privaten Schlüssel und den Request (siehe unten → Privaten Schlüssel und CSR erzeugen).
  • Eröffnen Sie dann mit Ihrer SIM-Kennung ein Ticket ( https://servicedesk.lrz.de/ql/create/43 ), in dem Sie unter Angabe des gewünschten Namens ein Zertifikat beantragen, und fügen den Request als Anlage bei (aber auf keinen Fall den privaten Schlüssel). Außerdem benötigen wir eine Kontakt-Mailadresse, am besten eine Sammel- oder Gruppenadresse, damit Mails bezüglich des Zertifikats auch dann noch jemanden erreichen, wenn Sie Ihre Institution inzwischen womöglich verlassen haben.
  • Zertifikate können so generiert werden, daß sie eine gewisse Zeit vor Ablauf automatisch erneuert werden. Wenn eine Kontakt-Mailadresse angegeben wurde, tragen wir hier 21 Tage ein, aber auf Wunsch sind natürlich auch andere Zeiten möglich. Ohne Kontakt-Mailadresse gehen wir von einer eher temporären Lebensdauer des Zertifikats aus und tragen keine automatische Verlängerung ein.
  • Sie erhalten dann von Sectigo eine Downoad-Mail (siehe unten), mit der Sie ihr Zertifikat in verschiedenen Formaten (verschiedene Varianten von .pem, .cer und .p12) herunterladen können.

Hinweis: Anders als in der DFN-PKI-Umgebung ist es unter GÉANT/Sectigo nicht möglich, bei einem ausgestellten Zertifikat zusätzliche SANs (Subject Alternative Names) hinzuzufügen. Brauchen Sie in Ihrem Zertifikat weitere SANs, müssen Sie es komplett neu beantragen.

3. Domainvalidierung

Zu beachten: Domain-Validierungen sind nur 1 Jahr lang gültig und müssen dann erneuert werden.

Hinweis: Für eine Reihe von Domains, etwa *.lrz.de, *.badw.de und *.mwn.de kümmern wir uns selbst um die Validierung. Wenn Ihr Server in einem dieser Namensräume liegt, dann müssen Sie nichts machen.


Sowohl für die DFN-PKI als auch die neue GÉANT/Sectigo-Umgebung gilt, daß wir (d.h. das LRZ, aber auch jeder andere Zertifikats-Ersteller) nur Zertifikate für Namen bzw. Domains ausstellen können, wenn wir dafür die Erlaubnis haben. Technisch gesehen muß die entsprechende Domain validiert sein.

Hier gibt es wiederum zwei Fälle:

3.1. Fall 1: Ihre Domain ist am LRZ gehostet

Machen Sie mit Ihrer SIM-Kennung über https://servicedesk.lrz.de/ql/create/36 ein Ticket auf (über den Teil Selfservice, nicht Simple Submit):

und teilen uns den gewünschten Domain-Namen mit. Für Domains, die bei uns gehostet sind, können wir die Validierung dann selbst erledigen.

3.2. Fall 2: Sie hosten Ihre Domain selbst oder bei einem Drittanbieter

Hier müssen Sie folgendes beachten:

Haben Sie für Ihre Domain einen CAA-Record konfiguriert, muß dieser vorab für Sectigo erweitert werden (hier am Beispiel der Domain xxx-domain.de):

xxx-domain.de.       IN    CAA    0 issue "sectigo.com"

Bisherige Einträge lassen Sie zweckmäßigerweise drin.

Haben Sie keinen CAA-Record konfiguriert, müssen Sie diesbezüglich nichts weiter machen.

Für die Validierung brauchen Sie auch eine Mailbox hostmaster@<Domain>, an die u.a. die Validierungsmail geschickt wird.

Eröffnen Sie dann mit Ihrer SIM-Kennung über https://servicedesk.lrz.de/ql/create/36 ein Ticket und teilen uns den gewünschten Domain-Namen mit. Wir tragen die Domain dann zur Validierung bei Sectigo ein und verschicken die Validierungsmail an o.g. Adresse. Wenn diese nicht exisitiert, ist keine Validierung möglich, zumindest nicht ohne weiteres. Sollte es Ihnen nicht möglich sein, die Mailbox hostmaster@<Domain> einzurichten, schreiben Sie das bitte im Ticket dazu. Wir überlegen uns dann, ob es eine alternative Möglichkeit geben könnte.


Bitte beachten Sie, daß es während der Übergangszeit nötig sein kann, Ihre Domain sowohl in der alten als auch in der neuen Umgebung zu validieren.


4. Privaten Schlüssel und CSR erzeugen

4.1. Für LINUX

4.1.1. Nur 1 Hostname

Wenn im Zertifikat nur ein einziger Hostname (Common Name - CN) stehen soll, genügt folgender Einzeiler:

  • Version mit privaten Schlüssel ohne Paßwort, erzeugt auf dem entsprechenden Host (hier wird der Einfachheit halber angenommen, daß der Rechnername, also der hostname, auch ins Zertifikat soll. Wenn nicht, schreiben Sie Statt  `hostname` einfach den gewünschten Namen):
openssl req -nodes -newkey rsa:4096 -out `hostname`-request.pem -keyout `hostname`-sec-key-ohnepass.pem -subj "/CN=`hostname`.xxx/O=Bayerische Akademie der Wissenschaften/L=Garching b. Muenchen/ST=Bayern/C=DE"


  • Version mit paßwort-gesichertem privaten Schlüssel, erzeugt auf dem entsprechenden Host:
openssl req -newkey rsa:4096 -out `hostname`-request.pem -keyout `hostname`-sec-key.pem -subj "/CN=`hostname`.xxx/O=Bayerische Akademie der Wissenschaften/L=Garching b. Muenchen/ST=Bayern/C=DE"


Die Namen der Ausgabedateien sind natürlich frei wählbar. xxx muß natürlich durch den entsprechenden Domain-Namen ersetzt werden. Sollte es Probleme mit der Schlüssellänge 4096 geben, ist auch 2048 als Wert möglich.

4.1.2. Mehrere Hostnamen

Ein Zertifikat kann mehr oder weniger beliebig viele CNs enthalten. Dies können Aliasnamen eines Servers oder Namen mehrerer verschiedener Server sein, die dann alle dasselbe Zertifikat (und denselben privaten Schlüssel) bekommen. Leider funktioniert obiger openssl-Befehl nur mit einem einzelnen CN. Sollen mehrere Namen ins Zertifikat, so müssen Sie es folgendermaßen zusammenbauen:

schreiben Sie eine Textdatei (im Beispiel zert.conf genannt) mit folgendem Inhalt (für die LRZ-CA):

prompt = no
 distinguished_name = req_distinguished_name
 [ req_distinguished_name ]
 countryName = DE
 stateOrProvinceName = Bayern
 localityName = Garching b. Muenchen
 organizationName = Bayerische Akademie der Wissenschaften
 commonName = Name des Servers (FQDN)
 emailAddress = E-Mail-Adresse des Zertifikatnehmers
[ req_exts ]
subjectAltName = @SAN
[SAN]
DNS.0=DNS-Name wie im Common Name
DNS.1=weiterer DNS-Name
DNS.2=weiterer DNS-Name ...


Schlüsel und CSR erzeugen Sie nun mit dem folgenden Befehl:

openssl req -config zert.conf -reqexts req_exts -newkey rsa:2048 -sha256 -keyout key.pem -out csr.pem


Die Namen der Ausgabedateien (hier key.pem und csr.pem) sind, wie üblich, frei wählbar.


4.2. Für WINDOWS

Die Details der einzelnen Schritte hängen ein bißchen von der jeweiligen Windows-Version ab, gehen aber im Prinzip folgendermaßen:

  • IIS-Verwaltung starten (am besten im Suchfeld nach IIS suchen):

Dort die gewünschte Site anklicken → Serverzertifikate (doppelklicken):

Zertifikatanforderung erstellen anklicken. Es öffnet sich dann folgende Eingabemaske:

Die Felder sind wie folgt auszufüllen:

Gemeinsamer Name (CN): Name des entsprechenden Rechners, z.B. test123.lrz.de

Organisation (O): Bayerische Akademie der Wissenschaften

Organisationseinheit (OU): nichts eintragen

Ort (L): Garching b. Muenchen

Bundesland/Kanton (ST): Bayern

Land (C): DE


4.3. Vorhandenes Zertifikat in Windows an IIS binden

Das Zertifikat muß im .p12-Format vorliegen, d.h. es muß den privaten Schlüssel enthalten. Durch Doppelklick wird es dann in den Windows-Zertifikatspeicher installiert. Achten Sie darauf, daß der Installationsort Webhosting → Zertifikate ist.

Achtung: Solche Zertifikat sind in der Regel verschlüsselt. Sie müssen das Paßwort dafür kennen.


Um den Webserver (IIS) mit dem Zertifikat auszustatten, öffnen Sie die IIS-Konsole, wählen die gewünschte Site (es kann nämlich auch mehrere geben) und dann Bindungen:

Es öffnet sich folgendes Fenster, wo Sie nun den Eintrag für https bearbeiten:

Das führt zu diesen Dialog, wo Sie nun das gewünschte Zertifikat auswählen können:

In der Auswahlliste werden die Zertifikate angezeigt, die im Windows-Zertifikatspeicher unter Webhosting → Zertifikate liegen.


5. Die Download-Mail

Die Download-Mail sieht etwa so aus und bietet das Zertifikat in 7 Varianten zum Herunterladen. Für den Standard-Apache ist das zweite von oben wahrscheinlich das richtige:


6. Zertifikat sperren

Es empfiehlt sich, Zertifikate, die vor ihrem Ablaufdatum aus dem Einsatz genommen werden, sperren zu lassen.

6.1. Möglichkeit 1

Per IET-Incident an die LRZ-PKI.

6.2. Möglichkeit 2

Wenn Sie über das Zertifiakt und den zugehörigen privaten Schlüssel verfügen, können Sie Ihr Zertifikat über den folgenden Link sperren:

https://secure.sectigo.com/products/RevocationPortalDetails?action=2a

Geben Sie dann auf der Eingabemaske die gewünschten Daten ein:

7. Sonstiges

Infos der TUM: http://www.it.tum.de/zertifikate/ 

Infos der LMU: https://www.serviceportal.verwaltung.uni-muenchen.de/services/it/infrastrukturdienste/ausstellung_zertifikate/index.html#goto404268 (LMU-Login erforderlich.)





Zuletzt aktualisiert am 24.6.2024