Checkmk
to checkmk.com

1. Voraussetzungen

Wenn Sie die Weboberfläche von Checkmk über HTTPS einsetzen möchten, dann müssen Sie auf Ihrem Monitoring-Server — unabhängig von Ihren Instanzen — folgende Voraussetzungen schaffen:

  • Sie besitzen ein gültiges Server-Zertifikat.

  • Das Apache-Modul mod_ssl ist installiert und aktiviert.

  • Der Server ist über HTTPS erreichbar.

  • Das Rewrite- und das Headers-Modul für den Webserver sind vorhanden und geladen.

Was dafür zu tun ist, erklärt dieser Artikel.

2. Apache-Module aktivieren

2.1. Geladene Module anzeigen

Verwenden Sie das Kommando apachectl (alte CentOS- und RHEL-Versionen benötigen möglicherweise stattdessen httpd), um eine Liste der geladenen Apache-Module anzuzeigen:

root@linux# apachectl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 [...]

Sind in der angezeigten Liste headers_module, rewrite_module und ssl_module bereits geladen, können Sie die nächsten beiden Schritte überspringen.

2.2. Module aktivieren

Die Aktivierung fehlender Module gelingt auf den meisten Distributionen mit dem Script a2enmod. Es legt Softlinks im Ordner /etc/apache2/mods-enabled an. Die Datei mit Endung .load enthält dabei Anweisungen zum Laden des Moduls, .conf die eigentliche Konfiguration des Moduls:

root@linux# a2enmod ssl
Enabling module ssl.
To activate the new configuration, you need to run:
  systemctl restart apache2

Bei älteren Versionen von RHEL und darauf basierenden Distributionen ist `mod_ssl`ein eigenes Paket, das Sie separat installieren müssen:

root@linux# yum install -y httpd mod_ssl

Distributionen mit monolithischer Konfiguration erfordern die Anpassung der Konfigurationsdatei /etc/httpd/conf/httpd.conf dergestalt, dass die auskommentierte Zeile LoadModule ssl_module […​] vom # befreit wird.

2.3. Apache neu starten

Nach der Aktivierung der Module muss der Apache-Webserver neu gestartet werden. Falls Ihre Distribution bereits bei der Apache-Installation ein selbst signiertes Zertifikat für Testzwecke erzeugt hat, werfen Sie bitte einen Blick in die Datei /etc/apache2/mods-enabled/ssl.conf und prüfen Sie. ob die hier angegebenen Zertifikatsdateien vorhanden sind.

Ob bei der Installation oder Aktivierung des SSL-Moduls ein Zertifikat erstellt wurde, erfahren Sie, indem Sie zunächst nach der Konfigurationsdatei suchen, welche die Pfade zu Zertifikat und Schlüsseln enthält und dann prüfen, ob diese Dateien existieren (bei RHEL ist als Startverzeichnis der Suche /etc/httpd anzugeben):

root@linux# find /etc/apache2/ -type f -exec grep -Hn '^\s*SSLCertificate.*File' {} \;
/etc/apache2/sites-available/default-ssl.conf:32: SSLCertificateFile	/etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/apache2/sites-available/default-ssl.conf:33: SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Falls kein automatisch erstelltes Zertifikat vorhanden ist, warten Sie mit dem Neustart des Apache-Webservers, bis Sie ein Zertifikat erhalten oder selbst erstellt haben.

Wurden Schlüssel und Start automatisch erzeugt, starten Sie mit einem der folgenden Befehle den Apache-Webserver neu, beim mittlerweile standardmäßig verwendeten systemd ist der erste Befehl zu verwenden:

root@linux# systemctl restart apache2
root@linux# systemctl restart httpd
root@linux# service apache2 restart
root@linux# /etc/init.d/apache2 restart
root@linux# /etc/init.d/httpd restart

3. Zertifikate erhalten

Im Wesentlichen existieren die folgenden Methoden, um an ein Server-Zertifikat zu gelangen:

  • Sie bezahlen für die Zertifikatsausstellung mittels CSR (Certificate Signing Request). Je nach Stufe der Validierung wird nur geprüft, ob Sie Webmaster einer Domain sind oder es müssen Handelsregisterauszüge eingereicht werden. Nachteil: das Verfahren kostet Geld und verursacht Verwaltungsaufwand.

  • Sie nutzen kostenlose Zertifikate von Letsencrypt. Nachteil: Sie müssen entweder Zugriff auf den Server haben, dessen Zertifikate Sie ausstellen wollen (und der muss von außen erreichbar sein), oder Sie müssen im Nameserver Ihrer Domain Einträge anlegen und ändern können.

  • Sie werden Ihre eigene Certificate Authority (CA) und erzeugen Zertifikate selbst. Nachteil: Sie müssen strikte Sicherheitsregeln einhalten und die CA in die Browser der Nutzer importieren, die Checkmk verwenden sollen.

3.1. Zertifikate per CSR erhalten

