Skip to main content

Securing your MAP platform

This chapter describes advanced procedures to secure your Centreon MAP platform.

If you want to use MAP in HTTPS, you must both secure your Centreon platform and MAP. If necessary, follow this procedure to secure your Centreon platform.

Mistakes when editing configuration files can lead to malfunctions of the software. We recommend that you make a backup of the file before editing it and that you only change the settings advised by Centreon.

All TLS settings described in this chapter are configured through properties in /etc/centreon-map/map-config.properties. Two certificate formats are supported:

  • PEM (recommended): use your .crt certificate and .key private key files directly. This is the default format and requires no conversion.
  • JKS: use a Java keystore, if you already have one.

If you are upgrading from a version that used the tls / tls_broker Spring profiles in /etc/centreon-map/centreon-map.conf, you don't need to change anything manually: the postinstall script automatically migrates your existing configuration to the property-based format described below.

Configure HTTPS/TLS on the MAP server​

This section describes how to secure the MAP web server itself (the interface reached by your browser and by Centreon Central).

HTTPS/TLS configuration with a recognized key​

This section describes how to use a recognized key with the Centreon MAP server.

If you want to use a self-signed certificate instead, please refer to the following section.

You will require:

  • A private key file, referred to as map-server.key.
  • A certificate file, referred to as map-server.crt.

  1. Copy the key and certificate files to the MAP server, for example into /etc/centreon-map/.

  2. Set the following parameters in /etc/centreon-map/map-config.properties:

    centreon-map.tls.enabled=true
    centreon-map.tls.pem.keystore.certificate=/etc/centreon-map/map-server.crt
    centreon-map.tls.pem.keystore.private-key=/etc/centreon-map/map-server.key
    centreon-map.tls.pem.keystore.private-key-pass=xxx

    Only set private-key-pass if your private key is encrypted. Adapt the paths if you stored the files elsewhere.

HTTPS/TLS configuration with an auto-signed key​

Enabling the TLS mode with an auto-signed key will force every user to add an exception for the certificate before using the web interface.

Enable it only if your Centreon also uses this protocol.

Users will have to open the URL:

https://<MAP_IP>:9443/centreon-map/api/beta/actuator/health

The solution we recommend is to use a recognized key, as explained above.

  1. Generate a self-signed certificate and private key:

    openssl req -x509 -newkey rsa:2048 -nodes -keyout /etc/centreon-map/map-server.key -out /etc/centreon-map/map-server.crt -days 365

  2. Set the following parameters in /etc/centreon-map/map-config.properties:

    centreon-map.tls.enabled=true
    centreon-map.tls.pem.keystore.certificate=/etc/centreon-map/map-server.crt
    centreon-map.tls.pem.keystore.private-key=/etc/centreon-map/map-server.key

Apply the configuration​

Restart the Centreon MAP service to apply the change:

systemctl restart centreon-map-engine

Centreon MAP server is now configured to respond to requests from HTTPS. The default listening port automatically switches to 9443 (or a port previously configured) instead of 8081.

To use a different port, set the following parameter in /etc/centreon-map/map-config.properties:

centreon-map.port=9443

To change the default port, refer to the dedicated procedure.

Don't forget to modify the URL on Centreon side in the MAP server address field in the Administration > Extensions > Map > Options menu.

Configure TLS on the Broker connection​

An additional Broker output for Centreon Central (centreon-broker-master) has been created during the installation.

You can check it in your Centreon web interface, from the Configuration > Pollers > Broker Configuration, by editing the centreon-broker-master configuration.

The output configuration should look like this:

image

Broker configuration​

You can enable TLS output and set up Broker's private key and public certificate as described below:

image

  1. Create a self-signed certificate with the following commands:

    openssl req -new -newkey rsa:2048 -nodes -keyout broker_private.key -out broker.csr
    openssl x509 -req -in broker.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out broker_public.crt -days 365 -sha256

  2. Copy the private key and the certificate into /etc/centreon/broker_cert/ directory:

    mv broker_private.key /etc/centreon/broker_cert/
    mv broker_public.crt /etc/centreon/broker_cert/

"Trusted CA's certificate" field is optional. If you activate Broker's client authentication by setting this "ca_certificate.crt", then you must also configure the MAP server's own TLS.

You MUST push the new broker configuration and restart the broker after configuration.

MAP engine configuration​

Set the following parameters in /etc/centreon-map/map-config.properties to enable the TLS socket connection to Broker:

broker.tls.enabled=true
broker.tls.pem.keystore.certificate=/etc/centreon-map/map-broker.crt

Point directly to the Broker public certificate (or its CA certificate) in PEM format — no truststore creation needed.

Restart the Centreon MAP service to apply the change:

systemctl restart centreon-map-engine

Once you configure a trusted certificate, Centreon MAP will use it to validate Broker's certificate. This means that if you use a self-signed certificate for Broker, you must add it as shown above. If you don't, the Monitoring > Map page will be blank, and the logs (/var/log/centreon-map/centreon-map.log) will show the following error: unable to find valid certification path to requested target.

Configure TLS for the connection to Centreon Central​

If it is not already done, secure your Centreon platform with HTTPS.

Set the centreon.url parameter inside /etc/centreon-map/map-config.properties to use HTTPS instead of HTTP:

centreon.url=https://<server-address>

If Centreon Central uses a self-signed certificate or a certificate signed by a custom/internal CA, you must give Centreon MAP a way to trust it:

centreon.tls.pem.keystore.certificate=/etc/centreon-map/central-ca.crt

Point directly to Central's public certificate or its CA certificate, in PEM format.

Centreon MAP defaults to the PEM format for this setting; if the PEM certificate file doesn't exist, it falls back to JKS. There is no centreon.tls.type property to set for this connection.

If the certificate is signed by a recognized CA, nothing needs to be configured: the JVM default trust store (cacerts, /etc/pki/java/cacerts) is used automatically.

Configure TLS on a MySQL or MariaDB database​

This section describes how to enable SSL on a MySQL/MariaDB server and configure Centreon MAP to connect to it securely using certificate authority verification (verify-ca mode).

Note: This procedure covers the verify-ca mode only. In this mode, the server certificate is validated against a trusted Certificate Authority, but the hostname/IP address is not verified. For other SSL verification modes, see the SSL Mode reference section.

  • Select the tab corresponding to the database you want to use.

Step 1 - Generate keys and certificates​

1. Create a directory (/etc/mysql/newcerts in this example) to store your certificate files:

mkdir -p /etc/mysql/newcerts
cd /etc/mysql/newcerts

2. Generate the Certificate Authority (CA). The CA is used to sign both the server and client certificates, establishing a chain of trust.

# Generate the CA private key
openssl genrsa 2048 > ca-key.pem
# Generate the CA self-signed certificate
openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem

3. Generate the server certificate. The server certificate is presented by MySQL to clients during the SSL handshake.

# Generate the server private key and CSR (Certificate Signing Request)
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem

# Convert the server key to RSA format (required by MySQL)
openssl rsa -in server-key.pem -out server-key.pem

# Sign the server certificate with the CA
openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

4. Generate the client certificate. The client certificate is used by the application to authenticate itself to MySQL (mutual TLS).

# Generate the client private key and CSR
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem
# Convert the client key to RSA format
openssl rsa -in client-key.pem -out client-key.pem
# Sign the client certificate with the CA
openssl x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

5. Verify the certificates. Ensure both certificates are correctly signed by the CA before proceeding.

openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
# Expected output:
# server-cert.pem: OK
# client-cert.pem: OK

Step 2 - Configure the MySQL/MariaDB server​

1. Set the file ownership. MySQL requires ownership of all certificate files.

Ensure you are using the directory you previously created (/etc/mysql/newcerts in this example).

