Journal Vérification des certificats X.509 sur le point d'expirer

Posté par . Licence CC by-sa
8
3
jan.
2018

Comme beaucoup, j'utilise Let's Encrypt.
J'ai pas mal automatisé le renouvellement avec acme-tiny, mais il me manque surtout le petit truc qui me dit quand le certificat n'est plus valide. Et si possible, avant que ça arrive.

C'est là : https://framagit.org/Glandos/lets_check

C'est simple. Éditez le script pour y mettre votre délai en jours, et vos noms d'hôtes, et lancez-le. S'il y a un problème, ça l'écrit. Si tout va bien, rien n'est écrit. C'est donc tout à fait compatible cron.

Alors, oui, c'est probablement du NIH. Je sais pas trop. Si ça existe déjà, en mieux et pas trop complexe, merci de me le dire, j'y ai passé à peine deux heures, donc ça va, c'est pas trop perdu.

  • # Probablement pas mieux mais très répendu

    Posté par (page perso) . Évalué à 7 (+6/-0).

    Alors, oui, c'est probablement du NIH. Je sais pas trop. Si ça existe déjà, en mieux et pas trop complexe, merci de me le dire, j'y ai passé à peine deux heures, donc ça va, c'est pas trop perdu.

    Check_http, dans monitoring-plugins-basic :

    $ /usr/lib/nagios/plugins/check_http -C 30 linuxfr.org --sni --ssl
    OK - Certificate '*.linuxfr.org' will expire on dim. 03 juin 2018 00:59:00 CEST.

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Probablement pas mieux mais très répendu

      Posté par . Évalué à 2 (+2/-0).

      Merci beaucoup :)

      Au moins, ça sera dispo pour les autres.

    • [^] # Re: Probablement pas mieux mais très répendu

      Posté par (page perso) . Évalué à 5 (+2/-0).

      Et si on n'a pas monitoring-plugins-basic. Il y a openssl en un peu moins user friendly:

      $ openssl s_client -connect linuxfr.org:443 -servername linuxfr.org < /dev/null | openssl x509 -checkend $(( 30 * 86400 ))                                                                                                
      depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
      verify return:1
      depth=1 C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2
      verify return:1
      depth=0 OU = Domain Control Validated, OU = Gandi Standard Wildcard SSL, CN = *.linuxfr.org
      verify return:1
      DONE
      Certificate will not expire
      

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Probablement pas mieux mais très répendu

        Posté par . Évalué à 2 (+0/-0).

        Moins user-friendly, mais ça a un gros intérêt : ça permet de découpler résolution DNS et connexion TLS. Et du coup, de vérifier ton certificat par deux chemins distincts (e.g. que le certificat est bien à jour sur le serveur applicatif pour les clients internes ET sur le reverse-proxy pour ceux du dehors).

    • [^] # Re: Probablement pas mieux mais très répendu

      Posté par (page perso) . Évalué à 3 (+1/-0).

      C'est valable si on n'a pas accès au serveur. Mais dans le cas présent, la vérification se fait sur le serveur qui stocke le certificat, donc plutôt que de faire une requête HTTP, autant lire directement le fichier du certificat, ça sera plus rapide

      DOMAIN_CRT=/chemin/vers/fichier.crt
      ENDDATE=$(openssl x509 -in $DOMAIN_CRT -noout -enddate | cut -d= -f2-)
      DAYSREMAINING=$(( (`date -d "$ENDDATE" +%s` - `date -d "00:00" +%s`) / (24*3600) ))
      
      if [ $DAYSREMAINING -lt 5 ]
      then
        # il reste moins de 5 jours, renouvelons
       ...
      fi
      
      • [^] # Re: Probablement pas mieux mais très répendu

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Yep mais du coup tu ne vérifies pas ce que ton navigateur sert à ses clients. :)

        Sinon, dans la même logique, pas besoin de vérifier le fichier : il « suffit » d'exécuter certbot (ou un de ses amis) pour que le certificat soit à jour. :)

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Probablement pas mieux mais très répendu

          Posté par (page perso) . Évalué à 1 (+0/-1).

          Yep mais du coup tu ne vérifies pas ce que ton navigateur sert à ses clients. :)

          s/navigateur/serveur je suppose ? ;-)

          Certes, mais normalement, il n'y a qu'un fichier cert pour le domaine en question sur la machine. Si le serveur ne le trouve pas, il ne voudra pas démarrer, et la vérification par http ne garanti pas que le nouveau est bien pris en compte, sauf si tu mémorises via ton script le nombre de régénération effectuées et mis en place des alertes si ce nombre devient anormalement élevé sur une période de 90 jours.

          Qui plus est, sur une infra digne de ce nom, tu as déjà des sondes qui vérifient tes services web, donc qui te remontent les problèmes de connexions foireuses causés par des certificats invalides ;-)

          Sinon, dans la même logique, pas besoin de vérifier le fichier : il « suffit » d'exécuter certbot (ou un de ses amis) pour que le certificat soit à jour. :)

          Quand tu héberges plusieurs domaines, ce n'est pas trop recommandé, d'une part parce que cela va provoquer des rechargements intempestifs de la config du serveur web, et d'autres parts parce que tu as des quotas au niveau de letsencrypt. Certes, ils sont assez élevés pour un usage normal, mais ce n'est pas une raison d'entamer ton quota et de participer un peu plus à la charge des serveurs letsencrypt (ne pas abuser d'un service gratuit permet de faire en sorte qu'il reste gratuit et qu'il ne réduise pas les quotas)

          • [^] # Re: Probablement pas mieux mais très répendu

            Posté par . Évalué à 5 (+3/-0).

            Quand tu héberges plusieurs domaines, ce n'est pas trop recommandé, d'une part parce que cela va provoquer des rechargements intempestifs de la config du serveur web, et d'autres parts parce que tu as des quotas au niveau de letsencrypt. Certes, ils sont assez élevés pour un usage normal, mais ce n'est pas une raison d'entamer ton quota et de participer un peu plus à la charge des serveurs letsencrypt (ne pas abuser d'un service gratuit permet de faire en sorte qu'il reste gratuit et qu'il ne réduise pas les quotas)

            cerbot --renew ne renouvelle le certificat que si la date d'expiration est proche (< 1 mois). Le reload est à mettre en post-hook et n'est exécuté que lorsque le certificat est effectivement renouvellé (du moins, si généré avec certbot certonly). Tu peux donc le lancer tous les jours, le renouvellement/reload ne sera fait qu'une fois tous les 2 mois. Et ça t'évite de louper un renouvellement parce qu'un problème t'empêche de le faire à un instant t.

          • [^] # Re: Probablement pas mieux mais très répendu

            Posté par (page perso) . Évalué à 3 (+2/-0).

            Le rate limit est seulement sur les nouveaux certificats, pas sur les renouvellements. https://letsencrypt.org/docs/rate-limits/

            Concernant le check, tu veux aussi vérifier que ton serveur a bien reload le nouveau certificat après un renouvellement au lieu de continuer à servir l'ancien qui va expirer.

  • # Rien à faire

    Posté par . Évalué à 4 (+3/-0).

    Sinon tu lances le client letsencrypt genre toutes les 4 semaines, et il ne générera un nouveau certificat que s'il expire dans moins d'un mois. C'est fait pour.

    • [^] # Re: Rien à faire

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Je crois bien qu'il est conseillé de le lancer plutôt tous les jours, pour être plus réactif en cas de faiblesse découverte.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Rien à faire

      Posté par (page perso) . Évalué à 3 (+2/-1).

      Il n'utilise pas le client letsencrypt "officiel", mais acme_tiny, beaaaaaauuuucoup moins usine à gaz, et qui s'intègre plus facilement dans des infra configurées automatiquement.

      Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification. Ce qui était absolument inacceptable pour l'infra que je configurais.

      Avec des outils légers comme acme_tiny, il y a juste un alias .well-known à configurer dans le serveur web, et à faire un reload une fois le certificat regénéré. Et optionnellement à ajouter une petite vérification de la validité du certificat dans le script que tu installes en cron.

      • [^] # Re: Rien à faire

        Posté par . Évalué à 3 (+1/-0).

        Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification.

        Il y a un module standalone, tu lui indiques juste les domaines et docroot, il ne touche pas au service web.

  • # ssl-cert-check

    Posté par (page perso) . Évalué à 6 (+5/-0).

    De mon coté j'utilise ssl-cert-check pour vérifier mon certificat, comme ça je n'ai pas besoin de l'inventer ici :)

    https://github.com/Matty9191/ssl-cert-check

    • [^] # Re: ssl-cert-check

      Posté par . Évalué à 1 (+0/-0).

      Ça, ça a l'air d'être le genre de script que j'aurais bien écrit.

      Bon, c'est en bash, mais en bash lisible.

    • [^] # Re: ssl-cert-check

      Posté par . Évalué à 3 (+1/-0).

      C'est d'ailleur une recommandation dans le descriptif du projet cité ici :

      DO NOT USE. Prefer https://github.com/Matty9191/ssl-cert-check

      • [^] # Re: ssl-cert-check

        Posté par . Évalué à 2 (+1/-0).

        Oui, je l'ai mis dans le dépôt après avoir utilisé ssl-cert-check.
        Je n'aime pas tomber sur des dépôts en jachère sans savoir quoi utiliser, donc j'essaie d'être poli avec les autres. Et ne pas supprimer le dépôt non plus, vu que je l'ai annoncé publiquement.

        Mais je suis passé à ssl-cert-check. Ça couvre parfaitement mon besoin. C'est en bash (bof), ça forke de partout (bof, mais en shell, on fait pas autrement), ça dépend de openssl (bof aussi, mais ça gère le starttls de base), mais c'est lisible et le développement est actif.

  • # Monit

    Posté par . Évalué à 6 (+5/-0).

    En perso et en pro (et aussi parce qu'il vérifie déjà plein d'autres choses) j'utilise https://mmonit.com/monit/documentation/monit.html

    Avec cet extrait de config:

    set alert moi@domaine
    
    check host cert_valid_for_fqdn with address my.fqdn every '0 1 * * *'
      if failed port 443 protocol https and certificate valid > 7 days then alert
    

    Il va vérifier la date du cert servi aux clients à 1h du matin, et m'alerter si la date d'expiration est dans moins d'une semaine.

  • # Dans le cloud

    Posté par . Évalué à 0 (+0/-0).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.