Klaus1: Letsencrypt auf SLES 12 SP5 gibt 'module' object has no attribute 'TLSSNI01'

Hallo,

ich würde gerne auf einem SUSE SLES 12 SP5 unsere Zertifikate über Letsencrypt automatisch erneuern.

Certbot und certbot-apache sind installiert. (certbot Version 0.36.0)

Wenn ich certbot --apache starte, erhalte ich die Liste der wählbaren Domains, aber egal welche ich auswähle, ich bekomme die unsten stehende Fehlermeldung.

Der Server ist ein Reverse-Proxy-Server für einen dahinter stehenden NGINX-Server. Letsencrypt sieht das wohl, denn im /var/log/letsencrypt/letsencrypt.log steht wohl daher: Server: nginx?

Was kann ich tun, damit ich über Letsencrypt die Zertifikate erneuern kann?

LG Klaus

An unexpected error occurred:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.36.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3.4/site-packages/certbot/main.py", line 1381, in main
    return config.func(config, plugins)
  File "/usr/lib/python3.4/site-packages/certbot/main.py", line 1132, in run
    certname, lineage)
  File "/usr/lib/python3.4/site-packages/certbot/main.py", line 120, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python3.4/site-packages/certbot/client.py", line 406, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python3.4/site-packages/certbot/client.py", line 349, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python3.4/site-packages/certbot/client.py", line 385, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python3.4/site-packages/certbot/auth_handler.py", line 61, in handle_authorizations
    achalls = self._choose_challenges(authzrs)
  File "/usr/lib/python3.4/site-packages/certbot/auth_handler.py", line 185, in _choose_challenges
    if any(isinstance(achall.chall, challenges.TLSSNI01) for achall in achalls):
  File "/usr/lib/python3.4/site-packages/certbot/auth_handler.py", line 185, in <genexpr>
    if any(isinstance(achall.chall, challenges.TLSSNI01) for achall in achalls):
AttributeError: 'module' object has no attribute 'TLSSNI01'
Quelltext hier
  1. Certbot und certbot-apache sind installiert. (certbot Version 0.36.0)

    Wie hast Du das genau getan? Beide via yast? python3-certbot-apache via pip3?

    1. Hallo,

      ich muss zugeben, dass ich da ein wenig "tricksen" musste. Ich habe alles über zypper installiert, aber zwei weitere Repos hinzugefügt:

      1. http://download.opensuse.org/repositories/devel:/languages:/python:/certbot/SLE_12_SP4/

      2. https://download.opensuse.org/repositories/home:/bjoern_beutel:/Aareon/SLE_12_SP5/

      Mit Pip hatte ich bisher noch nie etwas zu tun. 😟

      LG Klaus

      1. ich muss zugeben, dass ich da ein wenig "tricksen" musste.

        Hast Du noch andere „Tricks“ angewandt? z.B. Das Ignorieren von Problemen bei der Auflösung der Abhängigkeiten?

        Ich habe hier auch keinen SLE12.5 …

        Aber da EINERSEITS die offizielle Dokumentation von Certbot eine Installation auf SuSE12 gar nicht anbietet ANDERERSEITS die Installation via snapd für „Leap“ (OpenSuSE 15) und „Tumbleweed“ angeboten wird (für andere Systeme hingegen die direkte Installation) würde ich mal vermuten, dass die Installation via snapd auch auf Suse 12.5 funktioniert:

        https://certbot.eff.org/instructions?ws=apache&os=leap

        Ich mag snapd auch nicht, aber da es sich um ein System handelt, an dem ich nicht ich sitze, und weil ich die Abhängigkeiten nicht überprüfen kann ist das hier mein Favorit. Beachte die genaue Einhaltung der Schritte, insbesondere die Deinstallation.

        1. Willst Du wildcardzertifikate einrichten?

          Dann beachte, dass es auf https://certbot.eff.org/instructions?ws=apache&os=leap eine Auswahl dafür gibt. Den DNS-Test musst Du dann mit machen.

          Und klar: Der Webserver muss während des Bezugs der Zertifikate und beim Update natürlich aus dem internet erreichbar sein.

          Dann fällt mir noch folgendes ein: Dein Apache ist ja ein Proxy.

          Dann könnten Dir die Ausführungen hier sehr helfen:

          https://bendellar.com/apache-as-reverse-proxy-for-letsencrypt-free-https-certificates/

          insbesondere das

          ProxyPass /.well-known !
          

          bei der Konfiguration des(der) (v)Hosts sollte Deine Beachtung finden.

          sollte Dein Interesse finden und der certbot muss diese datei auch anlegen und beschreiben können.

  2. Tach!

    Der Server ist ein Reverse-Proxy-Server für einen dahinter stehenden NGINX-Server.

    Let's Encrypt arbeitet so, dass es den Besitz der Domain überprüfen möchte. Bei Nicht-Wildcard-Zertifikaten will es dazu nur eine Datei in .well-known lesen. Der Request muss vom Webserver beantwortet werden. Üblicherweise passiert das, indem die Zertifikatsverwaltung diese Datei anlegt und der Webserver den Request mit dieser Datei beantwortet. Das .well-known muss von allen Rewrite- und sonstigen Umschreibmaßnahmen berücksichtigt werden. Wenn bei dir der Apache nur ein Proxy ist, dann muss der Nginx den Request beantworten. Oder der Apache muss so konfiguriert sein, dass er den Request selbst beantwortet, wenn das .well-known in seinem Verantwortungsbereich angelegt wurde. Oft ist es ja so, dass der Proxy das Domain-Handling und auch die Verschlüsslung übernimmt und der dahinterliegende Server ziemlich einfach gebaut ist. Deshalb wird es wohl so sein, dass du dem Apachen beibringen musst, die .well-known-Anfragen zu beantworten, und der Zertifikatsverwaltung, dass sie in dieses dem Apachen bekannten Verzeichnis schreibt.

    dedlfix.

    1. Hi,

      sollte dann nicht ein etwas sprechendere Fehlermeldung ausgegeben werden (so etwas wie: Failed authorization procedure, the client lacks sufficient authorization, invalid response from http://mysite.com/.well-known/acme-challenge ?

      Auf letsdebug.net bekomme ich für die Standard-Challange HTTP-01 die Meldung, dass alles OK ist und keine Probleme gefunden wurden.

      Ich vermute im Moment, dass die Installation von certbot, insbesondere von certbot-apache nicht sauber ist.

      LG Klaus

      1. Tach!

        sollte dann nicht ein etwas sprechendere Fehlermeldung ausgegeben werden (so etwas wie: Failed authorization procedure, the client lacks sufficient authorization, invalid response from http://mysite.com/.well-known/acme-challenge ?

        Das wäre ideal, aber nicht immer gelingt es den Entwicklern, aussagekräftige Fehlermeldungen zu formulieren. Die von dir gezeigte Fehlermeldung ist so unspezifisch, dass als Ursache alles mögliche infrage kommen kann. Wenn du nicht im Quelltext nachlesen möchtest, was zu dieser Meldung führen kann, und auch keine sachdienlichen Hinweise im Internet findest, dann bleibt meist nur, die Installation so aufzusetzen, dass das Programm fehlerfrei laufen kann. Dazu gehört neben der Installation auch, dass die Bedingungen zur Laufzeit passen. Deswegen schrieb ich dir, was da zu beachten ist. Den Certbot selbst und Installationsprozeduren auf SLES kenne ich nicht und kann dir an der Stelle nichts weiter sagen.

        dedlfix.