Securing the web interface with HTTPS

1. Introduction

The main reason for securing the Checkmk web interface is usually security: Monitoring can generate a large volume of data that reveals to potential attackers which targets are worthwhile and which attack vectors are likely to succeed. Third parties should not be able to view or manipulate this transmitted data. For this reason, it should go without saying that at least those monitoring sites accessible via public networks should be secured with HTTPS.

Even when used within trusted environments, consistent use of HTTPS contributes to a smooth Checkmk experience.

The default security settings of all modern browsers block the unencrypted component in many combinations of HTTP and HTTPS, or force the connection to be upgraded to HTTPS. For example, you cannot embed dashboards loaded via HTTP in inline frames on pages that were loaded via HTTPS (Mixed content). Additionally, redirection from HTTPS to HTTP is not possible, which is relevant when external authentication is used. Furthermore, most browsers block access to the clipboard via JavaScript, which renders copy buttons unusable.

If you want to use the Checkmk web interface via HTTPS, you must meet the following requirements on your monitoring server—regardless of your sites:

You must have a valid server certificate.
The Apache module mod_ssl is installed and enabled.
The Apache modules mod_rewrite and mod_headers are present and also enabled.
The server is accessible via HTTPS.

This article explains how to do this.

2. Obtaining certificates

Since many distributions have non-standard paths to certificates, certificate chains, and keys configured by default, it makes sense to first obtain the certificates and then tackle the configuration of the Apache web server.

Essentially, the following methods are available for obtaining a server certificate:

Use free certificates from Let’s Encrypt. This method only allows for domain-level validation. To request certificates, the server you want to secure must be accessible from the outside, or you must be able to create (automated) entries in the public DNS for the domain in question.
You use an external service provider for certificate issuance via CSR (Certificate Signing Request), whose root certificate is trusted by browser and operating system vendors. With this method, certificates can be validated not only at the level of a domain, but also at the organizational level (Organization Validation) and higher (Extended Validation), as is mandatory in some industries for regulatory reasons.
You will set up your own Certificate Authority (CA) and generate your own certificates. The root certificate of your own CA must be installed on all computers that communicate with servers using certificates signed with the CA key. When managing your own CA, high security standards must be maintained, as this CA can be used to issue certificates for any domain.

2.1. Let’s Encrypt

If a server is accessible from the outside or if you have access to the name server, you can automatically generate certificates through the non-profit service provider Let’s Encrypt, which is part of the Electronic Frontier Foundation (EFF). There are no costs involved. Certificates validated via DNS require a few minutes of attention every 90 days, while certificates validated via a server directory can be automatically renewed for years.

For Let’s Encrypt certificates, the EFF provides the Python program Certbot in many different package formats. Certbot handles the generation of the key, the submission of the CSR, the verification of server or domain ownership, and finally downloads the certificate. To do this, it communicates with the EFF’s servers via the Automatic Certificate Management Environment (ACME) protocol.

Installing the Certbot script

There are three ways to install Certbot. Which one you choose will depend primarily on the age of your distribution and your organization’s policies regarding installation from third-party package sources:

If your Linux distribution’s package manager provides Certbot version 1.10 or higher, you can use that version of Certbot.
The EFF recommends installing from a Snap image on its Certbot documentation page. The well-known advantages and disadvantages of the Snap package format apply.
Certbot can be installed via the Python package installation tool pip from the Python Package Index. First, create a Python virtual environment (venv) to ensure that no Python modules provided by the distribution are corrupted. In the virtual environment, run pip install certbot to install Certbot and all required Python modules.

Fully automated configurations

If the Checkmk server is accessible from the Internet and you have not made any changes to the system-wide Apache web server configuration since installing Checkmk, you can use Certbot’s 'Apache Automation' feature. This feature allows you to generate keys, request certificates, automatically adjust the Apache configuration, and finally set up a cron job to regularly renew the certificates, which are valid for 90 days.

root@linux# certbot --apache

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

