Problem bei certs_dehydrated Zertifikat Update?

[Detlef Paschke]

Hallo,

heute Nacht sollte ein Zertifikat Update von certs_dehydrated
durchgeführt werden, schief gelaufen ist, da, wie ich finden konnte,
alle Zugriffe auf /.well-known/acme-challenge in HTTP-Code 403 enden.

error_log
[Sun Feb 05 10:09:50.382965 2023] [rewrite:error] [pid 25666:tid
140118862059072] [client 91.45.54.62:50204] AH00670: Options
FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule
directive is also forbidden due to its similar ability to circumvent
directory restrictions : /var/www/htdocs/certs_dehydrated

Port 80 und 443 sind bei mir dauerhaft offen.

Die letzten Zertifikat Updates (das letzte am 04.12.2022) liefen
Problemlos und Fehlerfrei. In der Zwischenzeit habe ich auf jeden Fall
Apache2 upgedatet und ob eine .htaccess im APACHE2_DOCUMENT_ROOT auch in
dieser Zeit hinzukam weiß ich nicht genau.

Erwähnung der .htaccess aus diesem Grund.
Ich habe beobachtet, dass ein Zugriff auf /.well-known/acme-challenge
problemlos möglich ist, wenn im APACHE2_DOCUMENT_ROOT keine oder eine
.htaccess mit "RewriteEngine off" abgelegt ist. Der weitere Inhalt der
.htaccess spielt keine Rolle, selbst wenn alles auskommentiert wurde,
endet ein Zugriff auf /.well-known/acme-challenge bei Fehler 403, wenn
"RewriteEngine on" angegeben ist. Die Einträge "Options +FollowSymlinks"
oder "Options +SymLinksIfOwnerMatch" in der .htaccess haben keinen
Einfluss und ändern nichts.

Als Zwischenlösung habe ich in
/etc/apache2/mods-enabled/certs_dehydrated.conf die Zeile "Options None"
auskommentiert und damit greift das Standardmäßige "Options
FollowSymLinks" in Apache2.
Aber beim nächsten Paket-Update von certs_dehydrated ist das wieder weg
und das war zuvor nicht nötig. Und die Einträge in
/etc/apache2/mods-enabled/certs_dehydrated.conf entsprechen dem, was
überall zu finden ist.
Was ist denn hier auf einmal anders?

Das letzte Update von certs_dehydrated kann ich nicht mehr nachvollziehen.
Das letzte Apache2 Update war am 12.01.2023 von 3.2.6 auf 3.2.7.
Ob ich die genannte .htaccess im APACHE2_DOCUMENT_ROOT erst nach dem
letzten Zertifikat Update von certs_dehydrated angelegt habe, weiß ich
nicht mehr. Auf jeden Fall, sollte es ja nicht unmöglich sein, im
APACHE2_DOCUMENT_ROOT eine .htaccess mit "RewriteEngine on" zu hinterlegen.

Viele Grüße
Detlef Paschke

--
Das "Zitat des Augenblick" gibt es nur auf:
https://schabau.eu

Meine "Merkzettel" findet man unter:
https://helpdesk.schabau.eu

[Juergen Edner]

Hallo Detlef,

> heute Nacht sollte ein Zertifikat Update von certs_dehydrated
> durchgeführt werden, schief gelaufen ist, da, wie ich finden konnte,
> alle Zugriffe auf /.well-known/acme-challenge in HTTP-Code 403 enden.
>
> error_log
> [Sun Feb 05 10:09:50.382965 2023] [rewrite:error] [pid 25666:tid
> 140118862059072] [client 91.45.54.62:50204] AH00670: Options
> FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule
> directive is also forbidden due to its similar ability to circumvent
> directory restrictions : /var/www/htdocs/certs_dehydrated
>
> Port 80 und 443 sind bei mir dauerhaft offen.

die Meldung scheint mir eher vom Apache2-Webserver als vom Paket zu
kommen. Vielleicht werden seit dem letzten Update Parameter etwas anders
behandelt.

> Als Zwischenlösung habe ich in
> /etc/apache2/mods-enabled/certs_dehydrated.conf die Zeile "Options None"
> auskommentiert und damit greift das Standardmäßige "Options
> FollowSymLinks" in Apache2.
> Aber beim nächsten Paket-Update von certs_dehydrated ist das wieder weg
> und das war zuvor nicht nötig. Und die Einträge in
> /etc/apache2/mods-enabled/certs_dehydrated.conf entsprechen dem, was
> überall zu finden ist.
> Was ist denn hier auf einmal anders?