Zertifikate bei einer kommerziellen Certificate Authority signieren zu lassen, war lange Zeit der einzige Weg, von allen Browsern und Betriebssystemen akzeptierte Zertifikate zu erhalten. Dieses Verfahren ist heute insbesondere dann noch üblich, wenn lange Gültigkeitszeiträume oder Validierung auf Organisationsebene (Organization Validation, kurz OV) oder höher (Extended Validation, kurz EV) erwünscht ist.

Die Kosten für dieses Verfahren liegen zwischen gratis (3 Monate Gültigkeit, ein Hostname), wenigen Euro (12 Monate, ein Hostname) und mehreren hundert Euro (24 Monate, mehrere Hostnamen, Validierung auf Organisationsebene).

Schlüssel und CSR erzeugen

Der Standardweg ist, zunächst den privaten Server-Schlüssel zu erzeugen. Diesen Schritt können Sie direkt auf dem Server durchführen können, auf dem Ihre Checkmk-Instanz läuft:

root@linux# mkdir /etc/certs
root@linux# cd /etc/certs
root@linux# openssl genrsa -out checkmk.mydomain.com.key 2048

Im nächsten Schritt erstellen Sie das "Certificate Signing Request":

root@linux# openssl req -new -key checkmk.mydomain.com.key -out checkmk.mydomain.com.csr
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]: Bavaria
Locality Name (eg, city) []: Munich
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Yoyodyne Inc.
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []: checkmk.mydomain.com
Email Address []: webmaster@mydomain.com

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

Achten Sie darauf, die Angaben zum Unternehmen korrekt anzugeben und als Common Name den Server-Namen einzutragen. Die eingetragene E-Mail-Adresse sollte in derselben Domain liegen und zu einem existierenden und gelesenen Postfach gehören.

Die CSR-Datei wird anschließend per Webformular an den von Ihnen ausugewählten Zertifikatsdienstleister übertragen. Je nach Validierungsstufe kann es sein, dass zusätzliche Dokumente wie ein Handelsregistereintrag beigefügt werden müssen. Im einfachsten Fall der reinen Domain-Validierung besteht diese darin, dass eine E-Mail mit Bestätigungslink an webmaster@mydomain.com oder postmaster@mydomain.com geschickt wird. Das fertige Zertifikat kann dann aus dem Webfrontend des Dienstleisters heruntergeladen werden oder es wird ebenfalls per E-Mail zugestellt.

Upload des CSR

Die folgenden Screenshots zeigen beispielhaft die wesentlichen Schritte bei Verwendung der Online-Formulare des Dienstleisters ZeroSSL. Die Verlinkung stellt dabei keine Empfehlung dar, ZeroSSL eignet sich jedoch der wegen drei möglichen 90-Tage-Gratis-Zertifikate pro Nutzerkonto gut für Tests. Die folgenden Screenshots zeigen die für die Zertifikatsanforderung relevanten Schritte

Zunächst wird die Domain angegeben, für die das Zertifikat ausgestellt werden soll. Je nach Dienstleister sind auch Multidomain-Zertifikate mit unterschiedlicher Flexibilität (und Preisgestaltung) möglich:

omd https zerossl step01

Es folgt der Upload des zuvor erzeugten CSR. Einige Zertifizierungsstellen bieten an, Schlüssel und CSR online zu erzeugen. Verzichten Sie aus Sicherheitsgründen darauf und laden Sie die selbst erzeugte Signierungsanfrage hoch:

omd https zerossl step02

Erhalten des Zertifikates

Meist müssen Sie jetzt die Laufzeit angeben (und sich damit für ein Preismodell entscheiden) und daraufhin die E-Mail-Adresse wählen, an die ein Validierungslink oder ein Token (Zeichenkette) für die Eingabe in ein Formular verschickt wird.

omd https zerossl step03

Befolgen Sie die Anweisungen in der E-Mail an die ausgewählte Adresse. So gelangen Sie zu einem Link zum Download des Zertifikates oder Sie bekommen das Zertifikat in einer weiteren E-Mail zugeschickt.

omd https zerossl step04

In unserem Fall enthielt das heruntergeladene Zip-Archiv zwei Dateien: certificate.crt (das eigentliche Zertifikat) und ca_bundle.crt, die Verkettung ein oder mehrerer Intermediate-Zertifikate. Sie können mit diesen beiden Dateien nun die Konfiguration des Apache-Servers durchführen.

3.2. Letsencrypt

Ist ein Server von außen erreichbar oder haben Sie Zugriff auf den Nameserver, können Sie automatisiert Zertifikate über den zu der Electronic Frontier Foundation (EFF) gehörenden Non-Profit-Dienstleister Letsencrypt erstellen lassen. Es entstehen keine Kosten. Per DNS validierte Zertifikate erfordern alle 90 Tage wenige Minuten Aufmerksamkeit, per Server-Verzeichnis validierte Zertifikate können Jahre lang automatisch neu erzeugt werden.