The script will now interactively prompt you for some information regarding contact details (email address for additional information such as necessary certificate revocations) and installation paths. The result is a fully functional SSL configuration. You do not need to modify the configuration file for mod_ssl; Certbot will have already taken care of that.

Partially automated configurations

If, as described in the previous section, you want to request certificates but customize the Apache configuration yourself, use the following command:

root@linux# certbot certonly --apache

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

You can then complete the configuration as described below in the configuration file for mod_ssl.

Additional options

For example, if the Checkmk server is only accessible from the intranet or via VPN, but the DNS server is public, you can perform validation using a DNS challenge. In this case, domain ownership is not verified by the ability to place files on the web server, but rather by the ability to add entries to the DNS. This does not involve records that resolve a hostname to an IP address, but rather so-called TXT records, which can contain any string of characters. TXT records are also used, for example, to specify which servers are authorized to send emails on behalf of a domain.

DNS challenges can be performed manually, which—given their 90-day validity period—is usually only practical for individual test systems. If your DNS provider offers an API supported by Let’s Encrypt, automatic renewal is also possible. For more information, see the Overview of Challenge Types on the Let’s Encrypt website.

2.2. Using an external CA

For a long time, having certificates signed by a commercial Certificate Authority was the only way to obtain certificates accepted by all browsers and operating systems. This procedure is still common today, particularly when validation on organization level rather than domain level is required.

The process is as follows: First, you generate the private server key, then create a Certificate Signing Request (CSR) for it, which you submit to the selected provider. The provider then verifies ownership of the domain, signs the CSR with its key, and sends you the resulting server certificate.

Please note—regardless of the examples below—that you must also follow the guidelines provided by your chosen Certificate Authority and modify the commands accordingly when required.

Generating keys and CSRs

First, generate the private server key. You can perform this step directly on the server running the Checkmk site you want to secure.

The folder /etc/certs used here is the default for many distributions. However, you can use any folder that the Apache process has read access to. Naming the key after the primary domain name for which it will be used (in this case, checkmk.mydomain.com) helps to maintain a clear overview. This naming convention makes it easier to identify the key, especially if additional server names are added later that require their own keys and certificates.

The private key will later be used to encrypt data traffic and should therefore be handled with care (for example, regarding access permissions). To ensure that the Apache server can be restarted automatically, most administrators do not set a 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)

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

In the next step, you’ll create the Certificate Signing Request (CSR)—a digital request to generate an identity certificate (in this case, a public-key certificate):

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

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Be sure to enter the company information correctly, and enter the server name as the Common Name. The Email Address should be within the same domain and belong to an existing email account that is actively monitored.

Create an extension file

Modern browsers require certificates that use the extension for alternative host names, even if the certificates are issued for only a single host name. This requires an extension file, which some providers automatically create and integrate. If this is not the case or if you are unsure, create such a file. If a certificate is to be valid for multiple host names, add additional lines under [alt_names], such as DNS.2 = and so on:

/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

Submitting documents

Depending on the desired validation level, it may be necessary to compile additional documents, such as extracts from the commercial register or bank information. Since the required documents, submission methods, and verification procedures vary from provider to provider, no general guidelines can be provided here. For example, Extended Validation may also involve sending a code via certified mail to a managing director or authorized signatory, which must then be entered via a web-based form.

In the simplest case of domain-level validation, the CSR file and, if applicable, the EXT file are uploaded via a web interface. You will then be given the option to select an email address: either from those on file for the domain’s Admin-C (owner) or Tech-C (technical contact), or a generic email address such as webmaster@domain.com. A confirmation link will then be sent to this address.

Receive a certificate

The verification process itself usually takes a few minutes at most for domain-level validation, but can sometimes take several days for an extended validation. Once this is complete, you will receive the certificate associated with your key via email or download. In addition to the certificate, you will also receive a download link for the certificate chain (Certificate Chain File). Be sure to save this as well.

2.3. Using an internal CA

You can assume the role of a Certificate Authority (CA) and issue certificates for any domains (your own domains, third-party domains, and fictional domains). Using your own CA is particularly useful for test environments or isolated Checkmk servers with a manageable number of users. This is also the only way to obtain certificates if you are using one of the five reserved top-level domains (TLDs)—.example, .invalid, .local, .localhost, or .test—internally. There are no registrars for these domains, so ownership cannot be verified.

This chapter explains how to issue certificates using such an internal CA. It is assumed that you already have the private CA root or CA intermediate key and will now use it to issue certificates to secure a Checkmk server.

Creating the CA keys, the CA certificate, and the associated configuration file is not covered in this guide. The Checkmk blog contains detailed instructions on how to set up your own CA infrastructure with IM certificates.

Generating keys and CSRs

To generate the server key, Certificate Signing Request (CSR), and extension file, follow the procedure described in the section on Certificate Issuance via a Commercial CA. The procedure and the required files are identical.

Signing the CSR

To sign certificates yourself, you need at least one private key (here, intermediate.key.pem) and the corresponding intermediate certificate intermediate.pem. If you also have a configuration file, specify the file path using the --config parameter.

You can then sign the CSR file checkmk.mydomain.com.csr, the extension file checkmk.mydomain.com.ext, and the output file checkmk.mydomain.com.crt using the following command:

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

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

In addition to the server certificate checkmk.mydomain.com.crt created here, you must provide your CA certificate intermediate.pem. If you are not a root CA, you must also provide the root certificate (referred to as ca_certificate_intern.pem in the text below).

Importing a certificate

The steps for importing a CA certificate as trusted vary from browser to browser. In most cases, it is sufficient to add the certificate ca_certificate_intern.pem under Settings > Privacy and Security > Certificates > Import.

To ensure that certificate management does not pose an obstacle to automatic agent updates in the commercial editions, in the Agent Bakery we have provided the option to specify a custom CA certificate that is used exclusively for agent updates. The system certificates remain unaffected, and agent updates are still possible.

If you are working with intermediate CAs, you must provide the Agent Updater with the complete certificate chain via the Agent Bakery!

If scripts that access the REST API, for example, are supposed to trust your own certificates, copy the file ca_certificate_intern.pem to /usr/local/share/ca-certificates/. Then regenerate the cache:

root@linux# update-ca-certificates

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

In Windows, you can manage system certificates using the 'Certificates' MMC snap-in. This is necessary, for example, if you want to use a Microsoft browser to access a Checkmk secured with your own CA. You can find the exact procedure in the Microsoft Knowledge Base article PKI. Alternatively, you can distribute certificates via Intune.

3. Configuring the Apache Web Server

In this section, you will enable SSL configuration and assign the certificates. Once the Checkmk server is accessible via HTTPS, you will add redirection from HTTP to HTTPS.

If you have used the fully automated mode of Let’s Encrypt, the required Apache modules will be active, and a Vhost configuration will have been created. After verifying that your Checkmk server is accessible via HTTPS, you can proceed with setting up HTTPS redirection.

3.1. Allow Port 443 in the firewall

Make sure your firewall allows incoming traffic on port 443 (HTTPS). If you are using firewalld, authorize the web server and apply the change using the following two commands:

root@linux# firewall-cmd --zone=public --add-service=https --permanent
success
root@linux# firewall-cmd --reload
success

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

3.2. Enabling modules

HTTPS security for the Checkmk interface requires the Apache module mod_ssl. In the rest of the setup process, we will also assume that incoming connections on the unencrypted port 80 should be redirected to the SSL-encrypted port 443. This requires the mod_rewrite module. Finally, mod_headers is needed so that the externally accessible Apache server, configured as a reverse proxy, can forward the request headers to the Apache server.

Depending on the distribution, the required Apache modules may be compiled into the web server, included but disabled, or available as separate packages to be installed.

Debian/Ubuntu

Red Hat

SUSE

Debian/Ubuntu