Es wäre auch möglich, dass die Apache2-Konfigurationsdateien in einer
anderen Reihenfolge abgearbeitet werden als zuvor, weil Du z.B. eine
andere Konfiguration ergänzt hast, die alphabetisch vorher abgearbeitet
wird. Im certs_dehydrated-Paket gibt es den optionalen Parameter
DEHYDRATED_APACHE2_PREFIX='zz-04' über den man einen Prefix für die
Konfigurationsdatei festlegen kann. Im Beispiel wird der Datei z.B.
'zz-04' vorangestellt, was dafür sorgt, dass die Datei erst ganz am Ende
und dort an vierter Stelle geladen wird.

Gruß Jürgen
--
Mail: jue...@eisfair.org

[Detlef Paschke]

Am 06.02.2023 um 09:59 schrieb Juergen Edner:
> Hallo Detlef,

Hallo Juergen,

>> error_log
>> [Sun Feb 05 10:09:50.382965 2023] [rewrite:error] [pid 25666:tid
>> 140118862059072] [client 91.45.54.62:50204] AH00670: Options
>> FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule
>> directive is also forbidden due to its similar ability to circumvent
>> directory restrictions : /var/www/htdocs/certs_dehydrated
>>
>> Port 80 und 443 sind bei mir dauerhaft offen.
>
> die Meldung scheint mir eher vom Apache2-Webserver als vom Paket zu
> kommen. Vielleicht werden seit dem letzten Update Parameter etwas anders
> behandelt.

in dieser Richtung dachte ich auch, dass letzte Update von
certs_dehydrated ist auch schon länger her, wie ich meine.

>> Als Zwischenlösung habe ich in
>> /etc/apache2/mods-enabled/certs_dehydrated.conf die Zeile "Options None"
>> auskommentiert und damit greift das Standardmäßige "Options
>> FollowSymLinks" in Apache2.
>> Aber beim nächsten Paket-Update von certs_dehydrated ist das wieder weg
>> und das war zuvor nicht nötig. Und die Einträge in
>> /etc/apache2/mods-enabled/certs_dehydrated.conf entsprechen dem, was
>> überall zu finden ist.
>> Was ist denn hier auf einmal anders?
>
> Es wäre auch möglich, dass die Apache2-Konfigurationsdateien in einer
> anderen Reihenfolge abgearbeitet werden als zuvor, weil Du z.B. eine
> andere Konfiguration ergänzt hast, die alphabetisch vorher abgearbeitet
> wird. Im certs_dehydrated-Paket gibt es den optionalen Parameter
> DEHYDRATED_APACHE2_PREFIX='zz-04' über den man einen Prefix für die
> Konfigurationsdatei festlegen kann. Im Beispiel wird der Datei z.B.
> 'zz-04' vorangestellt, was dafür sorgt, dass die Datei erst ganz am Ende
> und dort an vierter Stelle geladen wird.

Das habe ich ausprobiert, dass hat leider keinerlei Veränderung gebracht.

So wie ich zwischenzeitlich in anderen Beiträgen gelesen habe, habe ich
in der /etc/apache2/mods-enabled/certs_dehydrated.conf jetzt diese Zeile
angegeben.

Options FollowSymLinks MultiViews

Damit funktioniert es erst mal aber wie es bei eisfair nun mal leider so
ist, bei jedem Update oder schließen der Konfiguration ist die Zeile
wieder im Ausgangszustand.
Das Zertifikat Update ist erst mal durchgelaufen. Ich hatte zwar kurz
Ärger mit meinem Roundcube VHOST, dass war aber meine Schuld. Den hatte
ich irgend wann dummerweise auf APACHE2_VHOST_N_SSL_FORCE='yes' gestellt.

Ich habe auch die Möglichkeit, auf dns-01 umzusteigen und solchen
Problemen damit aus dem Weg zu gehen. Aber es tut mir Leid, ich verstehe
die Doku an dieser Stelle einfach nicht. Ich sehe zwar den Unterschied
der Challenge-Typen, aber ich bin einfach zu blöd um zu begreifen, wie
ich einen anderen als den Standard http-01 einzurichten habe.

Ich habe von meinem Domainanbieter eine Adresse und einen API-Token für
die DNS-01 Validation. In die Adresse muss neben dem API-Token, die
Domain und der Wert für den neuen TXT-Record. Das hat wenn ich es
richtig verstehe, certs_dehydrated als Umgebungsvariablen zur Verfügung.
(DOMAIN, TOKEN_VALUE)
Dann würde die Adresse so aussehen.

https://my.do.de/api/letsencrypt?token=XXX&domain=_acme-challenge.DOMAIN&value=TOKEN_VALUE

