Checkmk
EnglishEspañolFrançaisItaliano日本語
Cloud (SaaS)Cloud master2.4.02.3.02.2.02.1.02.0.01.6.0
Unsere KI-RichtlinieKI

1. Einleitung

Der Hauptgrund für die Absicherung der Weboberfläche von Checkmk ist meistens der Sicherheitsaspekt: Im Monitoring können viele Daten anfallen, welche potentiellen Angreifern zeigen, welche Ziele lohnenswert und welche Angriffsvektoren Erfolg versprechend sind. Diese übertragenen Daten sollen von Dritten weder eingesehen noch manipuliert werden können. Aus diesem Grund sollte es selbstverständlich sein, zumindest Monitoring-Instanzen, die über öffentliche Netze erreichbar sind, mit HTTPS abzusichern.

Tip

Auch beim Einsatz innerhalb vertrauenswürdiger Umgebungen trägt die konsequente Verwendung von HTTPS zur reibungslosen Checkmk-Nutzung bei.

Die Standard-Sicherheitseinstellungen aller modernen Browser sperren bei vielen Kombinationen aus HTTP und HTTPS die unverschlüsselte Komponente oder erzwingen ein Upgrade der Verbindung zu HTTPS. Beispielsweise können Sie keine per HTTP geladenen Dashboards in Inline Frames von Seiten einbetten, die per HTTPS geladen wurden (Mixed content). Zudem ist keine Weiterleitung von HTTPS nach HTTP möglich, was relevant ist, wenn externe Authentifizierung genutzt wird. Des Weiteren sperren die meisten Browser den Zugriff auf die Zwischenablage per JavaScript, was Kopierknöpfe unbrauchbar macht.

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.

  • Die Apache-Module mod_rewrite und mod_headers sind vorhanden und ebenfalls aktiviert.

  • Der Server ist über HTTPS erreichbar.

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

2. Zertifikate erhalten

Da viele Distributionen Phantasiepfade zu Zertifikaten, Ketten und Schlüsseln in ihrer Standardkonfiguration eingetragen haben, ist es sinnvoll, zuerst Zertifikate zu beschaffen und danach die Konfiguration des Apache-Webservers anzugehen.

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

  • Sie nutzen kostenlose Zertifikate von Let’s Encrypt. Dieses Verfahren erlaubt nur eine Validierung auf Domain-Ebene. Um Zertifikate anfordern zu können, muss der abzusichernde Server von außen erreichbar sein oder Sie müssen die Möglichkeit haben, (automatisiert) Einträge im öffentlichen DNS der verwendeten Domain anzulegen.

  • Sie greifen auf einen externen Dienstleister für die Zertifikatsausstellung mittels CSR (Certificate Signing Request) zurück, dessen Root-Zertifikat von Browser- und Betriebssystemherstellern vertraut wird. Mit diesem Verfahren können Zertifikate nicht nur auf Ebene einer Domain validiert werden, sondern auch auf Organisationsebene (Organization Validation) und höher (Extended Validation), wie es in einigen Branchen aus regulatorischen Gründen verpflichtend ist.

  • Sie werden Ihre eigene Certificate Authority (CA) und erzeugen Zertifikate selbst. Das Root-Zertifikat der eigenen CA muss auf allen Rechnern vorhanden sein, die mit Servern kommunizieren, die mit dem CA-Schlüssel signierte Zertifikate verwenden. Im Umgang mit der eigenen CA sollten hohe Sicherheitsstandards eingehalten werden, da mit dieser CA Zertifikate für beliebige Domains ausgestellt werden können.

2.1. Let’s Encrypt

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

Für Let’s Encrypt-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, die Prüfung der Inhaberschaft von Server oder Domain und lädt schließlich das Zertifikat herunter. Er kommuniziert hierfür über das Protokoll Automatic Certificate Management Environment (ACME) mit den Servern der EFF.

