Versions Compared

Old Version 42

changes.mady.by.user lrz-api1

Saved on

compared with

New Version 43

changes.mady.by.user lrz-api1

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


German

Table of Contents

Numbered Headings

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.
  • 2022 migriert die Zertifikats-Erstellung von der DFN-PKI zu GÉANT/Sectigo. Dabei ändern sich die Zertifikatskette (Chain) und das root-Zertifikat.
  • Es ändern sich ebenfalls einige Abläufe. Insbesondere ist kein unterschriebenes PDF mehr nötig. Es geht jetzt alles papierlos. Bestehende Zertifikate aus der DFN-PKI bleiben bis zu ihrem Ablauf gültig.

Kurz-Übersicht

Web-Hosting

Panel
borderColorblack
bgColor#ffd4a0
borderWidth2
borderStylesolid
  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.


Server-Hosting

Panel
borderColorblack
bgColor#ffd4a0
borderWidth2
borderStylesolid

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: ra@zv.tum.de, für die LMU: pki@lmu.de)
  2. vom LRZ (das ist insbesondere nötig, wenn der Server-Name auf srv.mwn.de endet, weil außer dem LRZ sonst niemand Zertifikate für diese Domain ausstellen kann)
  3. vom freien Markt, z.B. Let's Encrypt

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/36 ), in dem Sie unter Angabe des gewünschten Namens ein Zertifikat beantragen, und fügen den Request als Anlage bei. 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.
  • 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.


Domainvalidierung

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


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:

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.

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

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


Privaten Schlüssel und CSR erzeugen

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:2048 -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:2048 -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ß durch den entsprechenden Domain-Namen ersetzt werden.

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 (bei Nutzerzertifikaten Name des Zertifikatnehmers)
 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 sind, wie üblich, frei wählbar.


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:

Sonstiges

Infos der TUM:http://www.it.tum.de/zertifikate/ und https://www.it.tum.de/faq/it-dienste/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 4.5.2022


English

Pagetitle
Server Certificates (except GRID)
Server Certificates (except GRID)

Table of Contents

Numbered Headings

Introduction

  • This document is about server certificates for units hosted at the LRZ (web hosting or server hosting). You cannot obtain certificates from the LRZ for servers that are neither owned by the LRZ (or the BAdW) nor hosted at the LRZ.
  • In 2022 the certificate issuing instance migrates from DFN-PKI to GÉANT/Sectigo. This will change the certificate chain and the root certificate.
  • Some processes change as well. In particular, a signed PDF is no longer necessary. Everything is now paperless. Existing certificates from the DFN-PKI remain valid until they expire.

Overview

Web-Hosting

Panel
borderColorblack
bgColor#ffd4a0
borderWidth2
borderStylesolid
  1. If you use a custom name for your web server, you must ensure that this name or domain is validated. See below → Domain Validation.
  2. If the domain is validated, you don't need to do anything else. Your web server will get its certificate from us automatically.


Server-Hosting

Panel
borderColorblack
bgColor#ffd4a0
borderWidth2
borderStylesolid

Since you, as the server administrator, are responsible for the certificate itself, you have a choice of who to obtain it from. Essentially, you have the following options:

  1. from your own institution (for TUM: ra@zv.tum.de, for LMU: pki@lmu.de)
  2. from the LRZ (this is especially necessary if the server name ends with srv.mwn.de, because nobody else but the LRZ can issue certificates for this domain)
  3. from the free market like Let's Encrypt

In case 2, the following applies:

  • Wenn die Domain validiert ist, erstellen Sie einen privaten Schlüssel und den Request (siehe unten → Privaten Schlüssel und CSR erzeugen).
  • Once the domain is validated, create a private key and the request (see below → Generate private key and CSR).
  • Then open a ticket ( https://servicedesk.lrz.de/ql/create/36 ) with your SIM account, requesting a certificate by specifying the desired name, and attach the request. We also need a contact e-mail address, preferably a collective or group address, so that e-mails regarding the certificate still reach someone even if you may have left your institution in the meantime.
  • You will then receive a mail from Sectigo (see below), with which you can download your certificate in different formats (different variants of .pem, .cer and .p12).


Domain Validation

Please note: Domain validations are only valid for 1 year and must then be renewed.


For both the DFN-PKI and the new GÉANT/Sectigo environment, we (i.e. the LRZ, but also any other certificate issuer) can only issue certificates for names or domains if we have permission to do so. Technically, the domain must be validated.

Here again there are two cases:

Case 1: Your domain is hosted at the LRZ

Open a ticket with your SIM ID via https://servicedesk.lrz.de/en/ql/create/36 (via Selfservice, not Simple Submit):

aqnd inform us about the desired domain name. For domains hosted by us, we can then do the validation ourselves.

Case 2: Your domain ist hosted elsewhere

Here you need to consider the following:

If you have configured a CAA record for your domain, it must be extended for Sectigo in advance (here at the example of the domain xxx-domain.de):

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

Leave previous entries as they are.

If you have not configured a CAA record, you do not need to do anything further in this regard:

For the validation, you also need a mailbox hostmaster@<Domain>, to which the validation mail is sent.

Then open a ticket with your SIM account via https://servicedesk.lrz.de/en/ql/create/36 and tell us the desired domain name. We then enter the domain for validation at Sectigo and send the validation mail to the above address. If this address does not exist, validation is not possible, at least not easily. If it is not possible for you to set up the mailbox hostmaster@<domain>, please mention this in the ticket. We will then consider if there could be an alternative possibility.


Please note that during the transition period it may be necessary to validate your domain in both the old and new environments.


Creating of Private Key and CSR

Only 1 host name

If the certificate contains only one host name (Common Name - CN), the following command is sufficient:

  • Version with private key without password, generated on the corresponding host (here, for simplicity, it is assumed that the computer name, i.e. the hostname, should also be in the certificate. If not, just write the desired name instead of `hostname`):

openssl req -nodes -newkey rsa:2048 -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 with password-protected private key generated on the corresponding host:

openssl req -newkey rsa:2048 -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"


The names of the output files are of course freely selectable. xxx must be replaced by the belonging domain name.

More than 1 host name

A certificate can contain more or less any number of CNs. These can be aliases of one server or names of several different servers, which then all get the same certificate (and the same private key). Unfortunately, the above openssl command only works with a single CN. If you want more than one name in the certificate, you have to assemble it as follows:

Write a text file (called zert.conf in the example) with the following content (for the 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 (bei Nutzerzertifikaten Name des Zertifikatnehmers)
 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 …


Key and CSR are being created with the following command:

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

The names of the output files are, as usual, freely selectable.


The Download Mail

The download mail looks something like this and offers the certificate in 7 variants for download. For the standard Apache, the second one from above is probably the right one:


Miscellaneous

Infos from TUM:http://www.it.tum.de/zertifikate/ und https://www.it.tum.de/faq/it-dienste/zertifikate/

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




Last update: May 4. 2022