Aber wo muss ich die Zeile nun eintragen? Ich sehe es einfach nicht.

> Gruß Jürgen

[Detlef Paschke]

Am 06.02.2023 um 12:52 schrieb Detlef Paschke:

> Ich habe auch die Möglichkeit, auf dns-01 umzusteigen und solchen
> Problemen damit aus dem Weg zu gehen. Aber es tut mir Leid, ich verstehe
> die Doku an dieser Stelle einfach nicht. Ich sehe zwar den Unterschied
> der Challenge-Typen, aber ich bin einfach zu blöd um zu begreifen, wie
> ich einen anderen als den Standard http-01 einzurichten habe.
>
> Ich habe von meinem Domainanbieter eine Adresse und einen API-Token für
> die DNS-01 Validation. In die Adresse muss neben dem API-Token, die
> Domain und der Wert für den neuen TXT-Record. Das hat wenn ich es
> richtig verstehe, certs_dehydrated als Umgebungsvariablen zur Verfügung.
> (DOMAIN, TOKEN_VALUE)
> Dann würde die Adresse so aussehen.
>
> https://my.do.de/api/letsencrypt?token=XXX&domain=_acme-challenge.DOMAIN&value=TOKEN_VALUE
>
> Aber wo muss ich die Zeile nun eintragen? Ich sehe es einfach nicht.

Ich habe es gefunden und meine immer noch, in der DOKU findet sich
nicht, dass für dns-01 ein eigenes Script an den Anfang der
DEHYDRATED_HOOK muss, welches die Aufrufe zum jeweiligen Anbieter macht.

Ich habe es nun herausbekommen. Ich brauchte bei mir ja auch nicht viel,
im Grunde nur den Aufruf einer Adresse. So dachte ich leichtsinniger
Weise, dass ich jetzt recht leicht von http-01 auf dns-01 umstellen
kann. Mit DEHYDRATED_MODE='test' hat auch alles fehlerfrei funktioniert.
Nun dachte ich, es ist alle gut und ich kann auf DEHYDRATED_MODE='live'
wechseln, bekam dann aber diese Meldung.

Request Let’s Encrypt certificate update

Umgebung : live
Challenge: dns-01

Do you want to force a renewal of the certificate(s) (y/n) [no]? y

# INFO: Using main config file /etc/dehydrated/config
Processing schabau.eu with alternative names: helpdesk.schabau.eu
mail.schabau.eu
+ Checking domain name(s) of existing cert... unchanged.
+ Checking expire date of existing cert...
+ Valid till May 8 15:09:45 2023 GMT (Longer than 30 days). Ignoring
because renew was forced!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 3 authorizations URLs from the CA
+ Handling authorization for schabau.eu
ERROR: Validating this certificate is not possible using dns-01.
Possible validation methods are: http-01
-> Executing hook script 'exit_hook' ...

Press ENTER to continue

Was soll denn jetzt noch nicht stimmen und vor allem in welche Richtung
sollte ich Suchen, wenn der Testdurchlauf absolut fehlerfrei durchläuft?

[Juergen Edner]

Hallo Detlef,

> Ich habe es nun herausbekommen. Ich brauchte bei mir ja auch nicht viel,
> im Grunde nur den Aufruf einer Adresse. So dachte ich leichtsinniger
> Weise, dass ich jetzt recht leicht von http-01 auf dns-01 umstellen
> kann. Mit DEHYDRATED_MODE='test' hat auch alles fehlerfrei funktioniert.
> Nun dachte ich, es ist alle gut und ich kann auf DEHYDRATED_MODE='live'
> wechseln, bekam dann aber diese Meldung.

> ...

> + Handling authorization for schabau.eu
> ERROR: Validating this certificate is not possible using dns-01.
> Possible validation methods are: http-01
> -> Executing hook script 'exit_hook' ...

ich habe leider keine Erfahrung mit der 'dns-01'-Einstellung, jedoch
birgt dieses Prüfungsverfahren nach meinem Verständnis das Risiko, dass
eine DNS-Aktualisierung nicht zeitnah auf alle möglichen DNS-Server
synchronisiert wird. D.h. vermutlich muss eine Wartezeit nach dem
Aktualisieren des DNS-Eintrags eingefügt werden, was bei Verwendung von
'http-01' oder 'tls-alpn-01' verständlicherweise nicht erforderlich ist.

Eventuell findet sich Dein DNS-Provider im Wiki des Projektes:

https://github.com/dehydrated-io/dehydrated/wiki

[Detlef Paschke]

