Superviser un site HTTPS et son certificat SSL avec Centreon

Un site peut répondre en 200 et afficher une page d'erreur, ou fonctionner parfaitement jusqu'au jour où son certificat expire. Trois contrôles Centreon couvrent ces trois risques.

Un serveur web qui répond n'est pas forcément un service qui fonctionne. Cette page combine trois contrôles avec Centreon 25.10 : le temps de réponse, le contenu attendu dans la page et la date d'expiration du certificat. Les deux premiers viennent du connecteur HTTP Server, le troisième du connecteur X509 Certificate. Validez chaque commande depuis un collecteur de test avant de l'appliquer à vos sites de production.

RisqueContrôleModèle de service Centreon
site lent ou injoignabletemps de réponse et code HTTPApp-Protocol-HTTP-Response-Time-custom
page d'erreur servie en 200présence d'une chaîneApp-Protocol-HTTP-Expected-Content-custom
certificat bientôt expiréjours restantsApp-Protocol-X509-Certificate-custom

Prérequis selon la documentation : le site doit être joignable en HTTP ou HTTPS depuis le collecteur, éventuellement via un proxy. Le connecteur HTTP Server ne gère que l'authentification BASIC ou NTLM v1/v2, il ne sait donc pas tester une page derrière un portail SSO.

Installer les deux connecteurs

Installez les packs depuis Configuration > Connectors > Monitoring Connectors, puis les plugins sur chaque collecteur concerné, ou laissez l'installation automatique le faire. À la main, sur Alma Linux ou RHEL :

dnf install centreon-plugin-Applications-Protocol-Http
dnf install centreon-plugin-Applications-Protocol-X509

Sur Debian, les noms sont en minuscules (centreon-plugin-applications-protocol-http, centreon-plugin-applications-protocol-x509). Le détail du processus est décrit dans la page sur la supervision avec Centreon et ses connecteurs.

Temps de réponse et code HTTP

Le modèle d'hôte App-Protocol-HTTP-custom crée automatiquement le service HTTP-Response-Time. Pour un site HTTPS, réglez les macros d'hôte PROTOCOL sur https et PORT sur 443, puisque les valeurs par défaut sont http et 80. Testez d'abord sous le compte centreon-engine :

/usr/lib/centreon/plugins/centreon_protocol_http.pl --plugin=apps::protocols::http::plugin --mode=response --hostname=www.example.com --proto='https' --port='443' --urlpath='/'

Le mode response accepte des seuils de temps (--warning-time, --critical-time, en secondes) et des conditions sur le code de réponse (--warning-status, --critical-status). Ses métriques séparent la résolution DNS, la connexion, la négociation TLS et le transfert, ce qui aide à savoir où se perd le temps.

Contenu attendu dans la page

Le service HTTP-Expected-Content n'est pas créé automatiquement : ajoutez-le à l'hôte avec le modèle App-Protocol-HTTP-Expected-Content-custom, puis remplissez :

La documentation précise que --expected-string='motif' est un raccourci pour --critical-content='%{content} !~ /motif/mi', et recommande d'utiliser directement --critical-content. Les variables %{content}, %{header}, %{first_header} et %{code} permettent aussi de tester un en-tête ou le code HTTP.

Choisissez une chaîne qui n'apparaît que si l'application fonctionne vraiment : un libellé produit par la base de données plutôt que le titre statique du site. C'est ce qui distingue un vrai contrôle applicatif d'un simple ping web.

Supervision du certificat SSL avec X509

Le connecteur X509 Certificate mesure le temps restant avant l'expiration d'un certificat. Le modèle d'hôte App-Protocol-X509-custom crée le service X509-Certificate. Ses macros :

MacroRôleValeur par défaut
CUSTOMMODEméthode de lecture : file, https, opensslcli ou tcptcp
PORTport du service443
WARNINGSTATUScondition d'alerte%{expiration} < 60
CRITICALSTATUScondition critique%{expiration} < 30

Les conditions acceptent aussi %{subject}, %{issuer} et %{alt_subjects}. L'exemple de la documentation déclenche un état critique si le certificat expire dans moins de 30 jours ou ne couvre pas le nom attendu :

/usr/lib/centreon/plugins/centreon_protocol_x509.pl --plugin=apps::protocols::x509::plugin --mode=certificate --custommode='tcp' --hostname='www.example.com' --port=443 --critical-status='%{expiration} < 30 || %{alt_subjects} !~ /www.example.com/'

Les valeurs de 60 et 30 jours sont des défauts, pas une recommandation universelle. Fixez-les selon votre délai réel de renouvellement : le temps de commander, valider et déployer un certificat, plus une marge pour les congés. Un certificat renouvelé automatiquement mérite quand même ce contrôle, car c'est précisément l'échec du renouvellement qu'il détecte.

Le même connecteur sert pour tout service qui présente un certificat X509, pas seulement un site web : interface d'administration d'un serveur, comme la supervision HPE iLO, ou d'une imprimante réseau. Pour Exchange, combinez-le avec la supervision d'Exchange par NRPE et NSClient++. La rubrique Centreon regroupe les autres équipements.

Questions fréquentes

Comment superviser la date d'expiration d'un certificat SSL avec Centreon ?

Avec le connecteur X509 Certificate : appliquez le modèle App-Protocol-X509-custom à l'hôte, réglez le port, puis ajustez WARNINGSTATUS et CRITICALSTATUS, qui valent par défaut moins de 60 et moins de 30 jours.

Quelle différence entre HTTP-Response-Time et HTTP-Expected-Content ?

Le premier mesure le temps de réponse et peut juger le code HTTP. Le second vérifie qu'une chaîne précise figure dans la page, ce qui détecte une page d'erreur servie avec un code 200.

Peut-on tester une page protégée par mot de passe ?

Oui en authentification BASIC ou NTLM v1/v2. Le connecteur ne gère pas les pages derrière un portail SSO, selon sa documentation.

Peut-on vérifier qu'un certificat couvre le bon nom ?

Oui. La condition peut utiliser %{alt_subjects}, par exemple pour passer en critique si le nom attendu n'y figure pas.

Existe-t-il une alternative sans connecteur Centreon ?

Le plugin check_curl du projet Monitoring Plugins vérifie aussi un site et le nombre minimal de jours de validité d'un certificat avec son option -C. Il s'intègre comme commande personnalisée.