lets encrypt renew

lordg2009 · 28. Mai 2018

Hi,

ich habe vor knapp 3 Monaten mein erstes lets encrypt Zertifikat erstellt, um den collabora office server mit einem Zertifikat zu versehen. Ich benutze nextcloud auf debian 9 mit apache2 und certbot. auf noip habe ich eine dyndns und eine subdomain für collabora. In apache2 gibt es einen virtual host der auf port 80 horcht und mit rewrite an ssl weiterleitet und einen virtual host auf port 443 der anfragen mittels reverse proxy zu meinem docker container auf port 9980 umleitet.

Bis jetzt klappt alles wunderbar, aber es ist an der Zeit, das Zertifikat zu erneuern. Leider wirft der Befehl certbot renew folgenden Fehler aus:

Code:

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/office.myDomain.org.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for office.myDomain.org
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (office.myDomain.org) from /etc/letsencrypt/renewal/office.myDomain.org.conf produced an unexpected error: Failed authorization procedure. office.myDomain.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://office.myDomain.org/.well-known/acme-challenge/'HIER_MEINE_CHALLENGE': "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p". Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/office.myDomain.org/fullchain.pem (failure)

-------------------------------------------------------------------------------

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/office.myDomain.org/fullchain.pem (failure)
-------------------------------------------------------------------------------
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
- The following errors were reported by the server:

   Domain: office.myDomain.org
   Type:   unauthorized
   Detail: Invalid response from
   http://office.myDomain.org/.well-known/acme-challenge/'HIER_MEINE_CHALLENGE':
   "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
   <html><head>
   <title>404 Not Found</title>
   </head><body>
   <h1>Not Found</h1>
   <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.

Hat jemand ne Idee, was zu tun ist?

Nero FX · 28. Mai 2018

Das System arbeitet ja mit einer automatisch erstellen Verifzierungsseite.

1. ist "office.myDomain.org" wirklich deinen Adresse bzw. hast du das absichtlich ersetzt? Sonst ist der Certbot falsch eingestellt und versucht für eine unbekannte Seite eine Zertifikat zu erstellen

2. Der CertBot legt ein Verifizierungsseite an
http://office.myDomain.org/.well-known/acme-challenge/'HIER_MEINE_CHALLENGE':
"<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

Diese wird dann vom Let's Encrypt Server aufgerufen und erwartet dann ein "Geheimnis" so wird sichergestellt das der Zertifikatsanforderer auch (noch) Domainbesitzer ist.

Bei dir funktioniert das nicht, die Verifizierungsseite ist nicht erreichbar/vorhanden (Fehler 404),

lordg2009 · 28. Mai 2018

myDomain und die challenge habe ich unkenntlich gemacht. Normalerweise steht dort der originale Eintrag. Warum kann certbot bei mir diese Verifizierungsseite nicht erstellen?

BFF · 28. Mai 2018

Hi,

Such mal per Suchmaschine nach :
"letsencrypt certbot 404 renew"

BFF

Zerstoerer · 28. Mai 2018

Mal mit "sudo" versucht?

LinuXfr3ak · 28. Mai 2018

In der /etc/letsencrypt/renewal/office.myDomain.org.conf webroot path richtig gesetzt (muss auf root Verzeichnis deines Webservers bzw vhosts zeigen falls nicht im Webserver anders konfiguriert)

