Probleme mit letsencrypt

Hi Leute,

ich habe seit neustem Probleme mit Letsencrypt. Ich benutze das Nextcloudpi Image und eigentlich hat bisher alles funktioniert. Leider bekomme ich aber seit neustem kein neues SSL Zertifikat. Im Log steht nur folgendes:

[ letsencrypt ]
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for philsnextcloud.ddns.net
Using the webroot path /var/www/nextcloud for all unmatched domains.
Waiting for verification

Cleaning up challenges
Failed authorization procedure. philsnextcloud.ddns.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://philsnextcloud.ddns.net/.well-known/acme-challenge/y0Yw5GLk15ez-NwK5zeL3PiqXY_zl8tusaIax2GlG5U [91.66.9.52]: “\n\n404 Not Found\n\n

Not Found

\n<p”
IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: philsnextcloud.ddns.net
Type: unauthorized
Detail: Invalid response from
http://philsnextcloud.ddns.net/.well-known/acme-challenge/y0Yw5GLk15ez-NwK5zeL3PiqXY_zl8tusaIax2GlG5U
[91.66.9.52]: “\n\n404 Not
Found\n\n

Not Found

\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.

Meine config der Letsencrypt fĂŒr renewal sieht wie folgt aus:

renew_before_expiry = 30 days

version = 0.31.0
archive_dir = /etc/letsencrypt/archive/philsnextcloud.ddns.net
cert = /etc/letsencrypt/live/philsnextcloud.ddns.net/cert.pem
privkey = /etc/letsencrypt/live/philsnextcloud.ddns.net/privkey.pem
chain = /etc/letsencrypt/live/philsnextcloud.ddns.net/chain.pem
fullchain = /etc/letsencrypt/live/philsnextcloud.ddns.net/fullchain.pem

Options used in the renewal process

[renewalparams]
account = f56697e660f97bbd591d5d07a174b501
authenticator = webroot
webroot_path = /var/www/nextcloud
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]
#philsnextcloud.ddns.net = /var/www/nextcloud

Über die Konsole kommt auch nur eine Fehlermeldung. Bei No-IP ist mein Server noch online. Sprich er hat die aktuelle IP. Ich hoffe mir kann hier jemand weiterhelfen.

Falls ihr weitere Infos und Einstellung braucht, gebt bescheid.

Sind deine DNS records richtig gesetzt? Daran scheitert es nĂ€mlich laut Fehlermeldung. No-IP mĂŒsste txt records unterstĂŒtzen, am besten mal direkt danach suchen.

Sollte so Àhnlich funktionieren:

Stelle sicher, dass ein Zugriff auf die URL http://philsnextcloud.ddns.net/.well-known/acme-challenge/ ohne Authentifizierung von extern möglich ist. GemĂ€ĂŸ der Fehlermeldung ist ein Zugriff aktuell nicht möglich.

Das AuswahlmenĂŒ ist bei mir nicht sichtbar, da ich nur die free version verwende.

WIe stelle ich das denn sicher? Beim Aufrufen der Webseite kommt nur eine Fehlermeldung.

Bei https://philsnextcloud.ddns.net (SSL) erreicht man deine Nextcloud.
Bei http://philsnextcloud.ddns.net (kein SSL) eine Apache2-Testseite

Ich kenn mich mit Lets Encrypt wenig aus. Aber die Pfade sind verschieden und vielleicht gibt es Probleme mit dem Ordner .well-known/acme-challenge und der enthaltenen Datei.

Leite doch einfach HTTP immer zu HTTPS um.

In / (von Debian-Test-Webserver (evtl. /var/www/html) keinesfalls Nextcloud-Verzeichnis)

Datei .htaccess.


https://www.xolphin.de/support/Apache_FAQ/Apache_-_Konfigurieren_von_HTTPS_fĂŒr_die_komplette_Website