Am 11.02.2023 um 10:14 schrieb Juergen Edner:
> Hallo Detlef,

Hallo Juergen,

>> ...
>> + Handling authorization for schabau.eu
>> ERROR: Validating this certificate is not possible using dns-01.
>> Possible validation methods are: http-01
>> -> Executing hook script 'exit_hook' ...
>
> ich habe leider keine Erfahrung mit der 'dns-01'-Einstellung, jedoch
> birgt dieses Prüfungsverfahren nach meinem Verständnis das Risiko, dass
> eine DNS-Aktualisierung nicht zeitnah auf alle möglichen DNS-Server
> synchronisiert wird. D.h. vermutlich muss eine Wartezeit nach dem
> Aktualisieren des DNS-Eintrags eingefügt werden, was bei Verwendung von
> 'http-01' oder 'tls-alpn-01' verständlicherweise nicht erforderlich ist.

Mit http-01 gibt es (vermutlich seit dem letzten Apache update) nach
jedem Aufruf der Konfiguration Probleme, bevor nicht ein händischer
Eingriff in die /var/www/htdocs/certs_dehydrated erfolgt und so war für
mich eine Alternative angezeigt.

Bei tls-alpn-01 ist es ähnlich wie bei dns-01, im Grunde ist es nicht
beschrieben. Es muss wohl irgend ein Server irgendwo sein. Aber wie, wo
und was Konfiguriert wird...? Ebenso wie bei dns-01, wird wohl ein
einfaches DEHYDRATED_CHALLENGE_TYPE='tls-alpn-01' nicht ausreichend
sein. Den DNS TXT-Record kenne ich, so hatte dns-01 für mich Vorrang.

Eine Wartezeit habe ich angegeben, nach eigenen Tests, ist bei meinem
Anbieter aber fast keine Wartezeit nötig. Ich habe jetzt nur noch 10
Sek. angegeben.

Bei Testweisem schreiben des TXT-Record und unmittelbarem Aufruf mit
dig -t txt schabau.eu
wird der TXT-Record sofort und vollständig ausgegeben.

Wenn ich es recht begreife, hätte anderenfalls DEHYDRATED_MODE='test'
auch gar kein positives Ergebnis gebracht, weil der TXT-Record dort ja
ebenso abgefragt wird. Es wird halt nur ein ungültiges Zertifikat erstellt.

> Eventuell findet sich Dein DNS-Provider im Wiki des Projektes:
>
> https://github.com/dehydrated-io/dehydrated/wiki

Ist nicht dabei, ich hatte mir dort aber ein paar Anregungen für mein
Script zusammen gesucht.

In anderen Diskussionen habe ich zwischenzeitlich finden können, dass
auch bei anderen, beim Wechsel von http-01 auf dns-01, diese Meldung
aufgetaucht ist. Wenn das Zertifikat zu neu ist, wirft Let’s Encrypt
wohl diese Meldung aus. Meine Zertifikate sind gerade aktuell und es ist
bei mir jetzt alles auf dns-01 umgestellt. Nun warte ich, bis meine
Zertifikate wieder Update berechtigt sind, und werde sehen, ob das
Update fehlerfrei durchläuft.

> Gruß Jürgen

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

> Bei tls-alpn-01 ist es ähnlich wie bei dns-01, im Grunde ist es nicht
> beschrieben. Es muss wohl irgend ein Server irgendwo sein. Aber wie, wo
> und was Konfiguriert wird...? Ebenso wie bei dns-01, wird wohl ein
> einfaches DEHYDRATED_CHALLENGE_TYPE='tls-alpn-01' nicht ausreichend
> sein. Den DNS TXT-Record kenne ich, so hatte dns-01 für mich Vorrang.

Ich hatte tls-alpn-01 in der Penne benutzt, bis ich den Bezug eines
Zertifikates komplett einstellen musste, als das von mir betreute
Verwaltungsnetz hinter einer städtischen Firwall/Internetzugang "versteckt"
wurde und keinen eigenen, von mir betreuten, Internetzugang mehr hatte.

Für diese Challenge musste ich nichts extern konfigurieren und fand es
stressfrei.

Leider habe ich die Konfiguration nciht mehr verfügbar - auch nicht in
Backups.

--
Gruß Marcus
[eisfair-Team]

[Frank Eckelmann]

Hallo in die Runde,

bei mir wollte das Update auch nicht klappen.
Die quick and dirty Lösung bei meinem Server war das zeitweise Entfernen
der .htaccess Datei im htdocs Verzeichnis.
Der manuell angestoßene Updatevorgang lief dann problemlos durch.