Für Letsencrypt-Zertifikate stellt die EFF das Python-Programm Certbot in vielen verschiedenen Paketformaten bereit. Der Certbot übernimmt die Erstellung des Schlüssels, den Versand der CSR und die Prüfung der Inhaberschaft von Server oder Domain. Er kommuniziert hierfür über das Protokoll Automatic Certificate Management Environment (ACME) mit den Servern der EFF.

Installation des Certbot-Scriptes

Es existieren drei Möglichkeiten, Certbot zu installieren. Welche Sie wählen, dürfte vor allem vom Alter der eingesetzten Distribution und den Policies in Ihrem Unternehmen zur Installation aus fremden Paketquellen abhängen:

  • Die EFF empfiehlt auf der Certbot-Dokumentationsseite die Installation aus einem Snap-Image. Vorteil der Lösung ist, dass immer ein aktueller Certbot bereitsteht und Abhängigkeiten (beispielsweise zur benötigten Python-Version) problemlos aufgelöst werden. Nachteil der Lösung ist, dass eine Pakete als Dubletten installiert werden und der Platzbedarf relativ hoch ist.

  • Certbot ist über sind über das Python-Paketinstallationstool pip3 aus dem Python Package Index installierbar. Der Befehl pip3 install certbot installiert alle abhängig benötigten Python-Module.

  • Falls Sie eine über das Paketmanagement Ihrer Distribution bereitgestellten Certbot-Version installieren wollen, informieren Sie sich über mögliche Einschränkungen: So implementiert Certbot 0.40 in Ubuntu 20.04 zwar das erforderliche ACME v2 Protokoll, unterstützt aber keine ECDSA signierten Zertifikate, was bei Certbot 1.21 in Ubuntu 22.04 der Fall ist.

Hinweis: Certbot 0.40 aus Ubuntu 20.04 war die früheste Certbot-Version, mit der wir Stand März 2022 ohne Änderung der Konfiguration Letsencrypt-Zertifikate anfordern konnten. Ältere Versionen mögen ACME v2 fähig sein, decken aber unter Umständen nicht den kompletten Funktionsumfang von ACME v2, lassen DNS-Plugins vermissen oder erfordern teils manuelle Konfiguration.

Vollautomatische Konfiguration

Falls der Checkmk-Server aus dem Internet erreichbar ist und Sie an der Konfiguration des systemweiten Apache Webservers seit der Installation von Checkmk keine Änderung vorgenommen haben, können Sie den "Apache-Automatismus" von Certbot verwenden, um Schlüssel zu erzeugen, Zertifikate anzufordern, die Apache-Konfiguration automatisch anzupassen und schließlich einen Cronjob einzurichten, um regelmäßig die 90 Tage laufenden Zertifikate zu erneuern.

root@linux# certbot --apache

Das Script fragt nun interaktiv einige Informationen zu Kontaktdaten (E-Mail-Kontakt für zusätzliche Informationen wie notwendige Zertifikatsrückrufe) und Installationspfaden ab, am Ende steht die funktionsfähige SSL-Konfiguration.

Da die Parameter des Scriptes gelegentlichen Änderungen unterworfen sind, empfehlen wir, der jeweils aktuellen Anleitung in der Certbot-Dokumentation (hier für Ubuntu 20.04, andere Betriebssysteme per Dropdown auswählbar) zu folgen.

Teilautomatische Konfiguration über Webroot

Ist der Checkmk-Server zwar aus dem Internet erreichbar, aber Sie wollen oder können keine automatische Konfigurationsänderung vornehmen, kann das Certbot-Skript zwar Schlüssel generieren und Zertifikate anfordern, aber die restliche Konfiguration überspringen. Sie müssen die weitere Konfiguration dann manuell vornehmen und können die Zertifikate auch für andere Dienste einbinden, die Sie auf dem Checkmk-Server verwenden – zum Beispiel einen Mailserver für Benachrichtigungen.

Zunächst sollten Sie sicherstellen, dass für das Wurzelverzeichnis des Webservers keine Weiterleitung existiert oder zumindest der Ordner .well-known hiervon ausgenommen ist. In diesem Ordner legt das Certbot-Skript eine Datei mit an, deren Inhalt von den Letsencrypt-Servern vorgegeben wird. Mit dem Abruf der Datei können die Letsencrypt-Server dann bestätigen, dass derjenige, der das Zertifikat anfordert, Schreibrechte im Webroot des Servers hat.

Jetzt erzeugen Sie per certbot Schlüssel und fordern Zertifikate für die verwendete Domain an. Der erste Aufruf des Scriptes erfolgt interaktiv:

root@linux# certbot certonly --webroot -w /var/www/html -d checkmk.mydomain.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): johndoe@mydomain.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for checkmk.mydomain.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/checkmk.mydomain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/checkmk.mydomain.com/privkey.pem
[...]

Künftige Aufrufe des Skriptes können dann ohne Interaktion erfolgen, hierfür ist der Parameter -n hinzuzufügen. Manuell auf einem System mit länger als 30 Tage gültigem Zertifikat aufgerufen, wird die Information ausgeben, dass keine Erneuerung notwendig ist:

root@linux# certbot certonly -n --webroot -w /var/www/html -d checkmk.mydomain.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal; no action taken.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Um Zertifikate automatisch zu erneuern, erstellen Sie ein Shellscript, welches zunächst den letzten Befehl ausführt und anschließend den Apache-Webserver neustartet. Lassen Sie dieses Skript einmal pro Woche von einem Cronjob aufrufen, um rechtzeitig vor Zertifikatsablauf ein neues Zertifikat zu erhalten.

Sie können nun mit den Dateien in /etc/letsencrypt/live/checkmk.mydomain.com die Konfiguration des Apache-Servers durchführen.

Teilautomatische Konfiguration über DNS

Ist der Checkmk-Server beispielsweise nur aus dem Intranet oder per VPN erreichbar, aber der DNS-Server öffentlich, können Sie die Validierung über eine "DNS-Challenge" vornehmen. Hier wird die Inhaberschaft einer Domain nicht darüber geprüft, Dateien auf dem Webserver ablegen zu können, sondern darüber, dass Sie Einträge im DNS hinzufügen können. Dabei kommen keine Einträge zur Anwendung, die einen Hostnamen zu einer IP-Adresse auflösen, sondern sogenannte TXT-Einträge, die beliebige Zeichenketten enthalten können. TXT-Einträge werden beispielsweise auch verwendet, um anzugeben, welche Server Mail für eine Domain versenden dürfen.

Die Anforderung der Letsencrypt-Zertifikate muss nicht zwangsläufig auf dem Computer stattfinden, der als Checkmk-Server dient. Falls Sie die Anforderung von einem anderen Rechner aus durchführen, müssen Sie die Zertifikate und Schlüssel in /etc/letsencrypt anschließend mit rsync oder scp auf den Checkmk-Server kopieren.

Das erste Zertifikat fordern Sie komplett manuell an:

root@linux# certbot certonly --manual --preferred-challenges dns -d 'checkmk.mydomain.com'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): johndoe@mydomain.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for checkmk.mydomain.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.checkmk.mydomain.com with the following value:

cF1LxTIHTk6Fw5y_3nEJ3gr_7sskm5NuugXwnmP10Ps

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

Kopieren Sie nun die Zeichenkette und legen Sie einen entsprechenden TXT-Eintrag im DNS Ihrer Domain an. Eine Time To Live von 600 oder 300 Sekunden verringert bei künftigen Aktualisierungen die maximale Wartezeit:

omd https letsencrypt dns

Prüfen Sie nun an einem beliebigen Rechner, ob der Eintrag erfolgreich hinterlegt wurde:

johndoe@localhost:~$ dig -t TXT _acme-challenge.checkmk.mydomain.com
[...]
;; ANSWER SECTION:
_acme-challenge.checkmk.mydomain.com.	600 IN TXT "cF1LxTIHTk6Fw5y_3nEJ3gr_7sskm5NuugXwnmP10Ps"

;; Query time: 64 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fr Apr 01 14:35:29 CEST 2022
;; MSG SIZE  rcvd: 123

Ist der Eintrag noch nicht hinterlegt, warten Sie ein paar Minuten und versuchen es dann erneut. Wenn alles geklappt hat, schließen Sie die Zertifikatsanforderung durch Drücken der Eingabetaste ab:

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/checkmk.mydomain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/checkmk.mydomain.com/privkey.pem
[...]

Sie können nun mit den Dateien in /etc/letsencrypt/live/checkmk.mydomain.com die Konfiguration des Apache-Servers durchführen.

Wenn die erstmalige manuelle Anforderung der Zertifikate erfolgreich war, können Sie rechnerchieren, ob Ihr DNS-Anbieter über ein Certbot-Plugin verfügt, das Automatisierung zulässt und die künftige Aktualisierung der Zertifikate per Cronjob vornehmen.

3.3. Selbst Certificate Authority werden

Sie können sich selbst in die Rolle einer CA versetzen und Zertifikate für beliebige Domains (Ihre Domains, fremde Domains und Phantasie-Domains) ausstellen. Allerdings muss ein Vertrauensverhältnis zwischen den Clients und der eigenen Zertifizierungsstelle existieren. Wie Sie dieses herstellen, erklären wir am Ende des Kapitels.

Der Weg über die eigene CA ist vor allem für Testumgebungen oder abgeschottete Checkmk-Server mit überschaubarer Nutzerzahl sinnvoll. Sie ist zudem die einzige Möglichkeit, Zertifikate zu erhalten, wenn Sie intern eine der fünf reservierten TLDs .example, .invalid, .local, .localhost, oder .test verwenden. Für diese Domains gibt es keine Registrare, folglich kann keine Inhaberschaft bestätigt werden.

Selbst wenn eine Person auf einem Rechner alle Schritte durchführt: Um die Rollenverteilung im Zertifizierungsprozess zu verdeutlichen, nutzen wir Carla als Verwalterin der Certificate Authority, Bob als Betreuer des Intermediate Keys und schließlich Alice, die Administratorin, die Server-Zertifikate signieren lässt.

