Let's Encyrpt Zertifikat lässt sich nicht erneuern

Hallo,

mein lets encrypt Zertifikat lässt sich nicht erneuern. Ich habe die nextcloud auf einem raspberry pi installiert und versuche, das Zertifikat über die nextcloudpi Oberfläche zu erneuern. Leider gelingt mir das nicht. Ich bekomme auch eine Fehlermeldung in der letsencrypt log Datei:


2021-09-28 04:50:29,957:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: mydns
Type:   unauthorized
Detail: Invalid response from http://mydns/.well-known/acme-challenge/xxxxxxx [79.215.178.20]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
2021-09-28 04:50:29,958:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 82, in handle_authorizations
    self._respond(aauthzrs, resp, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 168, in _respond
    self._poll_challenges(aauthzrs, chall_update, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 239, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. mydns (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mydns/.well-known/acme-challenge/xxxxxxxx [79.215.178.20]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

2021-09-28 04:50:29,958:DEBUG:certbot.error_handler:Calling registered functions
2021-09-28 04:50:29,959:INFO:certbot.auth_handler:Cleaning up challenges
2021-09-28 04:50:29,959:DEBUG:certbot.plugins.webroot:Removing /var/www/nextcloud/.well-known/acme-challenge/xxxxxxxxxxxx
2021-09-28 04:50:29,960:DEBUG:certbot.plugins.webroot:All challenges cleaned up
2021-09-28 04:50:29,960:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/letsencrypt", line 11, in <module>
    load_entry_point('certbot==0.31.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1365, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1250, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 116, in _get_and_save_cert
    renewal.renew_cert(config, domains, le_client, lineage)
  File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 323, in renew_cert
    new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 353, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 389, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 82, in handle_authorizations
    self._respond(aauthzrs, resp, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 168, in _respond
    self._poll_challenges(aauthzrs, chall_update, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 239, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. mydns (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mydns/.well-known/acme-challenge/xxxxxxxxxxx [79.215.178.20]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

Kann hier jemand helfen?

1 Like

Wir könnten eventuell. Wenn wir mehr von deinen System wüsten :wink:

Du schreibst von einer Installation auf einen PI. Nur wissen wir nicht ob dieser PI hinter einen Router steckt oder sonnst wo.
Wir wissen auch nicht ob du zugriff auf deinen PI hast z.b über SSH… Oder inwieweit deine Kenntnisse reichen.

Hallo,mein Pi sitzt hinter einer Fritzbox. Die Box leitet die Ports 80 und443 an 808 und 4433 weiter.

Mein System erreiche ich über SSH. Viele Grüße.

Hat dein PI eine Feste IP bekommen?
Und sollte das nicht port 4443 sein? :wink:

Ja,der hat eine feste Adresse, die192.168.178.19.

Unter Port 4433 ist die nextcloud erreichbar, aber unter port 4443 ist nextcloudpi erreichbar

Kann keiner helfen? Ich bin mit meinem Latein am Ende.

Schau mal auf https://strobelstefan.org/2018/06/15/lets-encrypt-zertifikaterneuerung-schlaegt-fehlt/

Hallo Nanu,

eine letsentcypt-auto Exectuable Datei habe ich nicht im letsencrypt-Ordner :frowning:

Du braucht nicht nur eine Feste INTERNE IP sondern auch eine Feste Externe bzw. Domain. Woher soll denn let’s encrypt wissen ob deine jetzige IP die nächsten 90 Tage erreichbar ist? Anders bekommst du kein Zertifikat von let’s encrypt.

Hier steht warum und wie man selber eines erstellen kann.
https://letsencrypt.org/de/docs/certificates-for-localhost/

https://youtu.be/0ZhKv-DTnwQ

warum?

lass doch die NC an den Standardports hängen… 80 und 443 - (4443 ist nur für die NCP-WebGUI gedacht)

Welche conf files muß ich editieren, damit ich 80 und 443 nutze?

das legt der Installationsassistent von NCP automatisch so an (ist Standard). In deiner Fritzbox muss die Weiterleitung dann Port-echt sein… also 80–> 80 und 443 → 443

Hallo, wie rufe ich denn den Installationsassistenten auf? Ich habe ja bereits eine Instanz, mit der will ich weiter arbeiten…

Hallo, kann keiner helfen, wie ich die Ports von 4433 auf 443 und 808 auf 80 bekomme?

Die Antwort hast du selber geschrieben :wink:

Also mußt du das wieder auf deiner Fritzbox Rückgäng machen.

Geh auf der Fritzbox und schau unter Internet—>Freigaben dort muß dementsprechend eine Freigabe bzw. eine Umleitung der Ports angegeben worden sein. Die entsprechende Regel die dort angegeben worden ist kannst du mit den Roten X Löschen und bestätigen.

Aber nur wenn du innerhalb deines Heim Netzwerks den webserver über port 80 erreichen kannst.
Es gibt im Apache eine configurationsdatei manchmal heist sie httpd.conf oder falls du apache 2 drauf hast kannst du sie ja über a2query -s dann siehts du die aktivierten sites und bekommst auch gleich den namen der configurationsdatei bei mir z.B /etc/apache2/sites-enabled/name_der_configuarationsdatei.conf
dann schau dir ann was da steht.
Wenn da der Eintrag virtual host *:4433 steht änderst du ihn ab auf 443 die 808 änderst du auf 80
jetzt kontrolliert du noch den Eintrag im nextcloud verzeichnis /config in der config.php da muss im array der trusted hosts auch dein dyndns name stehen so wie du ihn bei letsencrypt angefordert hast.

Das setzt voraus das man erst mal weiss wie man in die config kommt und sie bearbeiten kann.
Dazu kommt noch das man Schreibrechte braucht :wink: Und das geht nur mit sudo su oder bzw root …
Und wenn wer da schon Probleme hat und nicht den Zusammenhang der einzelnen Konfigurationsdateien versteht ist für einer nicht gehosteten Cloudlösung ungeeignet.

Für den Privaten gebrauch innerhalb eines Netzwerkes empfehle ich einfach Fertige Cloudlösungen bzw. NAS zu Kaufen. Kommt immer darauf an was man vorhat :wink:

sudo macht auch root mit minus i
Nee ernsthaft hier ist jemand der spass daran hat etwas auszuprobieren ich finde es sinnvoll ihm ein wenig unterstützung zu geben.

Klar. Bin ich voll dafür! Dafür ist ja eine Community. Doch man sollte auch nicht vergessen das das alles ein gewissen Sicherheitsfaktor mit sich bringt.
Wenn ich meine Privaten Bilder ,Videos usw. In der ganzen Welt rausposaune brauch nicht nach mehr Datenschutz plärren :wink:
Und eine Eigene Cloud die man dann von aussen erreichen will muss genauso bombensicher sein wie bei jeden Anbieter. Das setzt eine gewissen Wissenstand stand voraus.
Innerhalb von Netzwerk kann man schon mal die “Sau” rauslassen :slight_smile:

Hallo, danke erstmal für die vielen Kommentare. Vielleicht kurz zu meinem Hintergrundwissen: ich habe E-Technik studiert, also ein bisschen was weiss ich schon, aber beschäftige mich mit den Dingen nicht ständig.

Es gibt im Apache eine configurationsdatei manchmal heist sie httpd.conf oder falls du apache 2 drauf hast kannst du sie ja über a2query -s dann siehts du die aktivierten sites und bekommst auch gleich den namen der configurationsdatei bei mir z.B /etc/apache2/sites-enabled/name_der_configuarationsdatei.conf

root@raspberrypi-iob:/etc/apache2# a2query -s
nextcloud (enabled by site administrator)
ncp (enabled by site administrator)

Hier taucht erstmal keine Konfigurationsdatei auf, macht aber nichts. Ich gehe also hier hin:

root@raspberrypi-iob:/etc/apache2/sites-available# pwd
/etc/apache2/sites-available
root@raspberrypi-iob:/etc/apache2/sites-available# cat nextcloud.conf
### DO NOT EDIT! THIS FILE HAS BEEN AUTOMATICALLY GENERATED. CHANGES WILL BE OVERWRITTEN ###

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    DocumentRoot /var/www/nextcloud
    ServerName dyndns
    CustomLog /var/log/apache2/nc-access.log combined
    ErrorLog  /var/log/apache2/nc-error.log
    SSLEngine on
    SSLProxyEngine on
    SSLCertificateFile      /etc/letsencrypt/live/dyndns/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/dyndns/privkey.pem

    # For notify_push app in NC21
    ProxyPass /push/ws ws://127.0.0.1:7867/ws
    ProxyPass /push/ http://127.0.0.1:7867/
    ProxyPassReverse /push/ http://127.0.0.1:7867/
  </VirtualHost>

  <Directory /var/www/nextcloud/>
    Options +FollowSymlinks
    AllowOverride All
    <IfModule mod_dav.c>
      Dav off
    </IfModule>
    LimitRequestBody 0
    SSLRenegBufferSize 10486000
  </Directory>
  <IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"
  </IfModule>
</IfModule>

Hier fällt auf, dass ich keinen Port 80 konfiguriert habe / konfigurieren kann, so wie du schreibst. Weiterhin fällt in der ersten Zeile auf, dass die Datei wieder überschrieben wird - wahrscheinlich bei einem Upgrade.

Dann noch der Inhalt der config.php:


root@raspberrypi-iob:/var/www/nextcloud/config# cat config.php
<?php
$CONFIG = array (
  'passwordsalt' => 'xxx',
  'secret' => 'xxx',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'example.com',
    3 => 'dyndns',
    4 => 'nextcloudpi.local',
    5 => 'nextcloudpi',
    6 => 'nextcloudpi.lan',
  ),
  'datadirectory' => '/var/www/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '21.0.4.1',
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => 'https://dyndns/',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'ncadmin',
  'dbpassword' => 'xxx',
  'installed' => true,
  'instanceid' => 'ocerw4in4l88',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
    'password' => 'xxx',
  ),
  'tempdirectory' => '/var/www/nextcloud/data/tmp',
  'mail_smtpmode' => 'smtp',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_from_address' => 'mail',
  'mail_domain' => 'maildomain',
  'loglevel' => '2',
  'log_type' => 'file',
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' =>
  array (
  ),
  'twofactor_enforced_excluded_groups' =>
  array (
  ),
  'allow_local_remote_servers' => true,
  'maintenance' => false,
  'htaccess.RewriteBase' => '/',
  'mail_sendmailmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_smtpauth' => 1,
  'mail_smtphost' => example.com',
  'mail_smtpport' => '465',
  'mail_smtpname' => 'xxx.de',
  'mail_smtppassword' => 'xxx',
  'trusted_proxies' =>
  array (
    11 => '127.0.0.1',
    12 => '::1',
    13 => 'dyndns',
    14 => 'example.com',
  ),
);

Hier ist meine dyndns sauber eingetragen. Die Ports in der Fritzbox habe ich mit TCP Protokoll von 80 auf 80 bis 80 und 443 auf 443 bis 443 weiterleiten lassen.

Ergebnis: kein Zugriff mehr auf die nextcloud :frowning: