Je reçois des mails de letsencrypt me disant que mes certificats arrivent à expiration pour mes différents domaines. Ils ne sont pas renouvelés, alors que la commande est bien lancée par le cron deux fois par jours.

Cependant, quand je lance le certbot à la main, les certificats se renouvellent. #TuTeFousDeMaGueule

Et dans les logs de la commande, je peux voir ce message :

Upgrading certbot-auto 1.8.0 to 1.10.1...
Replacing certbot-auto...
Your system is not supported by certbot-auto anymore.
Certbot will no longer receive updates.
Please visit https://certbot.eff.org/ to check for other alternatives.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/monDomaine.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...

Il semble que Debian 8 ne soit plus supporté, comme on peut le voir dans la liste d'OS sur le site de certbot. En effet, certbot-auto a été déprécié pour tous les systèmes, sauf ceux basés sur Debian et RHEL.

Alors je pose la question : Debian 8 n'est-il pas basé sur Debian ? #OnMAuraitMenti

Je sais que la version 8 commence à dater un peu, mais bon sang ! Décider unilatéralement d'arrêter un service comme ça sans prévenir, c'est comme manger une raclette sans pommes de terre. Ca ne se fait pas.

Lors de la création d'un job dans Jenkins, il se peut que l'erreur suivante apparaisse au moment d'indiquer le repository à suivre :

Failed to connect to repository : Command "git ls-remote -h https://monsite.com/scm/mon_repo.git HEAD"

Voire même :

Failed to connect to repository : Command "git ls-remote -h https://monsite.com/scm/mon_repo.git HEAD" returned status code 128:
stdout:
stderr: fatal: unable to access 'https://monsite.com/scm/mon_repo.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Cela arrive quand le serveur contenant les répo utilise un certificat SSL auto-signé. Pour remédier à ce problème, il faut :

• extraire le certificat du site contenant les repository au format x509 (généralement un fichier crt);
• puis copier ce certificat dans le répertoire /etc/ssl/certs/ du serveur hébergeant Jenkins.

Jenkins devrait maintenant accepter le répo sans broncher.

Il est désormais possible de demander des certificats wildcards avec Let's Encrypt! C'est à dire *.domaine.fr.

Un générateur de configuration SSL pour différents serveurs web (Apache, Nginx, ...).
Il prend en compte les versions des softs ainsi que la compatibilité recherchée avec les navigateurs.

Un ensemble de conférences sur le SSL/TLS, l'email, le BGP, le droit en informatique, les infrastructures réseau...
On y retrouve notamment Benjamin Bayard.

Dans le cadre de la configuration de ELK, il faut faire communiquer Logstash et Filebeat, qui se trouvent chacun sur un serveur différent. Dans cette optique, il est nécessaire que la communication soit chiffrée.
Il faut donc générer:

• Un fichier contenant la clef privée
• Un fichier contenant le certificat
• Un fichier contenant l'autorité de certification, qui sert à signer le certificat.

Les configurations de Filebeat (filebeat.yml) et Logstash (xyz.conf) devront faire alors appel à ces fichiers. Voir la première partie de cette page pour la config des fichiers.

Pour mémoire.
Il s'agissait pour moi de faire l'inverse en fait, c'est à dire de ne pas forcer la connexion en https.
Pour cela, il faut aller dans le fichier /etc/apache2/sites-available/monsite.conf et commenter les lignes suivantes:
RewriteEngine on
RewriteCond "quelquechose"
RewriteRule "quelquechose d'autre"
Puis ajouter la ligne suivante:
RewriteEngine off