Installation des Certbot-Skripts

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

  • Wenn das Paketmanagement Ihrer Linux-Distribution Certbot-Version 1.10 oder höher bereitstellt, kann diese Certbot-Version verwendet werden.

  • Die EFF bevorzugt auf ihrer Certbot-Dokumentationsseite die Installation aus einem Snap-Image. Es gelten die bekannten Vor- und Nachteile des Snap-Paketformates.

  • Certbot ist über das Python-Paketinstallationswerkzeug pip aus dem Python Package Index installierbar. Erstellen Sie zunächst ein Python Virtual Environment (venv), um sicherzustellen, dass keine von der Distribution bereitgestellten Python-Module beschädigt werden. In der virtuellen Umgebung führen Sie pip install certbot aus, um Certbot und alle abhängig benötigten Python-Module zu installieren.

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. Mit diesem können Sie Schlüssel erzeugen, Zertifikate anfordern, die Apache-Konfiguration automatisch anpassen und schließlich einen Cronjob einrichten, um regelmäßig die 90 Tage laufenden Zertifikate zu erneuern.

root@linux# certbot --apache
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Das Skript 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. Eine Anpassung der Konfigurationsdatei für mod_ssl ist nicht nötig, dies hat der Certbot bereits erledigt.

Teilautomatisierte Konfiguration

Falls Sie, wie im vorherigen Abschnitt beschrieben, Zertifikate anfordern, aber die Apache-Konfiguration selbst anpassen wollen, verwenden Sie den Befehl:

root@linux# certbot certonly --apache
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Die Konfiguration schließen Sie dann wie unten beschrieben in der Konfigurationsdatei für mod_ssl ab.

Weitere Möglichkeiten

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 Host-Namen 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 E-Mails für eine Domain versenden dürfen.

DNS-Challenges können manuell durchgeführt werden, was bei 90 Tagen Gültigkeit meist nur für einzelne Testsysteme praktikabel ist. Verfügt Ihr DNS-Anbieter über ein von Let’s Encrypt unterstütztes API, kann auch eine automatische Erneuerung durchgeführt werden. Lesen Sie hierfür die Übersicht der Challenge Typen bei Let’s Encrypt.

2.2. Externe CA verwenden

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 Validierung auf Organisations- statt nur Domain-Ebene erforderlich ist.

Die Abfolge ist, dass Sie zunächst den privaten Server-Schlüssel erzeugen und dann für diesen ein Certificate Signing Request (CSR) erstellen, welches Sie an den ausgewählten Anbieter übertragen. Dieser prüft dann die Inhaberschaft der Domain, bestätigt das CSR mit seinem Schlüssel und schickt Ihnen das resultierende Server-Zertifikat.

Beachten Sie — ungeachtet der nachfolgenden Beispiele — unbedingt auch die Vorgaben Ihrer Certificate Authority und ändern Sie die Befehle gegebenenfalls entsprechend ab.

Schlüssel und CSR erzeugen

Zunächst erzeugen Sie den privaten Server-Schlüssel. Diesen Schritt können Sie direkt auf dem Server durchführen, auf dem die abzusichernde Checkmk-Instanz läuft.

Der verwendete Ordner /etc/certs entspricht dem Standard vieler Distributionen. Sie können aber jeden beliebigen Ordner verwenden, auf den der Apache-Prozess lesend zugreifen kann. Den Schlüssel nach dem primären Domain-Namen zu benennen, für den er verwendet wird (hier checkmk.mydomain.com), dient hier der besseren Übersicht. Insbesondere wenn später weitere Server-Namen hinzukommen sollten, für die eigene Schlüssel/Zertifikate verwendet werden, erleichtert dieses Namensschema die Zuordnung.

Der private Schlüssel dient später der Verschlüsselung des Datenverkehrs und sollte entsprechend umsichtig behandelt werden (beispielsweise hinsichtlich der Zugriffsrechte). Um einen Neustart des Apache-Servers auch automatisiert durchführen zu können, vergeben die meisten Administratoren keine Passphrase.

root@linux# openssl genrsa -out /etc/certs/checkmk.mydomain.com.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.....++
...............................................................++
e is 65537 (0x010001)
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Im nächsten Schritt erstellen Sie das Certificate Signing Request (CSR) – einen digitalen Antrag auf Erstellung eines Identitäts-Zertifikats (hier: Public-Key-Zertifikat):

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 []:
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

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

Extension-Datei erstellen

Moderne Browser erfordern Zertifikate, welche die Erweiterung für alternative Host-Namen nutzen, selbst wenn die Zertifikate nur für einen Host-Namen ausgestellt werden. Dies erfordert eine Extension-Datei, welche manche Anbieter automatisch erstellen und integrieren. Ist das nicht der Fall oder Sie sind unsicher, erstellen Sie eine solche Datei. Soll ein Zertifikat für mehrere Host-Namen gültig sein, folgen unter [alt_names] weitere Zeilen DNS.2 = und so weiter:

/tmp/checkmk.mydomain.com.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = checkmk.mydomain.com

Unterlagen einreichen

Je nach angestrebter Validierungsebene kann es erforderlich sein, weitere Unterlagen wie Handelsregisterauszüge oder Bankdaten zusammenzustellen. Da die angeforderten Unterlagen, die Wege der Einreichung und die Wege der Bestätigung von Anbieter zu Anbieter verschieden sind, kann hier keine allgemein gültige Anleitung gegeben werden. So kann Extended Validation beispielsweise auch bedeuten, dass per Einschreiben ein Code an Geschäftsführer oder Prokurist verschickt wird, der über ein Webformular eingegeben werden muss.

Im einfachsten Fall einer Validierung nur auf Domain-Ebene wird die CSR-Datei und gegebenenfalls die EXT-Datei über eine Weboberfläche hochgeladen. Sie erhalten dann die Möglichkeit, eine E-Mail-Adresse auszuwählen: aus den für Admin-C (Inhaber) oder Tech-C (technisch Verantwortlicher) der Domain hinterlegten oder einer generischen E-Mail-Adresse wie webmaster@domain.com. An diese Adresse wird dann ein Bestätigungslink verschickt.

Zertifikat erhalten

Der Prüfungsvorgang selbst dauert bei Validierung auf Domain-Ebene in der Regel maximal einige Minuten, bei Extended Validation manchmal mehrere Tage. Sobald dieser abgeschlossen ist, erhalten Sie das zu Ihrem Schlüssel gehörende Zertifikat per E-Mail oder Download. Neben dem Zertifikat erhalten Sie auch einen Downloadlink zur Zertifikatskette (Certificate Chain File). Speichern Sie diese unbedingt mit ab.

2.3. Interne CA verwenden

Sie können sich selbst in die Rolle einer Certificate Authority (CA) versetzen und Zertifikate für beliebige Domains (Ihre Domains, fremde Domains und Phantasie-Domains) ausstellen. Der Weg über die eigene CA ist vor allem für Testumgebungen oder abgeschottete Checkmk-Server mit überschaubarer Nutzerzahl sinnvoll. Dies ist zudem die einzige Möglichkeit, Zertifikate zu erhalten, wenn Sie intern eine der fünf reservierten Top-Level-Domains (TLD) .example, .invalid, .local, .localhost oder .test verwenden. Für diese Domains gibt es keine Registrare, folglich kann keine Inhaberschaft bestätigt werden.

Dieses Kapitel erklärt die Ausstellung von Zertifikaten mit solch einer internen CA. Als Voraussetzungen werden angenommen, dass Sie bereits über den privaten CA-Root- oder CA-Intermediate-Schlüssel verfügen und diesen nun verwenden sollen, um Zertifikate zur Absicherung eines Checkmk-Servers auszustellen.

Die Erstellung der CA-Schlüssel, des CA-Zertifikats und der dazugehörigen Konfigurationsdatei ist nicht Bestandteil dieser Anleitung. Das Checkmk-Blog enthält eine ausführliche Anleitung, wie Sie eine eigene CA-Infrastruktur mit IM-Zertifikaten einrichten können.

Schlüssel und CSR erzeugen

Gehen Sie für die Erstellung von Server-Schlüssel, Certificate Signing Request (CSR) und Extension-Datei so vor, wie es im Abschnitt zur Zertifikatsausstellung über eine kommerzielle CA beschrieben ist. Die Vorgehensweise und die benötigten Dateien sind identisch.

CSR signieren

Um selbst Zertifikate zu signieren, benötigen Sie wenigstens einen privaten Schlüssel (hier intermediate.key.pem) und das dazugehörige Intermediate-Zertifikat intermediate.pem. Falls Sie zudem über eine Konfigurationsdatei verfügen, ist der Pfad zu dieser mit dem Parameter --config anzugeben.

Die Signatur auf Basis der CSR-Datei checkmk.mydomain.com.csr, Extension-Datei checkmk.mydomain.com.ext und der Ausgabedatei checkmk.mydomain.com.crt erledigen Sie dann mit folgendem Befehl:

user@host:~$ openssl x509 -CAcreateserial -req \
    -in checkmk.mydomain.com.csr \
    -CA intermediate.pem -CAkey intermediate.key.pem \
    -out checkmk.mydomain.com.crt -days 365 \
    -sha256 -extfile checkmk.mydomain.com.ext
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Neben dem hier erstellten Server-Zertifikat checkmk.mydomain.com.crt müssen Sie Ihr CA-Zertifikat intermediate.pem weitergeben. Falls Sie nicht Root-CA sind, müssen Sie zusätzlich auch das Root-Zertifikat (im weiteren Text als ca_certificate_intern.pem referenziert) weitergeben.

Zertifikat importieren

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

Damit die Zertifikatsverwaltung kein Stolperstein beim automatischen Agenten-Update in den kommerziellen Editionen 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, und Agenten-Updates sind dennoch möglich.

Tip

Wenn Sie mit Intermediate CAs arbeiten, müssen Sie dem Agent Updater via Agent Bakery die komplette Zertifikatskette übergeben!

Sollen Skripte, die beispielsweise auf das REST-API zugreifen, den eigenen Zertifikaten vertrauen, kopieren Sie die Datei ca_certificate_intern.pem nach /usr/local/share/ca-certificates/. Anschließend generieren Sie den Cache neu:

root@linux# update-ca-certificates
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

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 Microsoft Knowledge Base Artikel PKI nachlesen. Alternativ können Sie Zertifikate per Intune verteilen.

3. Konfiguration des Apache Webservers

In diesem Abschnitt aktivieren Sie die SSL-Konfiguration und weisen die Zertifikate zu. Wenn der Checkmk-Server dann über HTTPS erreichbar ist, fügen Sie Weiterleitung von HTTP nach HTTPS hinzu.

Tip

Falls Sie den vollautomatischen Modus von Let’s Encrypt verwendet haben, sind die benötigten Apache-Module aktiv und es wurde eine Vhost-Konfiguration erstellt. Nach dem Funktionstest, dass Ihr Checkmk-Server per HTTPS erreichbar ist, können Sie mit Einrichtung der HTTPS-Weiterleitung fortfahren.

3.1. Port 443 in der Firewall erlauben

Stellen Sie sicher, dass Ihre Firewall eingehenden Verkehr auf Port 443 (HTTPS) erlaubt. Wenn Sie firewalld verwenden, geben Sie den Webserver frei und aktivieren die Änderung mit den beiden folgenden Befehlen:

root@linux# firewall-cmd --zone=public --add-service=https --permanent
success
root@linux# firewall-cmd --reload
success
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

3.2. Module aktivieren

Die HTTPS-Absicherung der Checkmk-Oberfläche benötigt das Apache-Modul mod_ssl. Wir gehen im weiteren Verlauf der Einrichtung zudem davon aus, dass eine auf dem unverschlüsselten Port 80 eingehende Verbindung auf den SSL verschlüsselten Port 443 weitergeleitet werden soll. Dafür ist das Modul mod_rewrite nötig. Schließlich wird noch mod_headers benötigt, damit der als Reverse Proxy konfigurierte, extern erreichbare Apache dem Site Apache die Request Header weiterleitet.

Je nach Distribution sind die benötigten Apache-Module in den Webserver einkompiliert, beigelegt und inaktiv oder als separate Pakete zu installieren.

Debian/Ubuntu
Red Hat
SUSE
Debian/Ubuntu

Die geladenen Apache-Module können Sie sich mit dem Befehl apachectl anzeigen lassen. Mit grep prüfen Sie gleich, ob alle drei benötigten Module vorhanden sind:

root@linux# apachectl -M | grep -E 'headers|rewrite|ssl'
 rewrite_module (shared)
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

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

root@linux# a2enmod ssl
Enabling module ssl.
To activate the new configuration, you need to run:
  systemctl restart apache2
root@linux# a2enmod headers
Enabling module headers.
To activate the new configuration, you need to run:
  systemctl restart apache2
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Red Hat
SUSE

Starten Sie den Apache noch nicht neu. In vielen Fällen enthält die Konfiguration jetzt Pfade zu nicht existierenden Dateien, welche dafür sorgen, dass Apache nicht startet. Die Konfiguration passen Sie im nächsten Abschnitt an.

3.3. HTTPS-Verbindung für eine Instanz konfigurieren

Sind die Module vorbereitet, müssen Sie in der SSL-Konfigurationsdatei die korrekten Pfade zu Schlüssel, Zertifikat und Intermediate-Zertifikat angeben. Wir zeigen hier die einfachste Konfiguration mit einem Zertifikat pro Server, welches in der Standard-Konfigurationsdatei angegeben wird. Da Apache Server Name Indication unterstützt, können verschiedene Virtual Hosts verschiedene Zertifikate verwenden, die pro Vhost definiert werden. Dies ist nicht Scope dieses Artikels.

In den folgenden Beispielen bezeichnet das SSLCertificateKeyFile den eingangs erzeugten privaten Schlüssel für diesen Server. SSLCertificateChainFile enthält das Intermediate Certificate oder gegebenenfalls aneinandergereihte Intermediate Certificates. Lediglich bei einer internen CA, wo direkt mit dem CA-Schlüssel signiert wird, fällt dieses weg.

Unser Beispiel fügt zudem zwei Zeilen RequestHeader set X-Forwarded…​ hinzu. Diese stellen sicher, dass dem Site Apache auf Port 5000 mitgeteilt wird, dass ein Aufruf über SSL erfolgte, Sicherheitsregeln also eingehalten wurden. In der Folge wird Analyze configuration die Konfiguration für Secure GUI (HTTP) als OK erkennen.

Debian/Ubuntu
Red Hat
SUSE
Debian/Ubuntu

Zuerst müssen Sie die Konfiguration für die Standard-SSL-Site aktivieren:

root@linux# a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  systemctl reload apache2
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Passen Sie jetzt die Konfiguration an:

/etc/apache2/sites-available/default-ssl.conf
SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crt
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

…​oder bei Let’s Encrypt:

/etc/apache2/sites-available/default-ssl.conf
SSLCertificateKeyFile /etc/letsencrypt/live/checkmk.mydomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/checkmk.mydomain.com/chain.pem
SSLCertificateFile /etc/letsencrypt/live/checkmk.mydomain.com/cert.pem
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Fügen Sie unmittelbar vor dem schließenden Tag </VirtualHost> die folgenden Zeilen ein:

/etc/apache2/sites-available/default-ssl.conf
<IfModule headers_module>
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
</IfModule>
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Starten Sie dann den Apache-Prozess neu:

root@linux# systemctl restart apache2
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Red Hat
SUSE

3.4. HTTPS-Weiterleitung hinzufügen

Apache arbeitet mit virtuellen Hosts, um unter einer IP-Adresse verschiedene Inhalte bereitstellen zu können. Da auf einem reinen Checkmk-Server in der Regel nur ein virtueller Host mit einem Servernamen verwendet wird, nehmen Sie die Einstellungen nur im Standard-Vhost respektive in der globalen Apache-Konfiguration vor.

Debian/Ubuntu
Red Hat
SUSE
Debian/Ubuntu

Debian und Ubuntu verwenden eine separate Konfigurationsdatei für den Standard-Vhost auf Port 80. Fügen Sie dort die folgenden Zeilen unmittelbar vor dem schließenden Tag </VirtualHost> ein:

/etc/apache2/sites-enabled/000-default
RewriteEngine On
# Never forward request for .well-known (important when using Let's Encrypt)
RewriteCond %{REQUEST_URI} !^/.well-known
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Starten Sie dann den Apache-Prozess neu:

root@linux# systemctl restart apache2
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Red Hat
SUSE

3.5. 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 bietet den Vorteil, 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 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 Zertifikats aufgerufen werden.

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

Aktivierung in der SSL-Konfiguration

Die Aktivierung von HSTS erfolgt über eine zusätzliche Header-Zeile. Diese müssen Sie in der Konfigurationsdatei für Ihre SSL-Einstellungen innerhalb des Blockes <VirtualHost> …​ </VirtualHost> eintragen:

Header always set Strict-Transport-Security "max-age=43200"
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Tip

Setzen Sie zunächst einen kurzen Zeitraum – z.B. 300 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://mycmkserver/mysite/check_mk/login.py
HTTP/1.1 200 OK
Date: Fri, 12 Jun 2026 08:34:57 GMT
Server: Apache
Strict-Transport-Security: max-age=43200
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Letzte Änderung: Wed, 29 Jul 2026 10:36:05 GMT via Commit d96cfb68c
Auf dieser Seite