Sicherheitshinweise

  • Diese Anleitung verzichtet auf die Verwendung einer Certificate Revocation List. In größeren Produktivumgebungen sollten Sie eine verwenden, um kompromittierten Schlüsseln schnell das Vertrauen entziehen zu können!

  • Auch in Testumgebungen gilt, dass starke Passwörter verwendet und private Schlüssel gut gesichert werden müssen, denn mit dem verwendeten CA-Schlüssel können Zertifikate für beliebige Domains erstellt werden. Systeme, die dem Zertifikat eines "verlorenen" Schlüssels vertrauen, sind damit anfällig für Woman-in-the-Middle-Angriffe!

Schlüssel für die CA und Root-Zertifikat erstellen

Carla nutzt aus Sicherheitsgründen ein Notebook ohne Internetverbindung, um den Root-Schlüssel der CA zu erzeugen und Zwischenzertifikate zu signieren. Zunächst erstellt sie unter /home/carla/ca die Verzeichnisstruktur für die Zertifizierungsstelle:

carla@nb:~$ for d in certs newcerts crl private ; do mkdir -p ~/ca/$d ; done
carla@nb:~$ for f in index.txt serial ; do touch ~/ca/$f ; done

Im Ordner ~/ca/ legt sie eine Datei ca.cnf ab, von der wir ein Beispiel vorbereitet und am Ende dieses Artikels angehängt haben. Anschließend erstellt sie den privaten Schlüssel der CA, der AES256-verschlüsselt abgelegt und mit einer langen Passphrase versehen wird:

carla@nb:~$ cd ca
carla@nb:~/ca$ openssl genrsa -aes256 -out private/ca.key.pem 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
.............++++
..........++++
e is 65537 (0x010001)
Enter pass phrase for private/ca.key.pem:
Verifying - Enter pass phrase for private/ca.key.pem:

Es folgt das Root-Zertifikat, hier mit einer Gültigkeit von zwölf Jahren und zwei Wochen – mehr zur Wahl der Gültigkeitszeiträume weiter unten. Die relevanten Parameter für Ort und Unternehmen werden aus der Konfigurationsdatei ca.cnf übernommen. Common Name und Email Address sind auf sinnvolle Werte zu setzen:

carla@nb:~/ca$ openssl req -config ca.cnf  -new \
    -key private/ca.key.pem -x509 -days 4398 \
    -sha256 -extensions v3_ca -out certs/ca.cert.pem
Enter pass phrase for private/ca.key.pem:
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) [DE]:
State or Province Name [Bavaria]:
Locality Name [Munich]:
Organization Name [Stark Industries Ltd.]:
Organizational Unit Name []:
Common Name []: Stark Industries Root Certificate
Email Address []: carla@starkindustries.test

Anschließend prüft Carla das Root-Zertifikat mit dem Befehl:

carla@nb:~/ca$ openssl x509 -noout -text -in certs/ca.cert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:a0:77:02:e7:29:07:f7:b5:d5:ba:b5:a3:4e:2b:eb:b3:e7:a6:c0
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = DE, ST = Bavaria, L = Munich, O = Stark Industries Ltd., CN = Stark Industries Root Certificate, emailAddress = carla@starkindustries.test
        Validity
            Not Before: Feb 15 14:52:12 2022 GMT
            Not After : Mar 2 14:52:12 2034 GMT
        Subject: C = DE, ST = Bavaria, L = Munich, O = Stark Industries Ltd., CN = Stark Industries Root Certificate, emailAddress = carla@starkindustries.test
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:d7:a9:89:94:dd:02:66:bf:fd:8e:c2:70:4b:d0:
[...]

Carla kopiert die Konfigurationsdatei ca.cnf und stellt sie dem Kollegen Bob zur Verfügung, damit er eine Vorlage hat, die passende Parameter sowie Unternehmensnamen und -standort in korrekter Schreibweise enthält.

Das Intermediate-Zertifikat

Bob ist derjenige, der die tägliche Arbeit mit Zertifikaten für das lokale Netzwerk durchführt. Seine Aufgabe ist es, mit einem Intermediate-Zertifikat die Server-Schlüssel zu signieren, die Administratorinnen und Administratoren an ihn herantragen. Auch er erstellt zunächst eine Verzeichnisstruktur und verwendet dafür den Ordner im in seinem Heimatverzeichnis:

bob@pc:~$ for d in certs newcerts crl private ; do mkdir -p ~/im/$d ; done
bob@pc:~$ for f in index.txt serial ; do touch ~/im/$f ; done

Im Ordner im legt er die von Carla erhaltene Konfigurationsdatei als im.cnf ab und passt darin die Standardpfade auf sein Heimatverzeichnis und seine Rolle an. Anschließend erstellt auch er einen Private Key, mit dem er die nächsten Jahre arbeiten wird:

bob@pc:~$ cd im
bob@pc:~/im$ openssl genrsa -aes256 -out private/im.key.pem 4096