You can use the apachectl command to view the loaded Apache modules. Use grep to check immediately whether all three required modules are present:

root@linux# apachectl -M | grep -E 'headers|rewrite|ssl'
 rewrite_module (shared)

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

You can enable missing modules using the a2enmod script. This creates symbolic links in the /etc/apache2/mods-enabled directory. The file with the .load extension contains instructions for loading the module, and the .conf file contains the module’s actual configuration:

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

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Red Hat

On Red Hat Enterprise Linux and distributions based on it, mod_ssl is a separate package that you must install on its own:

root@linux# dnf install httpd mod_ssl

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

SUSE

SLES and openSUSE Leap include the required modules pre-compiled into the Apache binary. These are enabled via startup parameters, which must be specified in the /etc/sysconfig/apache2 file:

APACHE_SERVER_FLAGS="SSL"

In contrast, mod_headers, which is required for forwarding headers, is a dynamically loaded module; it is enabled using a2enmod.

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

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Do not restart Apache yet. In many cases, the configuration now contains paths to nonexistent files, which will prevent Apache from starting. You will modify the configuration in the next section.

3.3. Configuring an HTTPS connection for a site

Once the modules have been set up, you must specify the correct file paths to the key, certificate, and intermediate certificate in the SSL configuration file. Here, we will show you the simplest configuration with one certificate per server, which is specified in the default configuration file. Since Apache supports Server Name Indication, different virtual hosts can use different certificates, which are defined on a per-vhost basis. This is beyond the scope of this article.

In the following examples, SSLCertificateKeyFile refers to the private key generated earlier for this server. SSLCertificateChainFile contains the intermediate certificate or, if applicable, a chain of intermediate certificates. This is omitted only in the case of an internal CA, where the CA key is used to sign directly.

Our example also adds two lines: RequestHeader set X-Forwarded…. These ensure that the Apache site on port 5000 is informed that the request was made via SSL, meaning security rules were followed. As a result, Analyze configuration will recognize the configuration for Secure GUI (HTTP) as OK.

Debian/Ubuntu

Red Hat

SUSE

Debian/Ubuntu

First, you must enable the configuration for the default SSL site:

root@linux# a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  systemctl reload apache2

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Now modify the configuration:

/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

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

…or with 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

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Insert the following lines immediately before the closing </VirtualHost> tag:

/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>

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Then restart the Apache process:

root@linux# systemctl restart apache2

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Red Hat

Edit the file /etc/httpd/conf.d/ssl.conf:

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

SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crt

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

…or with Let’s Encrypt:

/etc/httpd/conf.d/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

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Insert the following lines immediately before the closing </VirtualHost> tag:

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

<IfModule headers_module>
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
</IfModule>

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Then restart the Apache process:

root@linux# systemctl restart httpd

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

SUSE

SLES and openSUSE Leap include a sample SSL configuration file. This must be copied to a file with the .conf extension so that it can be read:

root@linux# cp -v /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl-default.conf
'/etc/apache2/vhosts.d/vhost-ssl.template' -> '/etc/apache2/vhosts.d/vhost-ssl-default.conf'

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

In the target file, you only need to modify the two or three lines for the key, the certificate, and, if necessary, the chain:

/etc/apache2/vhosts.d/vhost-ssl-default.conf

SSLCertificateKeyFile /etc/certs/checkmk.mydomain.com.key
SSLCertificateChainFile /etc/certs/ca_bundle.crt
SSLCertificateFile /etc/certs/certificate.crt

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

…or with Let’s Encrypt:

/etc/apache2/vhosts.d/vhost-ssl-default.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

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Insert the following lines immediately before the closing </VirtualHost> tag:

/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>

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Then restart the Apache process:

root@linux# systemctl restart apache2

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

3.4. Adding an HTTPS redirect

Apache uses virtual hosts to deliver different content under a single IP address. Since a dedicated Checkmk server typically uses only one virtual host with a server name, make the settings only in the default vhost or in the global Apache configuration.

