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

Posté par Glandos le 03 janvier 2018 à 22:06. Licence CC By‑SA.

Étiquettes :

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 Pol' uX (site web personnel) le 03 janvier 2018 à 22:48. Évalué à 7.

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 Glandos le 03 janvier 2018 à 22:57. Évalué à 2.
  
  Merci beaucoup :)
  
  Au moins, ça sera dispo pour les autres.
- [^] # Re: Probablement pas mieux mais très répendu
  
  Posté par claudex le 04 janvier 2018 à 11:33. Évalué à 5.
  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 Larry Cow le 05 janvier 2018 à 11:53. Évalué à 2.
    
    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 Laurent J (site web personnel, Mastodon) le 04 janvier 2018 à 11:42. Évalué à 3.
  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 Pol' uX (site web personnel) le 04 janvier 2018 à 12:18. Évalué à 3.
    
    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 Laurent J (site web personnel, Mastodon) le 04 janvier 2018 à 13:21. Évalué à 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 kna le 04 janvier 2018 à 14:25. Évalué à 5.
        
        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 peikk0 le 04 janvier 2018 à 23:48. Évalué à 3.
        
        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.
        
        [^] # Re: Probablement pas mieux mais très répendu
        
        Posté par flan (site web personnel) le 05 janvier 2018 à 07:35. Évalué à 3.
        
        Accessoirement, il n'y a même pas de renouvellement (donc aucune requête) quand le certificat est encore largement valide (plus de 10 jours, je crois).
        
        [^] # Re: Probablement pas mieux mais très répendu
        
        Posté par peikk0 le 06 janvier 2018 à 12:28. Évalué à 1.
        
        La plupart des clients (dont certbot) renouvellent à 30 jours de l'expiration, il me semble que c'est la recommandation officielle.
# Rien à faire

Posté par ohm le 04 janvier 2018 à 00:45. Évalué à 4.

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 ʭ ☯ le 04 janvier 2018 à 09:15. Évalué à 4.
  
  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 Laurent J (site web personnel, Mastodon) le 04 janvier 2018 à 11:37. Évalué à 3.
  
  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 kna le 04 janvier 2018 à 12:27. Évalué à 3.
    
    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.
    - [^] # Re: Rien à faire
      
      Posté par kna le 04 janvier 2018 à 14:26. Évalué à 6.
      
      Oups, c'est pas standalone c'est certonly
# ssl-cert-check

Posté par Gauthier Monserand (site web personnel) le 04 janvier 2018 à 09:25. Évalué à 6.

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 Glandos le 04 janvier 2018 à 12:46. Évalué à 1.
  
  Ç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 Mimoza le 04 janvier 2018 à 17:45. Évalué à 3.
  
  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 Glandos le 05 janvier 2018 à 10:13. Évalué à 2.
    
    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 gaston le 04 janvier 2018 à 13:31. Évalué à 6.
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 jraf le 09 janvier 2018 à 18:31. Évalué à 0.

Moi j'utilise https://keychest.net/home

Suivre le flux des commentaires

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