Im nächsten Schritt erstellt er das Certificate Signing Request für diesen Schlüssel:

bob@pc:~/im$ openssl req -config im.cnf -new -sha256 \
    -key private/im.key.pem -out certs/imbob.csr
[...]
Country Name (2 letter code) [DE]:
State or Province Name [Bavaria]:
Locality Name [Munich]:
Organization Name [Stark Industries Ltd.]:
Organizational Unit Name []:
Common Name []: Bobs Intermediate Certificate
Email Address []: bob@starkindustries.test

Mit der Datei imbob.csr geht Bob auf einen Kaffee zu Carla ins Büro. Diese holt das Notebook mit der CA aus dem Tresor, kopiert Bobs CSR in ihren Ordner certs und signiert Bobs CSR – hier mit einer Laufzeit von vier Jahren und zwei Wochen:

carla@nb:~$ cd ca
carla@nb:~/ca$ openssl ca -config ca.cnf \
    -extensions v3_intermediate_ca \
    -days 1476 -rand_serial -notext -md sha256 \
    -in certs/imbob.csr -out certs/imbob.pem

Nun wird die Passphrase des Schlüssels abgefragt, der Inhalt des Certificate Signing Requests angezeigt und nach Bestätigung das Intermediate Certificate erstellt. Carla gibt Bob nun die beiden PEM-Dateien ca.cert.pem (das Zertifikat der Certificate Authority) und imbob.pem (das Intermediate Certificate) mit, fährt das Notebook wieder herunter und packt es in den Tresor. Zurück an seinem Rechner packt Bob beide Dateien in den Ordner ~/im/certs.

Schlüssel für die Checkmk-Instanz erstellen

Alice ist Administratorin der Checkmk-Server bei Stark Industries Ltd. Für die Absicherung eines neuen Checkmk-Servers erstellt sie zunächst den Server-Schlüssel. Hier ist es pragmatisch, keine Passphrase zu verwenden, also auf -des3 oder -aes256 zu verzichten. Sonst müsste diese Passphrase bei jedem Start des Servers eingegeben werden. Als Dateiname ist der Host-Name des Servers sinnvoll.

alice@pc:~$ openssl genrsa -out checkmk.starkindustries.test.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.................................++++
.......++++
e is 65537 (0x010001)

Es folgt die Erstellung des CSR. Wieder müssen die Fragen nach Firma und Abteilung beantwortet werden. Wichtig ist hier der Common Name, welcher dem Host-Namen des Servers entsprechen muss. Eine Konfigurationsdatei ist für Alice optional:

alice@pc:~$ openssl req -new -key checkmk.starkindustries.test.key \
    -out checkmk.starkindustries.test.csr
[...]
Country Name (2 letter code) [DE]:
State or Province Name [Bavaria]:
Locality Name [Munich]:
Organization Name [Stark Industries Ltd.]:
Organizational Unit Name []:
Common Name (e.g. server FQDN or YOUR name) []: checkmk.starkindustries.test
Email Address []: alice@starkindustries.test

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

Das Challenge-Passwort darf leer bleiben. Da der Checkmk-Server unter verschiedenen Host-Namen erreichbar ist, erstellt Alice eine X509 V3 certificate extension Konfigurationsdatei checkmk.starkindustries.test.ext:

/home/alice/checkmk.starkindustries.test.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = checkmk.starkindustries.test
DNS.2 = monitoring.starkindustries.test

Signieren eines Zertifikates

Mit den beiden Dateien checkmk.starkindustries.test.csr und checkmk.starkindustries.test.ext im Gepäck lädt sich Alice bei Bob auf einen Becher grünen Tee in dessen Büro ein. Bob signiert nun mit seinem Intermediate-Zertifikat das mitgebrachte CSR mit einem Jahr Gültigkeit:

bob@pc:~$ cd im
bob@pc:~/im$ openssl x509 -CAcreateserial -req \
    -in certs/checkmk.starkindustries.test.csr \
    -CA certs/imbob.pem -CAkey private/im.key.pem \
    -out certs/checkmk.starkindustries.test.crt -days 365 \
    -sha256 -extfile certs/checkmk.starkindustries.test.ext

Alice erhält von Bob drei Dateien: ca.cert.pem und imbob.pem stellen die Zertifikatskette dar und checkmk.starkindustries.test.crt ist das zum Serverschlüssel checkmk.starkindustries.test.key gehörende Zertifikat. Diese Dateien kann sie bereits auf dem Server ausrollen.

Importieren der CA

Die Wege, ein CA Zertifikat als vertrauenswürdig zu importieren, unterscheiden sich von Browser zu Browser. Meist genügt es, das Zertifikat ca.cert.pem unter Einstellungen > Datenschutz und Sicherheit > Zertifikate > Importieren hinzuzufügen.

Damit die Zertifikatsverwaltung kein Stolperstein beim automatischen Agenten-Update darstellt, haben wir in der Agentenbäckerei die Möglichkeit vorgesehen, ein eigenes CA-Zertifikat zu übergeben, das nur für Agenten-Updates benutzt wird. Die Systemzertifikate werden hierbei nicht angetastet, Agenten-Updates sind dennoch möglich.

Alternativ zur Verteilung per Agenten-Update können Sie das Root-Zertifikat in der lokalen CA-Datenbank des Hosts integrieren. Kopieren Sie dafür die Datei ca.cert.pem nach /usr/local/share/ca-certificates/starkindustries.crt. Anschließend generieren Sie den Cache neu:

root@linux# update-ca-certificates

Unter Windows ist es möglich, die Systemzertifikate über das MMC-Snap-In "Certificates" zu verwalten. Dies ist beispielsweise nötig, wenn Sie einen Microsoft-Browser verwenden wollen, um auf ein mit eigener CA abgesichertes Checkmk zuzugreifen. Das genaue Vorgehen können Sie im Microsofts Knowledge Base Artikel PKI nachlesen. Alternativ können Sie Zertifikate per Intune verteilen.

Zertifikatslaufzeit und -kaskaden

Die gesamte Zertifikatskaskade funktioniert nur, während alle Zertifikate gültig sind. Daher sollte über Laufzeiten Buch geführt und an jeder Stelle der Kette rechtzeitig ein neues Zertifikat erstellt werden. Wenn die Laufzeit von Carlas Root-Zertifikat zwölf Jahre beträgt und sie damit maximal vier Jahre gültige Intermediate-Zertifikate für Bob ausstellt, muss sie sich rechtzeitig vor Ablauf von acht Jahren ein neues Root-Zertifikat ausstellen und künftig dieses zum Signieren benutzen. Bob wiederum, der maximal zwei Jahre gültige Zertifikate ausstellt, muss alle zwei Jahre auf einen Kaffee bei Carla vorbeischauen, um ein neues, vier Jahre gültiges Zertifikat zu erhalten.

Alice weiss, dass Bob nur zwei Jahre gültige Server-Zertifikate ausstellen kann. Sollte Alice im Zuge der Expansion von Stark Industries sehr viele Server-Zertifikate benötigen, kann Bob als Inhaber eines Intermediate-Zertifikats für Alice ein weiteres Intermediate-Zertifikat mit zwei Jahren Gültigkeit erstellen. So kann Alice dann in die Rolle einer ihm untergeordneten CA schlüpfen, die Zertifikate mit einem Jahr Gültigkeit ausstellt. In diesem Fall muss sie jährlich bei Bob vorbeischauen.

Im unten beschriebenen Konfigurationsbeispiel muss dann nicht Bobs Intermediate-Zertifikat auf dem Server platziert werden, sondern eine Konkatenation aus Bobs und Alice' Intermediate-Zertifikaten.

4. Konfiguration der HTTPS-Verbindung für eine Instanz

Zunächst müssen Sie in der SSL-Konfigurationsdatei die korrekten Pfade zu Schlüssel, Zertifikat und Intermediate-Zertifikat angeben. Die Konfigurationsdatei ist in der Regel /etc/apache2/sites-enabled/default-ssl.conf, der Pfad kann jedoch bei älteren Distributionen abweichen.

4.1. Zertifikat wurde von kommerzieller Zertifizierungsstelle ausgestellt

Falls Sie Zertifikate von einem kommerziellen Anbieter signieren lassen haben, hat Ihnen dieser auch mitgeteilt, ob ein SSLCertificateChainFile benötigt wird und dieses gegebenenfalls mitgeschickt. Im oben gezeigten Beispiel mit ZeroSSL sähe die Konfiguration wie folgt aus:

/etc/apache2/sites-enabled/default-ssl.conf
SSLEngine on
SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crt

4.2. Zertifikat wurde mithilfe von Letsencrypt generiert

Der Letsencrypt-Certbot legt Zertifikate und automatisch erzeugte Schlüssel in /etc/letsencrypt ab:

/etc/apache2/sites-enabled/default-ssl.conf
SSLEngine on
SSLCertificateKeyFile /etc/letsencrypt/live/checkmk.starkindustries.test/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/checkmk.starkindustries.test/chain.pem
SSLCertificateFile /etc/letsencrypt/live/checkmk.starkindustries.test/cert.pem

4.3. Zertifikat wurden mit eigener CA ausgestellt

/etc/apache2/sites-enabled/default-ssl.conf
SSLEngine on
SSLCertificateKeyFile /etc/certs/checkmk.starkindustries.test.key
SSLCertificateChainFile /etc/certs/imbob.pem
SSLCertificateFile /etc/certs/checkmk.starkindustries.test.crt

4.4. Konfiguration der Apache Default Site

Die VirtualHost-Konfiguration befindet sich — je nach eingesetzter Distribution — in einer dieser Dateien:

Debian, Ubuntu

/etc/apache2/sites-enabled/000-default(.conf)

RHEL, CentOS

/etc/httpd/conf.d/ssl.conf

SLES

/etc/apache2/httpd.conf