Debian/Ubuntu

Red Hat

SUSE

Debian/Ubuntu

Debian and Ubuntu use a separate configuration file for the default virtual host on port 80. Insert the following lines there immediately before the closing </VirtualHost> tag:

/etc/apache2/sites-enabled/000-default

RewriteEngine On
# Never forward requests for .well-known (important when using Let's Encrypt)
RewriteCond %{REQUEST_URI} !^/.well-known
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Then restart the Apache process:

root@linux# systemctl restart apache2

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Red Hat

Red Hat does not use the VirtualHost directive; instead, it defines the behavior for port 80 in the rather confusing file /etc/httpd/conf/httpd.conf. This file does, however, read files with the .conf extension in the /etc/httpd/conf.d/ directory. Create a new file /etc/httpd/conf.d/redirect_to_https.conf with the following content:

/etc/httpd/conf.d/redirect_to_https.conf

RewriteEngine On
# Never redirect requests for .well-known (important when using Let's Encrypt)
RewriteCond %{REQUEST_URI} !^/.well-known
# The next 2 lines: Only enforce the redirect if the incoming request is not coming through port 443
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Then restart the Apache process:

root@linux# systemctl restart httpd

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

SUSE

Like Red Hat, SUSE does not use a VirtualHost directive for the default behavior on port 80. You can either create a virtual host by copying the configuration file /etc/apache2/vhosts.d/vhost.template to /etc/apache2/vhosts.d/vhost-default.conf and customizing that file—this solution is very flexible, but somewhat more involved than the following alternative. Or you can take the easier route and create a global configuration file /etc/apache2/conf.d/redirect_to_https.conf with the following content:

/etc/apache2/conf.d/redirect_to_https.conf

RewriteEngine On
# Never forward request for .well-known (important when using Let's Encrypt)
RewriteCond %{REQUEST_URI} !^/.well-known
# Next 2 lines: Force redirection only if incoming request is not on 443
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}$1 [L]

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Then restart the Apache process:

root@linux# systemctl restart apache2

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

3.5. Setting Up HSTS

Making the Checkmk server accessible only via HTTPS is the first and most important step in securing connections to the monitoring system. However, you can further enhance security with additional, optional settings. This allows the web server to instruct the browser to access it only via HTTPS in the future and to always reject unsecured connections via HTTP.

This technique is called HTTP Strict Transport Security (HSTS) and is set for a specific duration in seconds. Once this limit has expired, the browser checks again to see if the HSTS restriction is still valid.

Special Considerations

Configuring HSTS has the advantage of ensuring that only secure connections are used. Its implementation also involves certain special considerations that you must be aware of before making the switch:

Once the HSTS entry has been created by the user’s browser, it can—at least before it expires—only be removed with detailed knowledge of that specific browser. Note that many users do not have this knowledge.
The connection will be rejected, among other reasons, if the certificate has expired or been replaced by a self-signed certificate. Such sites also cannot be accessed by temporarily trusting a certificate via an exception.
Conversely, HSTS is only taken into account if the certificate is trusted when the connection is first established. If not, the browser will not create an HSTS entry, meaning that the additional protection mechanism will not be utilized.

Enabling HSTS in the SSL Configuration

HSTS is enabled via an additional header line. You must enter this in the configuration file for your SSL settings within the <VirtualHost> … </VirtualHost> block:

Header always set Strict-Transport-Security 'max-age=43200'

Copy file content to clipboard

Successfully copied file content to clipboard!

Write access to clipboard has been denied!

Start by setting a short time period—e.g., 300 seconds—to test the setting, since otherwise the connection might be rejected for a very long time if an error occurs! For more information, see also Specifics.

To see if the new setting works, you can use the curl program to query the server. Here are just the first 4 lines of the output:

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

Copy command(s) to clipboard

Successfully copied command(s) to clipboard!

Write access to clipboard has been denied!

Last modified: Wed, 29 Jul 2026 10:36:05 GMT via commit d96cfb68c