Nach der Umleitung (teste mit http://) könnte die Aktualisierung funktionieren. Dann brauchst du auch nicht mehr das dÀmliche https:// immer eingeben :wink: Kann man das nicht bei der Installation von Lets Encrypt direkt aktivieren?

HĂ€, wie hast du meine Nextcloud ohne https erreicht? redirect ist eingerichtet und funktioniert doch auch. Wenn ich nur http eingeben ruft er automatisch https auf bzw zeigt momentan nur an, dass das Zertifikat abgelaufen ist.

Mit http:// habe ich eine Debian-Testseite erreicht.
Mit https:// habe ich deine Nextcloud erreicht (Zertifikat ist abgelaufen).

Testet du von innen oder außen?

Anmerkung: Mein Link war falsch. Habe ich oben korrigiert.

ja, vom Wlan. Ich teste mal eben ĂŒber das mobile Netz.

Also bei mir funktioniert der Redirect nicht. Die Ausgabe ist unterschiedlich. Und das ist wahrscheinlich fĂŒr Lets Encrypt ein Problem fĂŒr den Aufruf der benötigten URL als http://

Du hast recht. Sehr merkwĂŒrdig. Vorher hat das alles funktioniert.
Ich befĂŒrchte ja das hat irgendwas mit dem letzten Update auf 18.0.2 zu tun.

Lege mal fĂŒr deinen Debian-HTTP-Bereich (wahrscheinlich /var/www/html/ wo auch die index.html-Testseite rumliegt) eine Datei .htaccess an:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

Hab ich gemacht und apache neu gestartet.
Ich könnte mir noch vorstellen, dass es an meiner 000-default-site liegt von apache. Hatte da etwas rumgespielt, weil ich mal nextcloud auf nen anderen Port ausfĂŒhren wollte damit pi-hole auf port 80 laufen kann. Hab es dann aber wieder gelöscht. Wie sollte die 000-default-sites aussehen?
Wieso ich mir das vorstellen kann? Ich hab in einem anderen Thread gelesen das letsencrypt Port 80 benötigt und dafĂŒr wohl ein virtual host gebraucht wird.

Hast du Rewrite aktiviert?

a2enmod rewrite

Apache2 erneut neu starten.

1 Like

Was ist rewrite?

Edit: War bereits aktiviert.

Die Umleitung. Wobei eigentlich muss sie schon alleine fĂŒr Nextcloud aktiviert sein. Sorry.

Hast du wirklich .htaccess in /var/www/html angelegt und liegt dort wirklich die index.html mit der Testseite? Poste evtl.

ls -l /var/www/html (also dein document-root fĂŒr deinen default-000-webserver)

Vielleicht noch soviel. Im Ordner /etc/apache2/sites-enabled gibt es zwei Dateien. Die eine fĂŒr deine Nextcloud und in der anderen die Default-Konfiguration. Dort steht der Pfad wahrscheinlich nach /var/www/html und in den Ordner gehört die genannte .htaccess

/var/www/html $ ls -al
insgesamt 24
drwxrwxr-x 2 www-data www-data 4096 MĂ€r 25 16:34 .
drwxr-xr-x 7 root root 4096 MĂ€r 25 15:45 

-rw-r–r-- 1 root root 141 MĂ€r 25 16:34 .htaccess
-rw-r–r-- 1 root root 10701 Jul 21 2019 index.html

naja und genau da liegt zur zeit glaube ich der fehler bei mir. ich habe an der default datei rumgespielt. momentan habe ich dort ĂŒberhaupt keine default datei.
sie sah aber so aus:

 #=== pihole WEBSITE ===
 
 <VirtualHost *:80>
         ServerAdmin webmaster@localhost
         ServerName pihole
         ServerAlias pi.hole
 
         DocumentRoot /var/www/html/dns
         <Directory /var/www/html/dns/>
                 Options FollowSymLinks MultiViews
                 AllowOverride all
                 Order deny,allow
                 Require all granted
         </Directory>
 
         ErrorLog ${APACHE_LOG_DIR}/pihole_error.log
         LogLevel warn
         CustomLog ${APACHE_LOG_DIR}/pihole_access.log combined
 </VirtualHost>
 
 #=== default WEBSITE ===
 
 <VirtualHost _default_:80>
   DocumentRoot /var/www
   <IfModule mod_rewrite.c>
     RewriteEngine On
     RewriteCond %{HTTPS} !=on
     RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
   </IfModule>
</VirtualHost>

Ich kopiere sie mal wieder in den ordner und teste nochmal

Vielleicht muss www-data sie gehören:
chown www-data:www-data /var/www/html/.htaccess
Setze auch die Rechte:
chmod 755 /var/www/html/.htaccess

Ich sehe gerade deinen Pi-Hole-Eintrag. Wird der vielleicht gezogen.
Poste:
ls -l /var/www/html/dns

Steht das Zeug wirklich in der Datei unterhalb von “#=== default WEBSITE ===”
DocumentRoot /var/www RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]