Let's encrypt

[Daniel Kubein]

-------- Weitergeleitete Nachricht --------
Betreff: Re: Problem beim jüngsten Apache2-Update (2.1.0)
Datum: Thu, 31 Jan 2019 06:08:02 +0100


Hallo Marcus,

> Und jetzt kommt letsencrypt ins Spiel, da du du hier auch das sparen
kanst,
> da ein letsencrypt-Zertifikat von einer CA signiert ist, welches FF
und Co
> kennen.
>

Ich habe das mehrfache Zaunfeld vestanden ^^

Also "Error" ->

+ Requesting authorization for superkubi.selfhost.eu...
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for superkubi.selfhost.eu authorization...
-> Executing hook script 'invalid_challenge' ...
+ Cleaning challenge tokens...
+ Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:unauthorized",
"detail": "Invalid response from
http://superkubi.selfhost.eu/.well-known/acme-challenge/a_aeT29Tq_L0wi-XCY19y9rGQQ7CPogmtaWPQO-3zpI:
\"\u003c!DOCTYPE HTML PUBLIC \\\"-//W3C//DTD HTML 4.01
Transitional//EN\\\"\u003e\\n\u003chtml\u003e\\n\u003chead\u003e\\n\u003cmeta
HTTP-EQUIV=\\\"Content-Type\\\" Content=\\\"text/html\"",
"status": 403
},
"uri":
"https://acme-v01.api.letsencrypt.org/acme/challenge/RJns5yE1Tf1weB9u8qT0IEqnmKcyDNcgqQzjWq40FZ8/12077496849",
"token": "a_aeT29Tq_L0wi-XCY19y9rGQQ7CPogmtaWPQO-3zpI",
"validationRecord": [
{
"url":
"http://superkubi.selfhost.eu/.well-known/acme-challenge/a_aeT29Tq_L0wi-XCY19y9rGQQ7CPogmtaWPQO-3zpI",
"hostname": "superkubi.selfhost.eu",
"port": "80",
"addressesResolved": [
"84.134.17.233"
],
"addressUsed": "84.134.17.233"
}
]
})
finished.
Press ENTER to continue
Successfully installed: certs_dehydrated (1.1.2)!


Gruß Daniel

[Marcus Roeckrath]

Hallo Daniel,

Hast du die Anmerkungen von Jürgen gelesen.

Es geht da auch darum, dass die Antwort von einer anderen Website kommt.

--
Gruss Marcus

[Juergen Edner]

Hallo Daniel,

>  + Challenge validation has failed :(
> ERROR: Challenge is invalid! (returned: invalid) (result: {
>   "type": "http-01",
>   "status": "invalid",
>   "error": {
>     "type": "urn:acme:error:unauthorized",
>     "detail": "Invalid response from
> http://superkubi.selfhost.eu/.well-known/acme-challenge/a_aeT29Tq_L0wi-XCY19y9rGQQ7CPogmtaWPQO-3zpI:
> \"\u003c!DOCTYPE HTML PUBLIC \\\"-//W3C//DTD HTML 4.01
> Transitional//EN\\\"\u003e\\n\u003chtml\u003e\\n\u003chead\u003e\\n\u003cmeta
> HTTP-EQUIV=\\\"Content-Type\\\" Content=\\\"text/html\"",
>     "status": 403
>   },
>   "uri":
> "https://acme-v01.api.letsencrypt.org/acme/challenge/RJns5yE1Tf1weB9u8qT0IEqnmKcyDNcgqQzjWq40FZ8/12077496849",
>
>   "token": "a_aeT29Tq_L0wi-XCY19y9rGQQ7CPogmtaWPQO-3zpI",
>   "validationRecord": [
>     {
>       "url":
> "http://superkubi.selfhost.eu/.well-known/acme-challenge/a_aeT29Tq_L0wi-XCY19y9rGQQ7CPogmtaWPQO-3zpI",

Du hast die Dokumentation gelesen:

Den Serverzugriff von extern prüfen

Damit die mit einem automatischen Let's Encrypt^TM
Zertifikatsabruf einhergehende Prüfung der in einem
Zertifikat verwendeten Domain funktioniert, wenn der
Challenge-Typ `http-01' verwendet wird, muss die
folgende URL ueber das Internet erreichbar sein:

http://meine.domain.dom/.well-known/acme-challenge

Der erfolgreiche Zugriff wird durch die Anzeige des
folgenden Textes bestätigt:

Let's Encrypt rocks!

Hinweis
Da für die Anzeige des genannten Textes eine Datei namens
index.html verwendet wird, ist es erforderlich, dass der
Parameter APACHE2_DIRECTORY_INDEX auch diesen Dateinamen
enthält!

Bei Verwendung des Challenge-Typ `tls-alpn-01' ist sicher
zu stellen, dass der TCP-Port 443 bzw. den über den Parameter
DEHYDRATED_ALPN_LISTEN_PORT definierte Port, korrekt an den
ALPN-Responder-Dienst weiter geleitet wird.

Gruß Jürgen

--
Mail: jue...@eisfair.org

[Marcus Roeckrath]

Hallo Jürgen,

Juergen Edner schrieb am Fri, 01 February 2019 10:05
> >
> > http://superkubi.selfhost.eu/.well-known/acme-challenge/a_aeT29Tq_L0wi-X
> > CY19y9rGQQ7CPogmtaWPQO-3zpI:

> Du hast die Dokumentation gelesen:
>
> Den Serverzugriff von extern prüfen
>
> Damit die mit einem automatischen Let's Encrypt^TM
> Zertifikatsabruf einhergehende Prüfung der in einem
> Zertifikat verwendeten Domain funktioniert, wenn der
> Challenge-Typ `http-01' verwendet wird, muss die
> folgende URL ueber das Internet erreichbar sein:
>
> http://meine.domain.dom/.well-known/acme-challenge

Wie du ja schon im anderen Thread bemerkt hast, kommt die Antwort dann
plötzlich von

http://superkubi.homeftp.net/

und somit von einer anderen Domain, als im Zertifikat angegeben.

Ich denke man, kann dann auch beide angeben, wenn das Konstrukt so
gewollt ist. Welche der beiden URLs muss dann aber an erster Stelle
angegeben werden?

Ich denke die, die dann von der Zertifizierungsstelle auch zum Abruf
benutzt wird.
--
Gruß Marcus

[Marcus Roeckrath]

Hallo Daniel,

Daniel Kubein wrote:

[Daniel Kubein]

Hallo Alle,

sorry, ich konnte direkt nach dem Artikelschreiben nichts
mehr in die NG posten.

Es kam Error:

Ein News-(NNTP-)Fehler ist aufgetreten: load at 41.78, try later

Oder Error:

Ein News-(NNTP-)Fehler ist aufgetreten: loadav [innwatch:load] 3590 gt 3500

Gruß Daniel

[Daniel Kubein]

Hallo Marcus,


> Es wäre besser gewesen, hierfür einen neuen Thread aufzumachen.

Hiermit erledigt, sorry!



>> Successfully installed: certs_dehydrated (1.1.2)!
>
> Was hast du gemacht?
>
> Du bist während der Installation die Konfiguration durchgegangen?

Ja ganz genau.
Installiert und direkt aus dem Installationsprozess die
Konfiguration heraus gestartet.



> Poste bitte deine certs_dehydrated-Konfiguration ohne Kommentare.



START_DEHYDRATED='yes'

DEHYDRATED_MODE='live'
DEHYDRATED_EMAIL='daniel at kubein punkt info'

DEHYDRATED_PRIVATE_KEY_RENEW='yes'

DEHYDRATED_PRIVATE_KEY_FILE=''

DEHYDRATED_ACCEPT_AGREEMENT='I ACCEPT THE AGREEMENT'

DEHYDRATED_DOMAIN_N='1'
DEHYDRATED_DOMAIN_1_ACTIVE='yes'
DEHYDRATED_DOMAIN_1_NAME='superkubi.selfhost.eu'

DEHYDRATED_DOMAIN_1_USAGE='all'

DEHYDRATED_CHECK_ON_START='no'

DEHYDRATED_CHECK_CRON='yes'
DEHYDRATED_CHECK_CRON_SCHEDULE='14 0 * * 0'


DEHYDRATED_LOG_COUNT='5' # number of log files to save
DEHYDRATED_LOG_INTERVAL='weekly' # interval: daily, weekly, monthly

>>>
>>>
http://superkubi.selfhost.eu/.well-known/acme-challenge/a_aeT29Tq_L0wi-X
>>> CY19y9rGQQ7CPogmtaWPQO-3zpI:
>> Du hast die Dokumentation gelesen:
>>
>> Den Serverzugriff von extern prüfen
>>
>> Damit die mit einem automatischen Let's Encrypt^TM
>> Zertifikatsabruf einhergehende Prüfung der in einem
>> Zertifikat verwendeten Domain funktioniert, wenn der
>> Challenge-Typ `http-01' verwendet wird, muss die
>> folgende URL ueber das Internet erreichbar sein:
>>
>> http://meine.domain.dom/.well-known/acme-challenge

Ja habe ich gelesen und fest gestellt, dass der
Aufruf nicht geht.
Die Ports sind aber offen und korrekt geroutet,
was man lt. Config-Doku prüfen soll.

> Wie du ja schon im anderen Thread bemerkt hast, kommt die Antwort dann
> plötzlich von
>
> http://superkubi.homeftp.net/
>
> und somit von einer anderen Domain, als im Zertifikat angegeben.

Ähem, nö!
Das habe ich tatsächlich nicht gechecked.
Home-FTPO hatte ich früher, so 2005 oder so,
bis DynDNS das abgeschafft hatte.
Homeftp habe ich aber nirgends mehr in der Config drin,
sondern nur noch Selfhost. Seltsam.

> Ich denke man, kann dann auch beide angeben, wenn das Konstrukt so
> gewollt ist. Welche der beiden URLs muss dann aber an erster Stelle
> angegeben werden?

Nein, das ist so nicht gewollt.

> Hast du die Anmerkungen von Jürgen gelesen.
>
> Es geht da auch darum, dass die Antwort von einer anderen Website kommt.
>

Noch nicht, ich hatte/habe Schwierigkeiten mit news.spline.de


Gruß Daniel

[Marcus Roeckrath]

Hallo Daniel,

Daniel Kubein wrote:

> > Poste bitte deine certs_dehydrated-Konfiguration ohne Kommentare.
>
> START_DEHYDRATED='yes'
>
> DEHYDRATED_MODE='live'

Bis zum Funktionieren würde ich den test-Modus nehmen, sonst könntest du in
eine Zeitsperre, wegen zu vieler Versuche landen.

Wo ist die Cheallengetyp-Zeile?

DEHYDRATED_CHALLENGE_TYPE='http-01'

> DEHYDRATED_EMAIL='daniel at kubein punkt info'

> DEHYDRATED_DOMAIN_N='1'
> DEHYDRATED_DOMAIN_1_ACTIVE='yes'
> DEHYDRATED_DOMAIN_1_NAME='superkubi.selfhost.eu'

http://superkubi.selfhost.eu/.well-known/acme-challenge liefert einen Error

ERROR 403 => Forbidden

Das bedeutet, dass Du keine Zugriffsberechtigung auf diese Seite hast!

dan...@kubein.de

und dann lande ich auf http://superkubi.homeftp.net/, was aber auch nicht
gefunden wird.

http://superkubi.selfhost.eu/.well-known/acme-challenge ist aber die URL,
unter der die Challenge gefunden werden muss.

Da du die Hook-Einstellungen nicht gepostest hast, hast du da etwas
verändert? Die Standardhooks müssen sein.

> Ja habe ich gelesen und fest gestellt, dass der
> Aufruf nicht geht.
> Die Ports sind aber offen und korrekt geroutet,
> was man lt. Config-Doku prüfen soll.

Wenn ich hier <server>/.well-known/acme-challenge aufrufe, kommt, wie Jürgen
schon bemerkt hat "Let's Encrypt rocks!".

ls -laR /var/www/htdocs/certs_dehydrated/

> > Wie du ja schon im anderen Thread bemerkt hast, kommt die Antwort dann
> > plötzlich von
> >
> > http://superkubi.homeftp.net/
> >
> > und somit von einer anderen Domain, als im Zertifikat angegeben.
>
>
> Ähem, nö!
> Das habe ich tatsächlich nicht gechecked.
> Home-FTPO hatte ich früher, so 2005 oder so,
> bis DynDNS das abgeschafft hatte.
> Homeftp habe ich aber nirgends mehr in der Config drin,
> sondern nur noch Selfhost. Seltsam.

Aber irgendwas leitet das immer noch an die alte Adresse weiter.

Was siehst du beim Aufruf von

http://superkubi.selfhost.eu/.well-known/acme-challenge

--
Gruss Marcus

[Juergen Edner]

Hallo zusammen,

> Wo ist die Cheallengetyp-Zeile?
>
> DEHYDRATED_CHALLENGE_TYPE='http-01'

das Setzen dieses Parameters ist nicht zwingend erforderlich

DEHYDRATED_CHALLENGE_TYPE (Optionaler Parameter)
^^^^^^^^^^^^^^^^^^^^
...

Wird dieser Parameter nicht gesetzt, so wird standardmaessig
der Challenge-Typ 'http-01' verwendet.

> Wenn ich hier <server>/.well-known/acme-challenge aufrufe, kommt, wie Jürgen
> schon bemerkt hat "Let's Encrypt rocks!".

Da wurde wohl die Dokumentation nicht korrekt gelesen, denn dort steht:

Den Serverzugriff von extern pruefen
^^^^^^

Damit die mit einem automatischen Let's Encrypt^TM Zertifikatsabruf

einhergehende Pruefung der in einem Zertifikat verwendeten Domain

funktioniert, wenn der Challenge-Typ `http-01' verwendet wird, muss
die folgende URL ueber das Internet erreichbar sein:

^^^^^^^^^^^^^^^^^^

>> > Wie du ja schon im anderen Thread bemerkt hast, kommt die Antwort dann
>> > plötzlich von
>> >
>> > http://superkubi.homeftp.net/
>> >
>> > und somit von einer anderen Domain, als im Zertifikat angegeben.
>>
>> Ähem, nö!
>> Das habe ich tatsächlich nicht gechecked.
>> Home-FTPO hatte ich früher, so 2005 oder so,
>> bis DynDNS das abgeschafft hatte.
>> Homeftp habe ich aber nirgends mehr in der Config drin,
>> sondern nur noch Selfhost. Seltsam.

Manchmal hilft es den Kommandozeilenbrowser `curl -v <url>` für die
Diagnose heran zu ziehen. Dann sieht man z.B. das eine Seite mit
folgendem Inhalt ausgeliefert wird:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<meta HTTP-EQUIV="Content-Type" Content="text/html; charset=iso-8859-1">
<meta http-equiv="Refresh" content="3; URL=http://superkubi.homeftp.net">
<meta name="siteinfo" content="robots.txt">
<meta name="audience" content="all">
<meta name="revisit-after" content="5 days">
<meta name="language" content="de">
<meta name="generator" content="bluefish">
...
<meta name="date" content="2004-01-05">
...
<meta name="Classification" content="persoenliche Homepage">
<meta name="Description" content="Daniels fli4l Router">
^^^^^^^^^^^^^^^^^^^^
...
<title>HTTP 403: forbidden</title>

> Aber irgendwas leitet das immer noch an die alte Adresse weiter.

Vielleicht hilft Dir ja die obige Ausgabe weiter.

[Marcus Roeckrath]

Hallo Jürgen,

Juergen Edner wrote:

>> Wenn ich hier <server>/.well-known/acme-challenge aufrufe, kommt, wie
>> Jürgen schon bemerkt hat "Let's Encrypt rocks!".
>
> Da wurde wohl die Dokumentation nicht korrekt gelesen, denn dort steht:
>
> Den Serverzugriff von extern pruefen
> ^^^^^^

Klar, wollte ihm hiermit auch nur aufzeigen, was er dann sehen sollte - und
das tut es bei ihm nicht, denn der Zugriff ergibt einen Error nmit
folgender Weiterleitung auf einen nicht existierenden Server.

> <meta HTTP-EQUIV="Content-Type" Content="text/html; charset=iso-8859-1">
> <meta http-equiv="Refresh" content="3; URL=http://superkubi.homeftp.net">

Da stehts doch, oder?

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Daniel,

Marcus Roeckrath wrote:

>> Den Serverzugriff von extern pruefen
>> ^^^^^^
>
> Klar, wollte ihm hiermit auch nur aufzeigen, was er dann sehen sollte -
> und das tut es bei ihm nicht, denn der Zugriff ergibt einen Error nmit
> folgender Weiterleitung auf einen nicht existierenden Server.

Wenn ich

http://superkubi.selfhost.eu/certs_dehydrated/index.html

aufrufe, müsste eine simple HTML-Seite kommen, deren Abruf mit curl
folgendes liefern würde:

# curl -v http://xxxx/certs_dehydrated/index.html
* Trying xxxxxx
* TCP_NODELAY set
* Connected to xxxxxxxxx port 80 (#0)
> GET /certs_dehydrated/index.html HTTP/1.1
> Host: xxxxxxx
> User-Agent: curl/7.63.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 04 Feb 2019 17:35:51 GMT
< Server: Apache/2.4
< Last-Modified: Sun, 03 Feb 2019 14:00:26 GMT
< ETag: "1e-580fdcc4980b5"
< Accept-Ranges: bytes
< Content-Length: 30
< Content-Type: text/html; charset=ISO-8859-1
<
<h1>Let's Encrypt rocks!</h1>
* Connection #0 to host localhost left intact

Nun mach das mal mit deiner URL (s. o.); das sieht ganz anders aus, also
wird etwas gänzlich anderres zurückgegeben. Eventuell, weil die Rechte
nicht stimmen und daher nun eine Fehlerseite angezeigt wird.

Du müsstest uns mehr über deinen Webserver sagen.

--
Gruss Marcus

[Daniel Kubein]

Hallo Juergen,

>
> Du hast die Dokumentation gelesen:

Ja.

> Den Serverzugriff von extern prüfen
>
> Damit die mit einem automatischen Let's Encrypt^TM
> Zertifikatsabruf einhergehende Prüfung der in einem
> Zertifikat verwendeten Domain funktioniert, wenn der
> Challenge-Typ `http-01' verwendet wird, muss die
> folgende URL ueber das Internet erreichbar sein:
>
> http://meine.domain.dom/.well-known/acme-challenge

Ist sie nicht, warum auch immer weiß ich nicht.

>
> Der erfolgreiche Zugriff wird durch die Anzeige des
> folgenden Textes bestätigt:
>
> Let's Encrypt rocks!
>
> Hinweis
> Da für die Anzeige des genannten Textes eine Datei namens
> index.html verwendet wird, ist es erforderlich, dass der
> Parameter APACHE2_DIRECTORY_INDEX auch diesen Dateinamen
> enthält!

index.html ist in der Apache-Config gesetzt.

>
> Bei Verwendung des Challenge-Typ `tls-alpn-01' ist sicher
> zu stellen, dass der TCP-Port 443 bzw. den über den Parameter
> DEHYDRATED_ALPN_LISTEN_PORT definierte Port, korrekt an den
> ALPN-Responder-Dienst weiter geleitet wird.

443 ist an 443 nach außen frei gegeben am Router.

Lieben Gruß Daniel

[Daniel Kubein]

Hallo Marcus,

>
> Wo ist die Cheallengetyp-Zeile?
>
> DEHYDRATED_CHALLENGE_TYPE='http-01'

War komplett nicht vorhanden, gab es also gar nicht.
Habe ich jetzt händisch nachgetragen.

> http://superkubi.selfhost.eu/.well-known/acme-challenge liefert einen Error
>
> ERROR 403 => Forbidden
>
> Das bedeutet, dass Du keine Zugriffsberechtigung auf diese Seite hast!
>
> dan...@kubein.de

Ja das ist eine .htaccess mit einem Routing bei nicht vorhanden Ordnern
und Dateien. Die wird auf meinem Server immer ausgeführt.

> und dann lande ich auf http://superkubi.homeftp.net/, was aber auch nicht
> gefunden wird.

Ja das File ist hundealt, passe ich mal direkt an.
Vielleicht liegt es ja daran.
Ich hatte dem jetzt keine Bedeutung zugemessen.

> ls -laR /var/www/htdocs/certs_dehydrated/
>
>> > Wie du ja schon im anderen Thread bemerkt hast, kommt die Antwort dann
>> > plötzlich von
>> >
>> > http://superkubi.homeftp.net/
>> >
>> > und somit von einer anderen Domain, als im Zertifikat angegeben.
>>

Seltsam.


> Aber irgendwas leitet das immer noch an die alte Adresse weiter.
>
> Was siehst du beim Aufruf von
>
> http://superkubi.selfhost.eu/.well-known/acme-challenge

Auch einen Error, wie ihr, auch intern.

Gruß Daniel

[Daniel Kubein]

Hallo Marcus,

>>
>> DEHYDRATED_MODE='live'
>
> Bis zum Funktionieren würde ich den test-Modus nehmen, sonst könntest du in
> eine Zeitsperre, wegen zu vieler Versuche landen.
>

Verdammt, zu spät.
Nun ist es passiert.


File /etc/config.d/certs_dehydrated saved
Checking configuration file ...

Configuration file was saved as certs_dehydrated.2019-02-10-05-19-32 in
/etc/backup.d.

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

version: v1.1.2
creating domains.txt file ...
creating well-known configuration ...
creating certs_dehydrated configuration ...
creating index.html file ...
creating files/links required by eisfair ...
+ domain 'superkubi.selfhost.eu':
- skipped.
checking package usage definition ...
checking symbolic links to certificate ...
+ domain 'superkubi.selfhost.eu':
- link 'apache.pem' ok.
- link 'exim.pem' ok.
- link 'imapd.pem' ok.
- link 'ipop3d.pem' ok.
- link 'pure-ftpd.pem' ok.
looking for dead symbolic link to certificate files ...
adding cronjob ...
creating logrotate configuration ...
Creating Apache2 configuration ...
activating modules...
done activating modules
apache2-mod_brotli: activate
requesting/updating certificate(s) ...
# INFO: Using main config file /etc/dehydrated/config
Processing superkubi.selfhost.eu
+ Signing domains...
+ Generating private key...
+ Generating signing request...

+ Requesting authorization for superkubi.selfhost.eu...
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for superkubi.selfhost.eu authorization...

+ Challenge is valid!
+ Cleaning challenge tokens...
+ Requesting certificate...
+ ERROR: An error occurred while sending post-request to
https://acme-v01.api.letsencrypt.org/acme/new-cert (Status 429)

Details:
HTTP/1.1 100 Continue
Expires: Sun, 10 Feb 2019 04:20:06 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 429 Too Many Requests
Server: nginx
Content-Type: application/problem+json
Content-Length: 202
Boulder-Requester: 50578512
Replay-Nonce: v5Wr8g6lu6FzE2QgZiSHwJXhjdoTLzKQFxUSaAg5YoU
Expires: Sun, 10 Feb 2019 04:20:06 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sun, 10 Feb 2019 04:20:06 GMT
Connection: close

{
"type": "urn:acme:error:rateLimited",
"detail": "Error creating new cert :: too many certificates already
issued for: selfhost.eu: see https://letsencrypt.org/docs/rate-limits/",
"status": 429
}

finished.


Gruß Daniel

[Marcus Roeckrath]

Hallo Daniel,

Daniel Kubein wrote:

>>> DEHYDRATED_MODE='live'
>>
>> Bis zum Funktionieren würde ich den test-Modus nehmen, sonst könntest du
>> in eine Zeitsperre, wegen zu vieler Versuche landen.
>
> Verdammt, zu spät.
> Nun ist es passiert.

Du wirst aber auch wieder freigeschaltet. Ein wenig Geduld ist angesagt.

> + Responding to challenge for superkubi.selfhost.eu authorization...
> + Challenge is valid!

Das zeigt aber, dass die Konfoguration nun wohl ok ist.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Daniel,

Daniel Kubein wrote:

>> Bei Verwendung des Challenge-Typ `tls-alpn-01' ist sicher
>> zu stellen, dass der TCP-Port 443 bzw. den über den Parameter
>> DEHYDRATED_ALPN_LISTEN_PORT definierte Port, korrekt an den
>> ALPN-Responder-Dienst weiter geleitet wird.
>
> 443 ist an 443 nach außen frei gegeben am Router.

Irgendwie ist diese Anleitung noch nicht ganz verständlich; Jürgen hat mich
auch erst auf die richtige Konfiguration an dieser Stelle hingewiesen, als
wir telefonisch noch einen Bug im Paket gesucht haben.

Der ALPN-Responder-Dienst ist ein eigener Dienst, der natürlich lokal nicht
auf dem https-Port des Apachen laufen darf - zwei Dienste auf gleichem Port
geht nicht.

Benutzt man also einen lokalen Webserver auf dem Port 443, muss man
DEHYDRATED_ALPN_LISTEN_PORT auf einen anderen freien Port setzen z. B.
8443 ...

Im Router ist dann der Port 443 nach intern 8443 weiterzuleiten.

Falls natürlich im Regelfall eine Weiterleitung von 443 an den internen
Webserver gewünscht ist, müsste man nun folgende Schritte über die Hooks
auf dem Router realisieren:

1. Löschen der Weiterleitung des 443 an den internen Webserver
2. Anlegen der Weiterleitung des 443 an den ALPN-Responder-Port

[Zertifikatsanforderung)

3. Löschen der Weiterleitung des 443 an den ALPN-Responder
4. Anlegen der Weiterleitung des 443 an den internen Webserver

Bei einer Fritzbox als Router kann das Paket avm_fritz_toolbox genutzt
werden, um in den Hooks diese Settings vorzunehmen. Beispiele für die
entsprechenden Skriptaufrufe hat Jürgen in der Konfigurationsdatei von
certs_dehydrated hinterlegt.

@Jürgen:
Laut Linux-Magazin 3/19 S. 16 soll das ACME-Protokoll im Apachen driekt
implementiert sein; hast du Kenntnis, ob das für unseren Apachen der Fall
ist?

--
Gruss Marcus

[Juergen Edner]

Hallo Marcus,

> @Jürgen:
> Laut Linux-Magazin 3/19 S. 16 soll das ACME-Protokoll im Apachen driekt
> implementiert sein; hast du Kenntnis, ob das für unseren Apachen der Fall
> ist?

damit habe ich mich auch bereits auseinander gesetzt und mich
entschieden diesen Ansatz nicht weiter zu verfolgen, da es
bedeutet hätte die ganze certs_dehydrated-Funktion mit einer
größeren Abhängigkeit zu anderen Paketen neu zu entwickeln.

Der Prozess wäre letztendlich gleich geblieben und auch ein
apache2-Neustart wäre regelmäßig notwendig geworden. So wie
es jetzt ist ist es gut und funktioniert auch schon seit
1,5 Jahren problemlos.

Die nächste Paketversion wird die besprochenen Erweiterungen
für das tls-alpn-01 Protokoll mitbringen und solange muss man
sich eben noch mit http-01 zufrieden geben.

[Marcus Roeckrath]

Hallo Jürgen,

Juergen Edner wrote:

> Die nächste Paketversion wird die besprochenen Erweiterungen
> für das tls-alpn-01 Protokoll mitbringen und solange muss man
> sich eben noch mit http-01 zufrieden geben.

Habe ich in meinem Post die notwendigen Portsweiterleitungen korrekt
dargestellt?

--
Gruss Marcus

[Juergen Edner]

Hallo Marcus,

>> Die nächste Paketversion wird die besprochenen Erweiterungen
>> für das tls-alpn-01 Protokoll mitbringen und solange muss man
>> sich eben noch mit http-01 zufrieden geben.
>
> Habe ich in meinem Post die notwendigen Portsweiterleitungen korrekt
> dargestellt?

wie üblich gibt es verschiedene Wege wie man Portweiterleitungen
einrichten kann. Der von Dir beschriebene Weg ist eine durchaus
zu empfehlende Konfigurationsvariante.