Sécurisez votre plateforme MAP
Ce chapitre décrit les procédures avancées permettant de sécuriser votre plateforme MAP.
Si vous souhaitez utiliser MAP en HTTPS, vous devez sécuriser à la fois votre plateforme Centreon et MAP. Suivez cette procédure pour sécuriser votre plateforme Centreon.
Des erreurs de modification de fichiers de configuration peuvent entraîner des dysfonctionnements du logiciel. Nous vous recommandons de faire une sauvegarde du fichier avant de le modifier et de ne changer que les paramètres conseillés par Centreon.
Configurer HTTPS/TLS sur le serveur MAP
Configurer HTTPS/TLS avec une clé reconnue
Cette section décrit comment ajouter une clé reconnue au serveur MAP.
Si vous souhaitez créer une clé auto-signée et l'ajouter à votre serveur, veuillez vous référer à la section suivante.
Vous aurez besoin de :
- Un fichier de clé, appelé key.key.
- Un fichier de certificat, appelé certificate.crt.
Accédez au serveur Centreon MAP par SSH.
Créez un fichier PKCS12 avec la ligne de commande suivante :
openssl pkcs12 -inkey key.key -in certificate.crt -export -out keys.pkcs12
Ensuite, importez ce fichier dans un nouveau keystore (un dépôt Java de certificats de sécurité) :
keytool -importkeystore -srckeystore keys.pkcs12 -srcstoretype pkcs12 -destkeystore map.jks
Placez le fichier keystore ci-dessus (map.jks) dans le dossier /etc/centreon-map/, et définissez les paramètres ci-dessous dans /etc/centreon-map/map-config.properties :
centreon-map.keystore=/etc/centreon-map/map.jks
centreon-map.keystore-pass=xxx
Remplacez la valeur "xxx" de keystore-pass par le mot de passe que vous avez utilisé pour le keystore et adaptez le chemin vers le keystore (s'il a été modifié).
Configuration HTTPS/TLS avec une clé auto-signée
L'activation du mode TLS avec une clé auto-signée obligera chaque utilisateur à ajouter une exception pour le certificat avant d'utiliser l'interface web.
Ne l'activez que si votre Centreon utilise également ce protocole.
Les utilisateurs devront ouvrir l'URL :
https://<MAP_IP>:9443/centreon-map/api/beta/actuator/healthLa solution que nous recommandons est d'utiliser une méthode de clé reconnue, comme expliqué ci-dessus.
Sur le serveur Centreon MAP, créez un keystore.
Allez dans le dossier où Java est installé :
cd $JAVA_HOME/bin
Ensuite, générez un fichier keystore avec la commande suivante :
keytool -genkey -alias map -keyalg RSA -keystore /etc/centreon-map/map.jks
La valeur de l'alias "map" et le chemin du fichier keystore /etc/centreon-map/map.jks peuvent être modifiés, mais à moins d'une raison spécifique, nous conseillons de conserver les valeurs par défaut.
Fournissez les informations nécessaires lors de la création du keystore.
À la fin du formulaire, lorsque le "mot de passe de la clé" est demandé, utilisez le même mot de passe que celui utilisé pour le keystore lui-même en appuyant sur la touche Entrée.
Placez le fichier keystore ci-dessus (map.jks) dans le dossier /etc/centreon-map/, et définissez les paramètres ci-dessous dans /etc/centreon-map/map-config.properties :
centreon-map.keystore=/etc/centreon-map/map.jks
centreon-map.keystore-pass=xxx
Remplacez la valeur keystore-pass "xxx" par le mot de passe que vous avez utilisé pour le keystore et adaptez le chemin (s'il a été modifié dans le keystore).
Activer le profil TLS du service Centreon MAP
-
Arrêtez le service Centreon MAP :
systemctl stop centreon-map-engine -
Modifiez le fichier
/etc/centreon-map/centreon-map.conf, en ajoutant,tlsaprès le profilprod:RUN_ARGS="--spring.profiles.active=prod,tls" -
Définissez le paramètre
centreon.urldans /etc/centreon-map/map-config.properties pour activer le protocole de communication HTTPS avec le serveur Centreon :
centreon.url=https://<server-address>
-
Redémarrez le service Centreon MAP :
systemctl start centreon-map-engine
Le serveur MAP est maintenant configuré pour répondre aux demandes provenant de HTTPS sur le port 9443.
Pour modifier le port par défaut, reportez-vous à la procédure dédiée.
N'oubliez pas de modifier l'URL côté Centreon dans le champ Adresse du serveur Centreon MAP du menu Administration > Extensions > Map > Options.
Configurer TLS sur la connexion Broker
Une sortie Broker supplémentaire pour Centreon Central (centreon-broker-master) a été créée pendant l'installation.
Vous pouvez la vérifier dans votre interface web Centreon, à la page Configuration > Collecteurs > Configuration de Centreon Broker, en éditant la configuration centreon-broker-master.
La configuration éditée doit ressembler à ceci :

Configuration de Broker
Vous pouvez activer la sortie TLS et configurer la clé privée et le certificat public de Broker comme décrit ci-dessous :

- Pour créer un certificat auto-signé, vous pouvez utiliser les commandes suivantes :
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
- Et ensuite, copiez la clé privée et le certificat dans le répertoire /etc/centreon/broker_cert/ :
mv broker_private.key /etc/centreon/broker_cert/
mv broker_public.crt /etc/centreon/broker_cert/
Le champ "Trusted CA's certificate" est facultatif. Si vous activez l'authentification client de Broker en définissant ce "ca_certificate.crt", vous devez alors configurer un keystore pour le serveur MAP
Vous devez pousser la nouvelle configuration du broker et redémarrer le broker après la configuration.
Configuration du serveur MAP
Tout d'abord, vous devez activer HTTPS/TLS sur le serveur web
Ensuite, définissez les paramètres suivants dans la configuration du serveur MAP dans :
/etc/centreon-map/centreon-map.conf
Définissez le protocole de communication avec le serveur Centreon comme étant HTTPS :
centreon.url=https://<server-address>
Pour activer la connexion par socket TLS avec le Broker :
broker.tls=true
Configuration avec un certificat auto-signé
Si le certificat public de Broker est auto-signé, vous devez créer un trust store contenant le certificat donné ou son certificat CA avec la ligne de commande suivante :
keytool -import -alias centreon-broker -file broker_public.crt -keystore truststore.jks
- "broker_public.crt" est le certificat public de Broker ou son certificat CA au format PEM,
- "truststore.jks" est le trust store généré au format JKS,
- un mot de passe du trust store est requis pendant la génération.
Ensuite, mettez le fichier de sortie généré truststore.jks dans /etc/centreon-studio de l'hôte du serveur MAP.
- Ajoutez les paramètres de trust store dans /etc/centreon-map/map-config.properties :
centreon-map.truststore=/etc/centreon-map/truststore.jks
centreon-map.truststore-pass=XXXX
Remplacez la valeur "xxx" de trustStorePassword par le mot de passe que vous avez utilisé pour générer le trust store.
En attendant, vous devez activer le profil "tls_broker" du service Centreon MAP.
- Editez le fichier /etc/centreon-studio/centreon-map.conf, et remplacez ",tls" par ",tls_broker" après le profil "prod" :
RUN_ARGS="--spring.profiles.active=prod,tls_broker"
Le profil "tls_broker" implique le profil "tls". Ainsi, le service Centreon MAP sert nécessairement HTTPS.
Une fois que vous avez ajouté un truststore, Centreon MAP l'utilisera pour valider les certificats auto-signés.
Cela signifie que si vous utilisez un certificat auto-signé pour le serveur central, vous devez l'ajouter au truststore.
Si vous ne le faites pas, la page Supervision > Map sera vide, et les journaux (/var/log/centreon-map/centreon-map.log) afficheront l'erreur suivante : unable to find valid certification path to requested target.
-
Copiez le certificat .crt du serveur central sur le serveur MAP.
-
Ajoutez le certificat au truststore :
keytool -import -alias centreon-broker -file central_public.crt -keystore truststore.jks
Configuration avec un certificat CA reconnu
Si le certificat public de Broker est signé par une autorité de certification reconnue, le truststore par défaut de la JVM "cacerts /etc/pki/java/cacerts" sera utilisé. Il n'y a rien à configurer pour le service Centreon MAP.
Configurer TLS sur une base de données MySQL ou MariaDB
Cette section décrit comment activer SSL sur un serveur MySQL/MariaDB et configurer une application Spring Boot pour se connecter de manière sécurisée en utilisant la vérification de l'autorité de certification (mode VERIFY_CA).
Note : Cette procédure couvre uniquement le mode VERIFY_CA. Dans ce mode, le certificat du serveur est validé par une autorité de certification de confiance, mais le nom d’hôte/adresse IP n’est pas vérifié. Pour d’autres modes de vérification SSL, consultez la référence des modes SSL.
- Sélectionnez l’onglet correspondant à la base de données que vous souhaitez utiliser.
Étape 1 - Générer les clés et certificats
- MySQL
- MariaDB
1. Créez un répertoire (/etc/mysql/newcerts dans cet exemple) pour stocker vos fichiers de certificats :
mkdir -p /etc/mysql/newcerts
cd /etc/mysql/newcerts
2. Générez l’autorité de certification (CA). La CA est utilisée pour signer les certificats serveur et client, établissant une chaîne de confiance.
# 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. Générez le certificat serveur. Le certificat serveur est présenté par MySQL aux clients lors de la négociation SSL.
# 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. Générez le certificat client. Le certificat client est utilisé par l’application pour s’authentifier auprès de MySQL (TLS mutuel).
# 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. Vérifiez les certificats. Assurez-vous que les certificats sont correctement signés par la CA avant de continuer.
openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
# Expected output:
# server-cert.pem: OK
# client-cert.pem: OK
1. Créez un répertoire (/etc/mariadb/newcerts dans cet exemple) pour stocker vos fichiers de certificats :
mkdir -p /etc/mariadb/newcerts
cd /etc/mariadb/newcerts
2. Générez l’autorité de certification (CA). La CA est utilisée pour signer les certificats serveur et client, établissant une chaîne de confiance.
# 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. Générez le certificat serveur. Le certificat serveur est présenté par MariaDB aux clients lors de la négociation SSL.
# 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 MariaDB)
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. Générez le certificat client. Le certificat client est utilisé par l’application pour s’authentifier auprès de MariaDB (TLS mutuel). Ignorez cette section si vous n’avez besoin que de REQUIRE SSL.
# Générer la clé privée client et la CSR
openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem
# Convertir la clé client au format RSA
openssl rsa -in client-key.pem -out client-key.pem
# Signer le certificat client avec la 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. Vérifiez les certificats. Assurez-vous que les certificats sont correctement signés par la CA avant de continuer.
openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
# Résultat attendu :
# server-cert.pem: OK
# client-cert.pem: OK
6. Définissez la propriété des fichiers. MariaDB exige la propriété de tous les fichiers de certificats.
Étape 2 - Configurer le serveur MySQL/MariaDB
- MySQL
- MariaDB
1. Définissez la propriété des fichiers. MySQL exige la propriété de tous les fichiers de certificats.
Assurez-vous d’utiliser le répertoire créé précédemment (
/etc/mysql/newcertsdans cet exemple).
chown -Rv mysql:root /etc/mysql/newcerts/*
2. Modifiez la configuration du serveur MySQL. Ajoutez le bloc suivant à votre fichier de configuration MySQL (généralement /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
# Restreindre aux versions TLS sécurisées uniquement
tls_version = TLSv1.2,TLSv1.3
3. Optionnel - Modifiez la configuration du client MySQL. Cela permet à l’outil CLI mysql de se connecter en utilisant SSL.
4. Redémarrez MySQL.
systemctl restart mysqld
5. Vérifiez que SSL est actif.
Assurez-vous d’utiliser le répertoire créé précédemment (
/etc/mariadb/newcertsdans cet exemple).
1. Ajoutez le bloc suivant à votre fichier de configuration MariaDB (généralement /etc/mariadb/mariadb.conf.d/50-server.cnf) :
[mariadb]
ssl-ca = /etc/mariadb/newcerts/ca-cert.pem
ssl-cert = /etc/mariadb/newcerts/server-cert.pem
ssl-key = /etc/mariadb/newcerts/server-key.pem
# Restreindre aux versions TLS sécurisées uniquement
tls_version = TLSv1.2,TLSv1.3
2. Optionnel - Modifiez la configuration du client MariaDB. Cela permet à l’outil CLI mariadb de se connecter en utilisant SSL (/etc/mariadb/mariadb.conf.d/client.cnf) :
[client-mariadb]
ssl-ca = /etc/mariadb/newcerts/ca-cert.pem
ssl-cert = /etc/mariadb/newcerts/client-cert.pem
ssl-key = /etc/mariadb/newcerts/client-key.pem
4. Redémarrez MariaDB.
systemctl restart mariadb
5. Vérifiez que SSL est actif.
SHOW VARIABLES LIKE '%ssl%';
-- have_ssl doit être YES
-- ssl_ca, ssl_cert, ssl_key doivent pointer vers vos fichiers de certificats
Étape 3 - Configurer l’utilisateur MySQL/MariaDB
- MySQL
- MariaDB
1. Exigez SSL pour l’utilisateur.
2. Accordez les privilèges.
1. Exigez SSL pour l’utilisateur.
- SSL uniquement (aucun certificat client requis)
ALTER USER 'centreon_map'@'<ip_or_hostname>' REQUIRE SSL;
-- Ou TLS mutuel (certificat client requis)
-- ALTER USER 'centreon_map'@'<ip_or_hostname>' REQUIRE X509;
-- Vérification : ssl_type doit maintenant afficher ANY (pour SSL) ou X509 (pour mTLS)
SELECT user, host, ssl_type FROM mysql.user WHERE user='centreon_map';
2. Accordez les privilèges.
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
CREATE TEMPORARY TABLES, LOCK TABLES
ON `centreon_map`.*
TO `centreon_map`@`<ip_or_hostname>`;
-- Vérifiez les droits
SHOW GRANTS FOR 'centreon_map'@'<ip_or_hostname>';
Étape 4 - Configurer JDBC (Spring Boot)
- MySQL
- MariaDB
MySQL Connector/J ne prend pas en charge le chargement des fichiers PEM directement depuis l’URL JDBC. Java exige que les certificats soient stockés dans un JKS (Java KeyStore) ou un keystore PKCS12. Cela élimine les problèmes de format PEM (ex : PKCS#1 vs PKCS#8) et assure une configuration SSL fiable.
Au minimum, un fichier keystore est requis. Un second est nécessaire uniquement si le TLS mutuel (mTLS) est activé :
| Fichier | Contenu | Utilité | Requis |
|---|---|---|---|
| truststore.jks | Certificat CA | Permet à Java de vérifier l’identité du serveur MySQL | Oui - Toujours |
| keystore.jks | Certificat client + clé privée | Permet à MySQL de vérifier l’identité de l’application | Uniquement si REQUIRE X509 |
Remarque : mTLS est optionnel. Il n’est requis que si l’utilisateur MySQL a été créé avec REQUIRE X509 (authentification mutuelle). Si l’utilisateur a été créé avec REQUIRE SSL, seul le TrustStore est nécessaire et les étapes 2 et 2a/2b peuvent être ignorées.
1. Créez le TrustStore. Le TrustStore contient le certificat CA. Java l’utilise pour valider que le certificat du serveur MySQL a été signé par une autorité de confiance.
keytool -importcert -alias mysqlServerCACert \
-file /etc/mysql/newcerts/ca-cert.pem \
-keystore /etc/mysql/newcerts/truststore.jks \
-storepass changeit \
-noprompt
2. Optionnel : mTLS uniquement - Créez le KeyStore (certificat client).
Remarque : Ignorez cette étape si l’utilisateur MySQL a été créé avec REQUIRE SSL. Elle n’est requise que pour REQUIRE X509 (TLS mutuel).
keytoolne peut pas importer une clé privée PEM directement, il faut donc d’abord convertir en PKCS12, puis en JKS.
2.1. Regroupez le certificat client et la clé dans un fichier PKCS12 :
openssl pkcs12 -export \
-in /etc/mysql/newcerts/client-cert.pem \
-inkey /etc/mysql/newcerts/client-key.pem \
-out /etc/mysql/newcerts/client.p12 \
-name mysqlClient \
-passout pass:changeit
2.2 Convertissez PKCS12 en JKS :
keytool -importkeystore \
-srckeystore /etc/mysql/newcerts/client.p12 -srcstoretype PKCS12 -srcstorepass changeit \
-destkeystore /etc/mysql/newcerts/keystore.jks -deststoretype JKS -deststorepass changeit
3. Définissez les permissions des fichiers. Assurez-vous que seul l’utilisateur exécutant l’application Java peut lire les fichiers keystore.
chown your_java_user: /etc/mysql/newcerts/*.jks
chmod 640 /etc/mysql/newcerts/*.jks
4. Définissez l’URL JDBC. Ajoutez ce qui suit à votre fichier de configuration (/etc/centreon-map/*-database.properties) :
*.connection.url=jdbc:mysql://<ip_or_hostname>:3306/centreon_map?sslMode=VERIFY_CA&trustCertificateKeyStoreUrl=file:/etc/mysql/newcerts/truststore.jks&trustCertificateKeyStorePassword=changeit&rewriteBatchedStatements=true
5. Optionnel — uniquement si mTLS est activé (REQUIRE X509). Ajoutez les options clientCertificateKeyStoreUrl et clientCertificateKeyStorePassword :
*.connection.url=jdbc:mysql://<ip_or_hostname>:3306/centreon_map?sslMode=VERIFY_CA&trustCertificateKeyStoreUrl=file:/etc/mysql/newcerts/truststore.jks&trustCertificateKeyStorePassword=changeit&clientCertificateKeyStoreUrl=file:/etc/mysql/newcerts/keystore.jks&clientCertificateKeyStorePassword=changeit&rewriteBatchedStatements=true
Contrairement à MySQL Connector/J, MariaDB Connector/J 3.x prend en charge les fichiers PEM nativement via le paramètre serverSslCert directement dans l’URL JDBC. Aucune conversion keystore Java n’est nécessaire pour le mode SSL simple.
Un fichier keystore n’est requis que pour mTLS (authentification par certificat client) :
| Fichier | Contenu | Utilité | Requis |
|---|---|---|---|
| ca-cert.pem | Certificat CA | Permet au driver de vérifier l’identité du serveur MariaDB | Oui - Toujours |
| keystore.p12 | Certificat client + clé privée | Permet à MariaDB de vérifier l’identité de l’application | Uniquement si REQUIRE X509 |
Remarque : mTLS est optionnel. Il n’est requis que si l’utilisateur MariaDB a été créé avec REQUIRE X509. Si l’utilisateur a été créé avec REQUIRE SSL, seul serverSslCert pointant vers la CA est nécessaire et les étapes keystore ci-dessous peuvent être ignorées.
1. Optionnel - Créez le KeyStore pour mTLS.
Ignorez cette étape si l’utilisateur MariaDB a été créé avec REQUIRE SSL. Elle n’est requise que pour REQUIRE X509 (TLS mutuel).
keytool ne peut pas importer une clé privée PEM directement, il faut donc regrouper via PKCS12.
1.1. Regroupez le certificat client et la clé dans un fichier PKCS12 :
openssl pkcs12 -export \
-in /etc/mariadb/newcerts/client-cert.pem \
-inkey /etc/mariadb/newcerts/client-key.pem \
-out /etc/mariadb/newcerts/keystore.p12 \
-name mariadbClient \
-passout pass:changeit
2. Définissez les permissions des fichiers. Assurez-vous que seul l’utilisateur exécutant l’application Java peut lire les fichiers keystore.
chown your_java_user: /etc/mariadb/newcerts/keystore.p12
chmod 640 /etc/mariadb/newcerts/keystore.p12
3. Définissez les permissions des fichiers. Assurez-vous que seul l’utilisateur exécutant l’application Java peut lire les fichiers keystore.
chown your_java_user: /etc/mariadb/newcerts/*.jks
chmod 640 /etc/mariadb/newcerts/*.jks
4. Définissez l’URL JDBC. Ajoutez ce qui suit à votre fichier de configuration (/etc/centreon-map/*-database.properties) :
*.connection.url=jdbc:mariadb://<ip_or_hostname>:3306/centreon_map?sslMode=verify-ca&serverSslCert=/etc/mariadb/newcerts/ca-cert.pem&rewriteBatchedStatements=true
5. Optionnel — uniquement si mTLS est activé (REQUIRE X509). Ajoutez les options keyStore, keyStorePassword et keyStoreType :
*.connection.url=jdbc:mariadb://<ip_or_hostname>:3306/centreon_map?sslMode=verify-ca&serverSslCert=/etc/mariadb/newcerts/ca-cert.pem&keyStore=/etc/mariadb/newcerts/keystore.p12&keyStorePassword=changeit&keyStoreType=PKCS12&rewriteBatchedStatements=true
Étape 5 - Vérifier l’expiration des certificats
- MySQL
- MariaDB
Les certificats générés avec -days 365000 sont valides pour environ 1000 ans, mais cela doit tout de même être surveillé dans des environnements à durée de vie plus courte.
1. Vérifiez le TrustStore (certificat CA) :
keytool -list -v -keystore /etc/mysql/newcerts/truststore.jks -storepass changeit
# Recherchez : Valid from ... until ...
2. Vérifiez le KeyStore (certificat client) :
keytool -list -v -keystore /etc/mysql/newcerts/keystore.jks -storepass changeit
# Recherchez : Valid from ... until ...
1. Vérifiez le certificat CA.
openssl x509 -in /etc/mariadb/newcerts/ca-cert.pem -noout -dates
# notBefore=...
# notAfter=...
2. Vérifiez le certificat serveur.
openssl x509 -in /etc/mariadb/newcerts/server-cert.pem -noout -dates
3. Vérifiez le KeyStore (mTLS uniquement).
keytool -list -v -keystore /etc/mariadb/newcerts/keystore.p12 -storepass changeit
# Recherchez : Valid from ... until ...
Référence des modes SSL
- MySQL
- MariaDB
Le mode VERIFY_CA est le minimum recommandé en production. Ce tableau liste les autres modes disponibles selon vos exigences de sécurité :
| Mode | Certificat serveur vérifié | Nom d’hôte/IP vérifié | Cas d’utilisation |
|---|---|---|---|
DISABLED | Non | Non | Développement uniquement — pas de chiffrement |
PREFERRED | Non | Non | Utilise SSL si disponible, sinon connexion non sécurisée |
REQUIRED | Non | Non | Implique SSL, mais ne valide pas le certificat serveur |
VERIFY_CA | Oui | Non | Utilisé dans cette procédure — valide la chaîne CA |
VERIFY_IDENTITY | Oui | Oui | Le plus strict — vérifie aussi le nom d’hôte/IP dans le SAN du certificat |
Le mode VERIFY_CA est le minimum recommandé en production. Ce tableau liste les autres modes disponibles selon vos exigences de sécurité :
| Mode | Certificat serveur vérifié | Nom d’hôte/IP vérifié | Cas d’utilisation |
|---|---|---|---|
DISABLED | Non | Non | Développement uniquement — pas de chiffrement |
trust | Non | Non | Chiffre le trafic mais ne valide pas le certificat serveur |
VERIFY_CA | Oui | Non | Utilisé dans cette procédure — valide la chaîne CA |
verify-full | Oui | Oui | Le plus strict — vérifie aussi le nom d’hôte/IP dans le SAN du certificat |
Remarque : Si vous souhaitez utiliser le mode
verify-full, le certificat serveur doit inclure un champ Subject Alternative Name (SAN) correspondant exactement à l’IP ou au nom d’hôte utilisé dans l’URL JDBC. Le champ CN seul n’est pas suffisant pour les connexions basées sur l’IP.