Vielleicht hilfts dem ein oder anderen hier.

VG
Frank

[W. Loefstedt]

Am 12.02.2023 um 08:59 schrieb Frank Eckelmann:

> bei mir wollte das Update auch nicht klappen.
> Die quick and dirty Lösung bei meinem Server war das zeitweise Entfernen
> der .htaccess Datei im htdocs Verzeichnis.
> Der manuell angestoßene Updatevorgang lief dann problemlos durch.

Kann ich bestätigen. Wie muss eine .htaccess-Datei ausssehen, damit das
Update klappt?

Gruss, Wolfgang

[Detlef Paschke]

Entweder für das Update "RewriteEngine off" in der .htaccess angeben
oder in der /etc/apache2/mods-enabled/certs_dehydrated.conf diese Zeile
angegeben und Apache anschließend neu starte.

ist:
Options None

soll:
Options FollowSymLinks MultiViews

> Gruss, Wolfgang

[W. Loefstedt]

Am 12.02.2023 um 22:15 schrieb Detlef Paschke:

> Entweder für das Update "RewriteEngine off" in der .htaccess angeben
> oder in der /etc/apache2/mods-enabled/certs_dehydrated.conf diese Zeile
> angegeben und Apache anschließend neu starte.
>
> ist:
> Options None
>
> soll:
> Options FollowSymLinks MultiViews

Danke für den Hinweis,
Wolfgang

[Juergen Edner]

Hallo zusammen,

>> Bei tls-alpn-01 ist es ähnlich wie bei dns-01, im Grunde ist es nicht
>> beschrieben. Es muss wohl irgend ein Server irgendwo sein. Aber wie, wo
>> und was Konfiguriert wird...? Ebenso wie bei dns-01, wird wohl ein
>> einfaches DEHYDRATED_CHALLENGE_TYPE='tls-alpn-01' nicht ausreichend
>> sein.

Um 'tls-alpn-01' verwenden zu können muss lokal ein entsprechender
Listener gestartet werden, der die https-Anfrage von Let's Encrypt
temporär beantwortet. Die Vorgehensweise sieht dabei wie folgt aus:

startup_hook -> einen eventuell auf Port 443/tcp hörenden
Webserver beenden
startup_hook -> EXEC='/etc/init.d/certs_dehydrated'
OPTIONS='--quiet --start-alpn-server'
deploy_cert -> EXEC='/var/install/config.d/certs_dehydrated.sh'
OPTIONS='--create-eisfair-cert'
deploy_cert -> EXEC='/var/install/config.d/certs_dehydrated.sh'
OPTIONS='--cleanup-certs'
deploy_cert -> EXEC='/var/certs/dehydrated/jed-deploy-cert-test-
script.sh'
OPTIONS=''
invalid_challenge -> EXEC='/var/install/config.d/certs_dehydrated.sh'
OPTIONS='--send-challenge-warning'
exit_hook -> EXEC='/var/install/config.d/certs_dehydrated.sh'
OPTIONS='--restart-eisfair-services-on-request'
exit_hook -> EXEC='/etc/init.d/certs_dehydrated'
OPTIONS='--quiet --stop-alpn-server'
exit_hook -> einen eventuell anfangs gestoppten Webserver
wieder starten.

[Detlef Paschke]

Am 11.02.2023 um 14:53 schrieb Detlef Paschke:

> Meine Zertifikate sind gerade aktuell und es ist
> bei mir jetzt alles auf dns-01 umgestellt. Nun warte ich, bis meine
> Zertifikate wieder Update berechtigt sind, und werde sehen, ob das
> Update fehlerfrei durchläuft.

Ich würde noch ein wenig testen wollen, ob ich evtl. auch auf ein
Wildcard Zertifikat umsteige. Dabei stört mich aber (was ich bei der
Umstellung auf dns-01 festgestellt habe), dass meine produktiven
Zertifikate bei der Einstellung DEHYDRATED_MODE='test', mit ungültigen
Testzertifikaten überschrieben werden und dann erst wieder herstellt
werden müssen. (Das halte ich ehrlich ausgedrückt, für einen "Test"
ziemlich dämlich.)
Kann man angeben, dass die Zertifikate bei DEHYDRATED_MODE='test',
irgendwo oder zumindest mit einem anderen Namen (z.B.
schabau.testcert.eu) abgelegt werden? Auch so ist ersichtlich, ob alles
funktioniert und mit
openssl x509 -in /etc/ssl/certs/schabau.testcert.eu.pem -text -noout
lassen sich die Details des Testzertifikat zeigen.

Viele Grüße
Detlef Paschke

[Juergen Edner]

Hallo Detlef,

> Ich würde noch ein wenig testen wollen, ob ich evtl. auch auf ein
> Wildcard Zertifikat umsteige. Dabei stört mich aber (was ich bei der
> Umstellung auf dns-01 festgestellt habe), dass meine produktiven
> Zertifikate bei der Einstellung DEHYDRATED_MODE='test', mit ungültigen
> Testzertifikaten überschrieben werden und dann erst wieder herstellt
> werden müssen. (Das halte ich ehrlich ausgedrückt, für einen "Test"
> ziemlich dämlich.)
> Kann man angeben, dass die Zertifikate bei DEHYDRATED_MODE='test',
> irgendwo oder zumindest mit einem anderen Namen (z.B.
> schabau.testcert.eu) abgelegt werden? Auch so ist ersichtlich, ob alles
> funktioniert und mit
> openssl x509 -in /etc/ssl/certs/schabau.testcert.eu.pem -text -noout
> lassen sich die Details des Testzertifikat zeigen.

in der Datei /var/certs/dehydrated/config gibt es die folgenden beiden
Parameter die den Pfad beeinflussen. Du kannst die Datei ja einmal
manuell auf andere Verzeichnisse setzen und schauen, ob dies das von Dir
gewünschte Ergebnis bringt:

BASEDIR=/var/certs/dehydrated
ACCOUNTDIR=/var/certs/dehydrated/accounts

Ich setze Deine Anregung einmal auf meine Merkliste.

[Detlef Paschke]

Am 22.02.2023 um 18:18 schrieb Juergen Edner:
> Hallo Detlef,

Hallo Juergen,

ich Danke Dir, das werde ich so machen.
Eine Frage noch. Für ein Wildcard Zertifikat, das Haupt- und Subdomain
abdeckt, gebe ich DEHYDRATED_DOMAIN_1_NAME='*.schabau.eu' an und das
Zertifikat ist dann für alle Subdomain *.schabau.eu _und_ für die
Hauptdomain schabau.eu gültig oder muss schabau.eu und *.schabau.eu
angegeben werden?

> Ich setze Deine Anregung einmal auf meine Merkliste.

Ja, das hatte mich an dem Tag, wo ich die dns-01 Sache durchgetestet hat
sehr überrascht. Ich habe es auch erst bemerkt, als ich später auf eine
meiner Seiten gegangen bin und die Fehlermeldung über ein ungültiges
Zertifikat bekommen habe. Man bemerkt sonst gar nicht, das die
Zertifikate durch die Testzertifikate ausgetauscht wurden.

> Gruß Jürgen

[Juergen Edner]

Hallo Detlef,

>> in der Datei /var/certs/dehydrated/config gibt es die folgenden beiden
>> Parameter die den Pfad beeinflussen. Du kannst die Datei ja einmal
>> manuell auf andere Verzeichnisse setzen und schauen, ob dies das von Dir
>> gewünschte Ergebnis bringt:
>>
>> BASEDIR=/var/certs/dehydrated
>> ACCOUNTDIR=/var/certs/dehydrated/accounts
>
> ich Danke Dir, das werde ich so machen.
> Eine Frage noch. Für ein Wildcard Zertifikat, das Haupt- und Subdomain
> abdeckt, gebe ich DEHYDRATED_DOMAIN_1_NAME='*.schabau.eu' an und das
> Zertifikat ist dann für alle Subdomain *.schabau.eu _und_ für die
> Hauptdomain schabau.eu gültig oder muss schabau.eu und *.schabau.eu
> angegeben werden?

um ehrlich zu sein kann ich diese Frage nicht mit Sicherheit
beantworten, da ich selbst noch nie ein Wildcard-Zertifikat über Let's
Encrypt abgerufen habe. Rein technisch gesehen sind '*.schabau.de' und
'schabau.de' definitiv zwei Paar Schuhe. D.h. der zweite Name sollte
unbedingt auch als Alias angegeben werden. Vielleicht hilft dir diese
Beschreibung weiter:

https://terminaladdict.com/linux/networking/bash/2021/07/21/WildCardSSL.html

[Detlef Paschke]

Am 23.02.2023 um 15:02 schrieb Juergen Edner:
> Hallo Detlef,

Hallo Juergen,

>

ich werde es spätestens bei meinem Test herausbekommen. ;-)
Aber nach dem was ich die letzten Stunden gelesen habe, ist es wohl so,
wie Du auch schon vermutest, dass beides angegeben werden muss. Wenn man
mal in genauer darüber nachdenkt, eigentlich ja auch logisch.