Zum testen einfach das Verzeichnis anzulegen, testfile reinlegen und versuchen übern Browser aufzurufen (http://office.myDomain.org/.well-known/acme-challenge/testfile) - wenn kein 404 zurückkommt passts. Dann nochmal mit cert renew versuchen (Letsencrypt sperrt die Domain für ein paar Stunden - 1Tag bei zu vielen fehlschlägen)

maloz · 28. Mai 2018

Verstehe ich das richtig: Du rufst von extern nextcloud.domain.com (dyndns) auf (Port 80) und bei dir erfolgt dann der Redirect auf 443?
D.h. in deinem Router gibt es ein Port Forwarding von Port 80 auf apache, der macht dann 443 auf deinen Reverse Proxy welcher wiederum auf deinen „custom“ High Port weiterreicht.

Das Konstrukt hat so bei der initialen, automatisierten Zertifikatserstellung (letsencrypt-auto) funktioniert?

Ich muss immer mein Port forwarding auf 443 (von extern kommend) ändern und dann die Zertifikatserneuerung durchlaufen lassen, das klappt auf Anhieb und anschließend stelle ich den Port wieder zurück.

riff-raff · 29. Mai 2018

Ich schleife Port 443 für Nextcloud direkt und Port 80 für den Certbot durch, da geht auch der Renewal automatisch.

lordg2009 · 12. Juni 2018

Ist schon eine Weile her, aber ich habe das Problem lösen können.

Im Router wird port 80 und 443 unverändert weitergegeben. Auf meinem Server nutze ich die von certbot angebotene Funktion mir eine redirect Regel zu schreiben, um traffic auf https umzuleiten. Die nextcloud Instanz funktioniert auch ohne Probleme. Das Problem ist die collabora Instanz die in einem docker container läuft. Collabora benutze ich, um office dokumente in der Cloud darzustellen. In der apache2 Konfiguration von collabora nutze ich das reverseProxy modul, um traffic auf port 443 an die subdomain office.MEIN_NEXTCLOUD.de an den docker container an 127.0.0.1:9980 weiterzuleiten.

Es gibt also kein lokales webroot verzeichnis, an das im docker container komme ich nicht ran.

Folgende Lösung funktioniert für mich unter debian, falls jemand das gleiche Problem haben sollte:

zusätzliches webroot verzeichnis für collabora anlegen, z.B. /var/www/office.MEIN_NEXTCLOUD.de
eigentliche vhost Konfiguration zu collabora deaktivieren
Code:
```
a2dissite collabora-le-ssl.conf
```

simple apache vhost config auf dieses Verzeichnis anlegen collabora-le-renew.conf

XML:

<VirtualHost *:80>    
    ServerName office.MEIN_NEXTCLOUD.org
   
    DocumentRoot /var/www/office.MEIN_NEXTCLOUD.org
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /var/www/office.MEIN_NEXTCLOUD.org>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>
</VirtualHost>

als root ein zertifikat anfordern

Bash:

certbot --authenticator webroot --installer apache

ich habe eine redirect regel anlegen lassen, braucht man aber wahrscheinlich nicht, damit habe ich jetzt zwei neue vhost configs collabora-le-renew.conf und collabora-le-renew-le-ssl.conf
die drei neuen Zeilen zur Angabe des Zertifikates in der collabora-le-renew-le-ssl.conf müssen einmalig in die vhost-Konfiguration der eigentlichen collabora instanz mit reverseproxy zum docker container eingetragen werden
XML:
```
SSLCertificateFile /etc/letsencrypt/live/office.MEIN_NEXTCLOUD.org/fullchain.pemSSLCertificateKeyFile /etc/letsencrypt/live/office.MEIN_NEXTCLOUD.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
```
jetzt können die beiden renew vhosts deaktiviert werden und die eigentlich collabora konfiguration aktiviert werden
Bei jedem automatischen renew müssen dann erst die eigentliche Konfiguration deaktiviert, die beiden renew Konfigurationen aktiviert, das Zertifikat erneuert werden und die Änderungen in der Apache Konfiguration wieder rückgängig gemacht werden. Dazu habe ich mir folgendes Script angelegt und es le_renew.sh genannt:

Bash:

#!/bin/bash

# apache2 VHostConf für docker deaktivieren
a2dissite collabora-le-ssl.conf

# abache VHostConf für lokales verzeichnis aktivieren (mit redirect)
a2ensite collabora-le-renew-le-ssl.conf
a2ensite collabora-le-renew-redirect.conf

# Änderungen in apache2 laden
systemctl reload apache2.service

# Zertifikate erneuern
certbot renew -q

# apache2 VHostConf für docker wieder aktivieren
a2ensite collabora-le-ssl.conf

# abache VHostConf für lokales verzeichnis wieder deaktivieren (mit redirect)
a2dissite collabora-le-renew-le-ssl.conf
a2dissite collabora-le-renew-redirect.conf

# Änderungen noch mal in apache2 laden
systemctl reload apache2.service

jetzt noch einen Cronjob, der das ganze einmal täglich durchführt, Ausgabe nach /dev/null, damit nur Fehlermeldungen durchkommen

Bash:

# nextcloud lets encrypt zertifikate erneuern
@daily    root    /usr/local/sbin/le_renew.sh > /dev/null

Suche

lets encrypt renew

lordg2009

Lt. Commander

Nero FX

Commander

lordg2009

Lt. Commander

BFF

¯\_(ツ)_/¯

Zerstoerer

Lieutenant

LinuXfr3ak

Lt. Junior Grade

maloz

Captain

riff-raff

Captain

lordg2009

Lt. Commander

Ähnliche Themen