Certbot : sudo certbot certificates en erreur

Bonjour,
Sans autre modification que mise à jour de jeedom (sans que la corrélation n’ait été prouvée), la commande « certbot certificates » revoie une erreur « RuntimeError: OpenSSL 3.0’s legacy provider failed to load. » (détail en fin de post).
Historique : Mon installation de certificat a été réalisée avec le tuto « Piloter Jeedom depuis l'extérieur en HTTPS – Jeedomiser.fr » et a fonctionné correctement plusieurs mois et avec 2 renouvellements réussi (en manuel).
Je n’ai pas d’erreur dans la page « santé » et les package OS sont OK
Mon jeedom est toujours accessible sur internet en https via No-IP (livebox oblige !).
Juste une info : Monitor ne veut plus se mettre à jour (mais je suis en debian 10) : A mon avis sans corrélation avec le pb.
Pouvez-vous me donner des pistes.


Traceback (most recent call last):
  File "/snap/certbot/4183/bin/certbot", line 5, in <module>
    from certbot.main import main
  File "/snap/certbot/4183/lib/python3.12/site-packages/certbot/main.py", line 6, in <module>
    from certbot._internal import main as internal_main
  File "/snap/certbot/4183/lib/python3.12/site-packages/certbot/_internal/main.py", line 20, in <module>
    import josepy as jose
  File "/snap/certbot/4183/lib/python3.12/site-packages/josepy/__init__.py", line 40, in <module>
    from josepy.json_util import (
  File "/snap/certbot/4183/lib/python3.12/site-packages/josepy/json_util.py", line 24, in <module>
    from OpenSSL import crypto
  File "/snap/certbot/4183/lib/python3.12/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import SSL, crypto
  File "/snap/certbot/4183/lib/python3.12/site-packages/OpenSSL/SSL.py", line 11, in <module>
    from OpenSSL._util import (
  File "/snap/certbot/4183/lib/python3.12/site-packages/OpenSSL/_util.py", line 6, in <module>
    from cryptography.hazmat.bindings.openssl.binding import Binding
  File "/snap/certbot/4183/lib/python3.12/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 15, in <module>
    from cryptography.exceptions import InternalError
  File "/snap/certbot/4183/lib/python3.12/site-packages/cryptography/exceptions.py", line 9, in <module>
    from cryptography.hazmat.bindings._rust import exceptions as rust_exceptions
RuntimeError: OpenSSL 3.0's legacy provider failed to load. This is a fatal error by default, but cryptography supports running without legacy algorithms by setting the environment variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY. If you did not expect this error, you have likely made a mistake with your OpenSSL configuration.

Bonjour,

Pas la peine d’écrire aussi gros :wink:

As-tu fait une recherche sur le message d’erreur ?

Boujour,
C’est vrai que cela flashe ! : Toutes mes excuses. La taille de la police de réponse est un mystère (copié-collé je pense).
Sur le fond, concernant l’erreur, j’ai vu qu’on pouvait baisser la sécurité en modifiant la variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY mais je n’ai pas essayé : A moins d’avoir l’info qu’une récente mise à jour aurait renforcé la sécurité, je ne vois pas de raison de le faire.
Certains conseillent aussi de désinstaller le package et de recommencer l’installation d’un nouveau certificat. C’est un peu radical en première approche et je ne suis pas sûr que cela aboutisse. Il y a peut-être un service à relancer, des dépendances … ?

Comment savoir si OpenSSL a changé entre octobre et novembre, c’est à dire entre mes deux mise à jour jeedom ?
N’y aurait-il pas des nouveaux packages ou plugin qui ne seraient plus réellement compatibles avec debian 10. Sur RPI 3b je ne peux plus faire évoluer debian d’après ce que je comprends.

Oui clairement de plus en plus de choses vont arrêter de fonctionner sous Debian 10.

Pourquoi pas possible de passer sous Debian 11 avec un Pi3b ? Peut-être un peu juste en RAM pour Jeedom c’est tout.

Bonjour,
Merci pour ta réponse.
Je viens de tomber sur un post « Erreur OpenSSL lors du renouvellement de mon certificat HTTPS » très récent qui semble parler du même sujet. Je vais creuser.
Cependant, j’ai vraiment peur que passer sur debian 11 avec RPI3B me lance dans une nouvelle galère, avec des débordements mémoire.
J’envisageais de passer sur RPI5 avec MVMe mais le concept lowcost du RPI en prend un coup : J’attends le black friday pour voir si les tarifs évoluent .
En attendant, changer la variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY a-t-il un sens et quel est le risque encouru ?

Tu me fais marcher rassure-moi ? :sweat_smile: C’est le post que je viens de citer 2 fois dans ton sujet :rofl:

Attention pi5 = Debian 12 = Jeedom bêta + comptabilité plugins à vérifier (seul Debian 11 est officiellement supporté pour le moment).

Sinon pi4 + SSD en msata.

C’est pas faux ! J’ai cherché par moi même en parallèle de la réponse. Désolé.
Dois-je en déduire que pour RPI3B et debian 10, c’est cuit ?

Oui c’est cuit

ERRATUM le 08/01/25 ->>>> Problème résolu !
Bonjour,
Suite aux nombreux échanges et collaborations, il a été statué que certificat ne pouvait plus être renouvelé en debian 10 / jeedom 4.4.19,
.… jusqu’à ce jour !!!
Le monitoring que j’avais mis en place a retourné une valeur aujourd’hui indiquant la date d’expiration le 03/01/25 et disant que le certificat avait expiré.
La commande fonctionnait donc à nouveau
sudo certbot certificates | grep Expiry | awk {'print $6 '}
image

J’ai donc tenté de renouveler, avec succès :


Found the following certs:
Certificate Name: xxxxxx.ddns.net
Serial Number: xxxxxxxxx
Key Type: ECDSA
Domains: xxxxxx.ddns.net
Expiry Date: 2025-04-08 08:49:51+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/xxxx.ddns.net/fullchain.pem
Private Key Path: /etc/letsencrypt/live/xxxx.ddns.net/privkey.pem


Etant donné que les problèmes ne se résolvent pas tout seul, MERCI à la bonne âme qui a rétabli le service.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.