[Detlef Paschke]

Am 23.02.2023 um 15:02 schrieb Juergen Edner:
> Hallo Detlef,

Hallo Juergen,

>> Eine Frage noch. Für ein Wildcard Zertifikat, das Haupt- und Subdomain
>> abdeckt, gebe ich DEHYDRATED_DOMAIN_1_NAME='*.schabau.eu' an und das
>> Zertifikat ist dann für alle Subdomain *.schabau.eu _und_ für die
>> Hauptdomain schabau.eu gültig oder muss schabau.eu und *.schabau.eu
>> angegeben werden?
>
> um ehrlich zu sein kann ich diese Frage nicht mit Sicherheit
> beantworten, da ich selbst noch nie ein Wildcard-Zertifikat über Let's
> Encrypt abgerufen habe. Rein technisch gesehen sind '*.schabau.de' und
> 'schabau.de' definitiv zwei Paar Schuhe. D.h. der zweite Name sollte
> unbedingt auch als Alias angegeben werden. Vielleicht hilft dir diese
> Beschreibung weiter:
>
> https://terminaladdict.com/linux/networking/bash/2021/07/21/WildCardSSL.html

tja, das Problem ist, ich komme noch nicht einmal soweit, dass Let's
Encrypt bei einem Testdurchlauf meckern könnte. Derzeit meckert noch
certs_dehydrated nach Abschluss der Konfiguration.

Activate configuration now (y/n) [yes]? y

version (eisfair-64): v1.1.8
creating domains.txt file ...
no alias defined for wildcard domain in DEHYDRATED_DOMAIN_1_NAME.
no domain(s) defined, check the DEHYDRATED_DOMAIN_x_.. parameters.
finished.
Press ENTER to continue

Ich habe beide Varianten (nur *.schabau.eu oder schabau.eu und
*.schabau.eu) versucht. Der Output war unverändert.

DEHYDRATED_API_VERSION='2'
DEHYDRATED_DOMAIN_1_NAME='schabau.eu:*.schabau.eu'

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

> tja, das Problem ist, ich komme noch nicht einmal soweit, dass Let's
> Encrypt bei einem Testdurchlauf meckern könnte. Derzeit meckert noch
> certs_dehydrated nach Abschluss der Konfiguration.
>
> Activate configuration now (y/n) [yes]? y
>
> version (eisfair-64): v1.1.8
> creating domains.txt file ...
> no alias defined for wildcard domain in DEHYDRATED_DOMAIN_1_NAME.
> no domain(s) defined, check the DEHYDRATED_DOMAIN_x_.. parameters.
> finished.
> Press ENTER to continue
>
> Ich habe beide Varianten (nur *.schabau.eu oder schabau.eu und
> *.schabau.eu) versucht. Der Output war unverändert.
>
> DEHYDRATED_API_VERSION='2'
> DEHYDRATED_DOMAIN_1_NAME='schabau.eu:*.schabau.eu'

Wenn ich den zugehörigen Code von Jürgen korrekt interpretiere, darf die
Wildcarddomain nicht am Ende stehen, sondern muss noch von einer
Nicht-Wildcard-Domain als Alias gefolgt werden.

Da ich in der Doku dazu nichts gefunden habe, muss Jürgen selbst etwas dazu
sagen.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Detlef,

Marcus Röckrath wrote:

>> version (eisfair-64): v1.1.8
>> creating domains.txt file ...
>> no alias defined for wildcard domain in DEHYDRATED_DOMAIN_1_NAME.
>> no domain(s) defined, check the DEHYDRATED_DOMAIN_x_.. parameters.
>> finished.
>> Press ENTER to continue
>>
>> Ich habe beide Varianten (nur *.schabau.eu oder schabau.eu und
>> *.schabau.eu) versucht. Der Output war unverändert.
>>
>> DEHYDRATED_API_VERSION='2'
>> DEHYDRATED_DOMAIN_1_NAME='schabau.eu:*.schabau.eu'
>
> Wenn ich den zugehörigen Code von Jürgen korrekt interpretiere, darf die
> Wildcarddomain nicht am Ende stehen, sondern muss noch von einer
> Nicht-Wildcard-Domain als Alias gefolgt werden.

In der von Jürgen zum Thema Wildcardzertifikat geposteten URL steht der
dehydrated-Kommandozeilenaufruf:

/usr/bin/dehydrated --cron --challenge dns-01 --domain *.example.com --alias
star_example.com --hook /etc/dehydrated/wildcard_hook.sh

Es wird also für ein Wildcardzertifikat auch ein Alias benötigt.

