En essayant de builder une application avec maven, j'ai obtenu cette erreur :

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Traduction : maven a un problème de vérification de certificat SSL pour l'accès à un artifactory (dans mon cas).

Remède proposé (et testé par moi-même) : ajouter des options à la ligne de commande de maven afin de lui faire ignorer ces erreurs SSL :

mvn clean install -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true

Note : maven utilisé en version 3.8.4

Une interview très intéressante de Catherine Austin Fitts et Valérie Bugault, qui abordent le sujet d'actualité du passeport sanitaire (dit aussi passeport vert) en le liant (entre autres) aux monnaies numériques étatiques (euro et dollar), au déficit de démocratie dans les sociétés occidentales (et à l'escroquerie du système électif couplée à l'impunité des élus), ainsi qu'au désir des européistes d'aller vers toujours plus de contrôle et de surveillance (en invoquant la sécurité sanitaire des habitants).

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.

Le protocol ACMEv1 sera abandonné par Letsencrypt à partir du 01/06/2020. Si vous avez installé certbot (ou un autre client) il y a longtemps (plusieurs mois ou plusieurs années), pensez à le mettre à jour/

Pour Certbot, suivez le lien de ce post. Il faudra simplement désintaller l'ancien client, puis installer le nouveau.

La ligne de commande de renouvellement (généralement lancée dans une tâche CRON) devra être modifiée pour lancer non plus certbot mais certbot-auto.

Pour être sûr que votre certificat est bien passé en ACMEv2, ouvrez la configuration de renouvellement du certificat :

cat /etc/letsencrypt/renewal/nomdemondomaine.conf | grep -E "server"

Vous devriez obtenir https://acme-v02.api.letsencrypt.org/directory

Besoin :

Je veux ajouter un certificat SSL à mon apt.

Procédure :

Je lance la commande suivante (en adaptant les valeurs) :

apt-key adv --keyserver keyring.debian.org --recv-keys 0x1827364554637281

Problème :

J'obtiens le message d'erreur suivant dans la console :

Executing: /tmp/apt-key-gpghome.jm0CXrmSHQ/gpg.1.sh --keyserver keyring.debian.org --recv-keys 0x1827364554637281
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/tmp/apt-key-gpghome.jm0CXrmSHQ/S.dirmngr' failed: No such file or directory
gpg: keyserver receive failed: No dirmngr

La partie importante est No dirmngr.

Remède :

Il faut installer l'outil dirmngr :

sudo apt install dirmngr

La commande d'ajout du certificat peut alors être lancée.

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.

Quand le mec qui gère un repo distant ne crée pas de certificat SSL, ça donne ça:

git push origin master
fatal: unable to access 'https://truc.machin.fr/mon/repo/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Pour contourner ce grave problème de sécurité, il faut lancer la commande suivante dans le repo local:

git config http.sslVerify "false"

Il ne reste plus qu'à remettre la tête dans le sable...

Edit : S'il s'agit d'un répo devant être cloné :

GIT_SSL_NO_VERIFY=true git clone https://url
cd directory/
git config http.sslVerify "false"