chown -Rv mysql:root /etc/mysql/newcerts/*

2. Edit the MySQL server configuration. Add the following block to your MySQL server configuration file (typically /etc/mysql/mysql.conf.d/mysqld.cnf):

[mysqld]
ssl-ca   = /etc/mysql/newcerts/ca-cert.pem
ssl-cert = /etc/mysql/newcerts/server-cert.pem
ssl-key  = /etc/mysql/newcerts/server-key.pem
# Restrict to secure TLS versions only
tls_version = TLSv1.2,TLSv1.3

3. Optional - Edit the MySQL client configuration. This allows the mysql CLI tool to connect using SSL as well.

[mysql]
ssl-ca   = /etc/mysql/newcerts/ca-cert.pem
ssl-cert = /etc/mysql/newcerts/client-cert.pem
ssl-key  = /etc/mysql/newcerts/client-key.pem

4. Restart MySQL.

systemctl restart mysqld

5. Verify SSL is active.

SHOW VARIABLES LIKE '%ssl%';
-- have_ssl should be YES
-- ssl_ca, ssl_cert, ssl_key should point to your certificate files

Step 3 - Configure the MySQL/MariaDB user​

1. Require SSL for the user.

ALTER USER 'centreon_map'@'<ip_or_hostname>' REQUIRE SSL;
-- Verify: ssl_type should now show ANY
SELECT user, host, ssl_type FROM mysql.user WHERE user='centreon_map';

2. Grant privileges.

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES
  ON `centreon_map`.*
  TO `centreon_map`@`<ip_or_hostname>`;
-- Verify grants
SHOW GRANTS FOR 'centreon_map'@'<ip_or_hostname>';

Step 4 - Configure JDBC (Spring Boot)​

Since the migration to MariaDB Connector/J, the MySQL connector is no longer bundled. Even when your database server is MySQL, the JDBC URL uses the jdbc:mariadb:// scheme and the org.mariadb.jdbc.Driver driver. MariaDB Connector/J 3.x supports PEM files natively via the serverSslCert parameter directly in the JDBC URL. No Java keystore conversion is needed for SSL simple mode.

A keystore file is only needed for mTLS (client certificate authentication):

FileContainsPurposeRequired
ca-cert.pemCA certificateLets the driver verify the MySQL server's identityYes - Always
keystore.p12Client cert + private keyLets MySQL verify the application's identityOnly if REQUIRE X509

Note: mTLS is optional. It is only needed if the MySQL user was created with REQUIRE X509. If the user was created with REQUIRE SSL, only serverSslCert pointing to the CA is needed and the keystore steps below can be skipped.

1. Optional - Create the KeyStore for mTLS.

Skip this step if the MySQL user was created with REQUIRE SSL. It is only required for REQUIRE X509 (mutual TLS).

keytool cannot import a PEM private key directly, so we first bundle via PKCS12.

1.1. Bundle the client cert and key into a PKCS12 file:

openssl pkcs12 -export \
-in /etc/mysql/newcerts/client-cert.pem \
-inkey /etc/mysql/newcerts/client-key.pem \
-out /etc/mysql/newcerts/keystore.p12 \
-name mysqlClient \
-passout pass:changeit

2. Set file permissions. Ensure only the user running the Java application can read the keystore files.

chown your_java_user: /etc/mysql/newcerts/keystore.p12
chmod 640 /etc/mysql/newcerts/keystore.p12

3. Set the JDBC URL. Add the following to your configuration file (/etc/centreon-map/*-database.properties):

*.connection.url=jdbc:mariadb://<ip_or_hostname>:3306/centreon_map?sslMode=verify-ca&serverSslCert=/etc/mysql/newcerts/ca-cert.pem&rewriteBatchedStatements=true

Note: sslMode=trust for MySQL 8. On a MySQL 8 server, the sslMode=trust parameter is added by default: the caching_sha2_password authentication hardened setup, replace trust with verify-ca (as shown above) or verify-full. Never use sslMode=disable on MySQL 8, as it would break authentication.

4. Optional — only if mTLS is enabled (REQUIRE X509). Add options keyStore, keyStorePassword and keyStoreType:

*.connection.url=jdbc:mariadb://<ip_or_hostname>:3306/centreon_map?sslMode=verify-ca&serverSslCert=/etc/mysql/newcerts/ca-cert.pem&keyStore=/etc/mysql/newcerts/keystore.p12&keyStorePassword=changeit&keyStoreType=PKCS12&rewriteBatchedStatements=true

Step 5 - Check Certificate Expiry​

1. Check the CA certificate.

openssl x509 -in /etc/mysql/newcerts/ca-cert.pem -noout -dates
# notBefore=...
# notAfter=...

2. Check the server certificate.

openssl x509 -in /etc/mysql/newcerts/server-cert.pem -noout -dates

3. Check the KeyStore (mTLS only).

keytool -list -v -keystore /etc/mysql/newcerts/keystore.p12 -storepass changeit
# Look for: Valid from ... until ...

SSL Mode reference​

The verify-ca mode is the recommended minimum for production. This table lists other available modes depending on your security requirements:

ModeServer cert verifiedHostname/IP verifiedUse case
disableNoNoDevelopment only — no encryption
trustNoNoEncrypts traffic but does not validate the server cert
verify-caYesNoUsed in this procedure — validates the CA chain
verify-fullYesYesStrictest — also checks hostname/IP against the certificate SAN

Note: If you want to use the verify-full mode, the server certificate must include a Subject Alternative Name (SAN) matching the exact IP or hostname used in the JDBC URL. The CN field alone is not sufficient for IP-based connections.