Pour que nous puissions voir dans l’outil de surveillance si et quand un certificat SSL expire, un Script a été écrit pour déterminer la date d’expiration. Comparé à d’autres contrôles, ce script ne peut pas seulement vérifier les certificats via HTTPS.
Vous trouverez ici une description de la façon d’obtenir la date d’expiration d’un certificat SSL.

openssl s_client -servername "${HOST}" -connect "${HOST}":"${PORT}" 2>&- | openssl x509 -enddate -noout

Pour pouvoir vous connecter à un hôte SSL, vous avez d’abord besoin d’un client SSL. Ici le s_client d’OpenSSL est utilisé, qui supporte aussi TLS. Le s_client est généralement utilisé pour diagnostiquer et déboguer les certificats SSL/TLS.

servername

Le paramètre “nom du serveur” peut être utilisé pour vérifier que le certificat correct est utilisé si un serveur possède plusieurs certificats SSL via VHosts.
Cela se fait via SNI (Server Name Indication).

connect

Ici, la connexion à l’hôte est établie via le nom et le port de l’hôte.

openssl x509 -enddate -noout

Maintenant le certificat x509 est lu et la date d’expiration est donnée par les paramètres “endddate” et “noout” respectivement que le certificat n’est plus valide après la date XY. La sortie restante est empêchée par “noout”.

Alarme, Alarme !

L’objectif était de pouvoir déterminer comment et quand les alertes Nagios / Icinga sont envoyées. Pour alerter Nagios / Icinga, il a besoin du Error Status Code 2. Error Codes :

• 1 – Warning
• 2 – Critical
  0 est OK, bien sûr. Les paramètres de réglage de l’avertissement et des valeurs critiques sont affectés. sont des valeurs standard :
• Warning=30 (jours)
• Critical=5 (jours)
  La date d’expiration est comparée à la date du jour, de sorte que vous pouvez voir combien de jours il vous reste avant que le certificat expire.
  Le script de monitoring est disponible surGitHub.

Intégration dans la surveillance

Le script est exécuté par nous en tant que plugin Icinga.
Les commandes sont définies dans le fichier de configuration “/etc/icinga/icinga/icinga.cfg” ou sont décrites là où elles sont définies.
Voici un extrait de la configuration Icinga :

define command {
    command_name check _ssl
    command_line /bin/bash $USER1$/check_ssl.sh -H $ARG1$ -p $ARG2$ -P $ARG3$ -w $ARG4$ -c $ARG5$
}

Les variables $ARG$ sont alors données par une définition de service qui se trouve par défaut dans /etc/icinga/objects/services_icinga.cfg.
C’est ainsi que le service de vérification SSL est défini pour un hôte :

define service {
        use                             template-service
        host_name                       Hostname (e.g. adfinis.com)
        service_description             check_ssl
        max_check_attempts              5
        check_interval                  360
        retry_interval                  1
        check_command                   check _ssl!'adfinis.com'!'443'!'no_tls'!'30'!'5'
}

Dans la ligne check_command, les variables $ARG$ sont séparées par des points d’exclamation et sont ensuite affectées dans cet ordre. C’est à dire :

• adfinis.com = $ARG1
• 443 = $ARG2$
• no_tls = $ARG3$
• 30 = $ARG4$
• 5 = $ARG5$

Links

• IcingaExchange
• GitHub