Ergänzen Sie im Abschnitt für den VirtualHost folgende Zeilen:

/etc/apache2/sites-enabled/000-default
RewriteEngine On
# No forwarding for .well-known when using LetsEncrypt
RewriteCond %{REQUEST_URI} !^/.well-known
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]
# This section passes the system Apaches connection mode to the
# instance Apache. Make sure mod_headers is enabled, otherwise it
# will be ignored and "Analyze configuration" will issue "WARN".
<IfModule headers_module>
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
</IfModule>

Nach der Konfigurationsänderung muss der Webserver neu gestartet werden. Je nach eingesetzter Distribution sind die Befehle dafür unterschiedlich:

root@linux# systemctl restart apache2 # Debian/Ubuntu, systemd
root@linux# systemctl restart httpd # RHEL and derivatives, systemd
root@linux# service apache2 restart # Ubuntu, upstart
root@linux# /etc/init.d/apache2 restart # Debian/Ubuntu, SysV init
root@linux# /etc/init.d/httpd restart # RHEL and derivatives, SysV init

5. Zusätzliche Optionen

5.1. HSTS einrichten

Den Checkmk-Server nur noch mittels HTTPS erreichbar zu machen, ist der erste und wichtigste Schritt, um Verbindungen zum Monitoring abzusichern. Erhöhen kann man die Sicherheit aber mit zusätzlichen, optionalen Einstellungen. So kann der Webserver dem Browser mitteilen, dass er in Zukunft bitte nur noch über HTTPS angesprochen werden soll und eine ungesicherte Verbindung über HTTP immer abgelehnt wird.

Diese Technik nennt sich HTTP Strict Transport Security (HSTS) und wird für einen bestimmten Zeitraum in Sekunden gesetzt. Ist dieser Zeitraum abgelaufen, prüft der Browser erneut, ob die Limitierung über HSTS weiterhin gültig ist.

Besonderheiten

Die Einrichtung von HSTS hat nicht nur den Vorteil der Sicherstellung, dass nur sichere Verbindungen genutzt werden. Der Einsatz bringt auch bestimmte Besonderheiten mit sich, derer man sich vor der Umstellung bewusst sein muss:

  • Ist der Eintrag zu dem HSTS einmal vom Browser des Benutzers angelegt, kann er — zumindest vor Ablauf der Zeit — nur mit entsprechendem Detailwissen zu dem jeweiligen Browser entfernt werden. Beachten Sie, dass viele Benutzer dieses Wissen nicht haben.

  • Die Verbindung wird u.a. dann abgelehnt, wenn das Zertifikat abgelaufen ist oder durch ein selbst-signiertes ausgetauscht wurde. Solche Seiten können auch nicht mit einer Ausnahme zum temporären Vertrauen eines Zertifikates aufgerufen werden.

  • HSTS wird umgekehrt nur dann berücksichtigt, wenn dem Zertifikat beim ersten Verbindungsaufbau vertraut wird. Ansonsten legt der Browser keinen Eintrag zum HSTS an, so dass der zusätzliche Schutzmechanismus nicht benutzt wird.

Konfiguration des Apache-Webservers

Um die Option zu setzen, fügen Sie den folgenden Eintrag der HTTPS-Konfiguration hinzu. Unter Debian/Ubuntu ist das standardmäßig die Datei default-ssl.conf:

/etc/apache2/sites-enabled/default-ssl.conf
Header always set Strict-Transport-Security "max-age=43200"

Wichtig: Setzen Sie zunächst einen kurzen Zeitraum — z.B. 600 Sekunden --, um die Einstellung zu testen, da es sein kann, dass ansonsten die Verbindung im Fehlerfall für einen sehr langen Zeitraum abgelehnt wird! Mehr dazu auch bei den Besonderheiten.

Um zu sehen, ob die neue Einstellung funktioniert, können Sie mit Hilfe des Programms curl den Server abrufen. Hier in der Ausgabe nur die ersten 4 Zeilen:

root@linux# curl -I https://myHost/mySite/check_mk/login.py
HTTP/1.1 200 OK
Date: Tue, 01 Jun 2021 09:30:20 GMT
Server: Apache
Strict-Transport-Security: max-age=3600

6. Appendix

Die Konfigurationsdatei /home/carla/ca/ca.cnf kopiert (und überschreibt damit) viele Abschnitte der systemweiten openssl.cnf. Kopieren Sie diese Datei als Basis für die eigene CA-Konfiguration (zurück zur Schlüsselerzeugung). Passen Sie dann zunächst die Verzeichnisse (im Abschnitt [ CA_default ]) und die Firmendaten (im Abschnitt [ req_distinguished_name ]) an.

/home/carla/ca/ca.cnf
# OpenSSL root CA configuration file.
# Copy to `/home/username/ca/ca.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = /home/carla/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = DE
stateOrProvinceName_default     = Bavaria
localityName_default            = Munich
0.organizationName_default      = Stark Industries Ltd.
organizationalUnitName_default  =
emailAddress_default            =

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
Auf dieser Seite