Hast du mal

*.schabau.de:schabau.de

versucht.

--
Gruß Marcus
[eisfair-Team]

[Christian Richter]

Am 24.02.23 um 22:30 schrieb Marcus Röckrath:

>
> Es wird also für ein Wildcardzertifikat auch ein Alias benötigt.
>
> Hast du mal
>
> *.schabau.de:schabau.de
>
> versucht.
>

Ich setze bei mir auch ein Wildcardzertifikat ein und musste in der Config
DEHYDRATED_DOMAIN_1_NAME = richter-ch.de:*.richter-ch.de:richter-ch.de
setzen. Also erst meine Domain, dann den Alias und am Ende nochmals die
Domain. Alle Anderen Konstellationen hatten sonst nicht funktioniert.

Gruß Christian

[Detlef Paschke]

Am 25.02.2023 um 12:24 schrieb Christian Richter:
> Am 24.02.23 um 22:30 schrieb Marcus Röckrath:

Hallo Christian,

>>
>> Es wird also für ein Wildcardzertifikat auch ein Alias benötigt.
>>
>> Hast du mal
>>
>> *.schabau.de:schabau.de
>>
>> versucht.
>>
>
> Ich setze bei mir auch ein Wildcardzertifikat ein und musste in der Config
> DEHYDRATED_DOMAIN_1_NAME = richter-ch.de:*.richter-ch.de:richter-ch.de
> setzen. Also erst meine Domain, dann den Alias und am Ende nochmals die
> Domain. Alle Anderen Konstellationen hatten sonst nicht funktioniert.

ich habe gestern in google.groups (https://web.nettworks.org/forum/ ist
ja leider gestorben), deine Beitrag "Certs_dehydrated dns-01 challenge
mit Cloudflare" gelesen und den nötigen Hinweis gefunden.
Im Grunde habe ich es so wie Du, nur das ich in meinem Script noch einen
clean_challenge Aufruf habe um den DNS-TXT Eintrag nach der Überprüfung
gleich wieder zu entfernen.

Bei den verschiedenen Versuchen hat Let’s Encrypt zwar immer noch
gespuckt und Meldungen wie diese ausgeworfen, weil mein Zertifikat ja
ganz frisch war:

ERROR: Validating this certificate is not possible using dns-01.
Possible validation methods are: http-01

Aber mit einem mal und ohne ersichtlich Veränderung, wurde ein neues
Wildcard-Zertifikat per dns-01 ausgestellt, und das läuft nun.

> Gruß Christian

[Frank Eckelmann]

Hallo,

das gleiche Problem trat eben wieder bei mir auf.
Hängt das evtl. mit dem letzten Update beim Apache2 zusammen?

Am 12.02.2023 um 08:59 schrieb Frank Eckelmann:

[Marcus Röckrath]

Hallo Frank,

Frank Eckelmann wrote:

> das gleiche Problem trat eben wieder bei mir auf.
> Hängt das evtl. mit dem letzten Update beim Apache2 zusammen?
>

>> bei mir wollte das Update auch nicht klappen.
>> Die quick and dirty Lösung bei meinem Server war das zeitweise Entfernen
>> der .htaccess Datei im htdocs Verzeichnis.
>> Der manuell angestoßene Updatevorgang lief dann problemlos durch.

Hast du es wieder durch zeitweises Entfernen der .htaccess lösen können?

Wo kommt diese .htaccess her?

Welchen Inhalt hat sie?

--
Gruß Marcus
[eisfair-Team]

[Frank Eckelmann]

Hallo Marcus,

Am 23.10.2023 um 19:10 schrieb Marcus Röckrath:
>
> Hast du es wieder durch zeitweises Entfernen der .htaccess lösen können?

Ja, das hat wieder geholfen.

> Wo kommt diese .htaccess her?

Ich denke, das sie wegen der Nextcloud reingekommen ist, vermutlich
musste ich sie mal erstellen.

> Welchen Inhalt hat sie?

<IfModule mod_rewrite.c>
RewriteEngine on
# RewriteCond %{HTTP_USER_AGENT} DavClnt
# RewriteRule ^$ /remote.php/webdav/ [L,R=302]
# RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/webfinger
/nextcloud/index.php/.well-known/webfinger [R=301,L]
RewriteRule ^\.well-known/nodeinfo
/nextcloud/index.php/.well-known/nodeinfo [R=301,L]
# RewriteRule ^remote/(.*) remote.php [QSA,L]
# RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^\.well-known/(?!acme-challenge|pki-validation)
/index.php [QSA,L]
# RewriteRule
^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>


VG
Frank