Zertifikatsprobleme mit Docker + mrbs

rettich · 11. Dezember 2019 um 08:18

Hallo Holger,

ich hab’ den genau wie von Frank in Docker KISS + linuxmuster-mrbs beschrieben aufgesetzt.

Genaueres sag ich dir heute Mittag, muss schon wieder weiter…

Gruß,
Mathias

rettich · 11. Dezember 2019 um 18:59

Hallo Holger,

Du hattest schon Recht. Auf dem Dockerhost läuft kein Apache. Es ist der nginx. Nur wie bekomme ich das Problem in den Griff?
Wenn ich mich recht erinnere, hattest du das gleiche Problem. Wie hast du das gelöst?
Gruß,
Mathias

baumhof · 11. Dezember 2019 um 20:05

Hallo Mathias,

Du hattest schon Recht. Auf dem Dockerhost läuft kein Apache. Es ist der
nginx. Nur wie bekomme ich das Problem in den Griff?
Wenn ich mich recht erinnere, hattest du das gleiche Problem. Wie hast
du das gelöst?

ich habe apache auf meinem Host, auf dem es das Problem gab.
Ich hab seine config angepaßt, ein update gemacht und wieder umgeleitet …

Jetzt erzähl doch erst mal was du da genau hast:
ist der reverseproxy im Docker oder auf dem Host?
Wo läuft den der certbot?
Ist das jwilder mit le erweiterung?

LG

Holger

rettich · 11. Dezember 2019 um 20:49

Hallo Holger,

ich habe das System, das in Docker KISS + linuxmuster-mrbs beschrieben ist.
Der Reverseproxy häuft auf dem Host. Ich komme also in das Verzeichnis /etc/nginx.

Naja, das läuft alles über dehydrate (läuft halt nicht)

Hab die Frage nicht verstanden …

baumhof · 13. Dezember 2019 um 10:06

Hallo Mathias,

ich hab bei meinem Docker seit 3 Tagen das selbe Problem …
Gestern Nacht hab ich es nicht geschafft, das zu beheben.
Ich bin dabei.
Wenn ich es raus gefunden habe, dann schreibe ich dir.

Ich muß schon sagen, dass ich das mit Lets Encrypt noch nciht als der
Weisheit letzter Schluss betrachte.
Defakto muss ich da schon pro server alle 6 bis 8 Monate hinlangen: und
da das einige Server sind, komm ich fast auf: alle 2 Monate flennt
irgend einer rum, und immer wegen was anderem …
Da ist noch Luft nach oben, sagen wir mal …

LG

Holger

baumhof · 13. Dezember 2019 um 15:35

Hallo zusammen,

ich hab das Problem nun vorübergehend gelöst: es wird mir aber in 90
Tagen wieder in die Suppe Spucken…

Die Laune war nicht wirklich die ganze Zeit gut …

Was ist das Problem:

ich habe den Dockerhost, der unter
schnulli.dynalias.org
erreichbar ist.
Darauf läuft linuxmuster-mrbs im docker, welches unter
mrbs.schnulli.dynalias.org
erreichbar ist. Beide Domains werden im DNS mit der selben IP geführt.

Als Reverseproxy dient nginx auf dem Host und dehydrated zum Holen der
Certs.
dehydrated hat mrbs.schnulli.dynalias.org in der domain.txt drin stehen.

Das Problem ist nun, dass ein Aufruf von mrbs.schnulli.dynalias.org
immer an den Container weitergeleitet wird.
die Validierung des Certs muß aber unter
http://mrbs.schnulli.dynalias.org/.well-known/acme-challenge/ von außen
erreicht werden können.
Das ist aber im Container und dessen www Verzeichnis liegt im Container
und nicht im Hostdateisystem.
Damit kommt dehydratet an das Verzeichnis nicht ran sondern erstellt die
Challenge im Hostdateisystem, wo man per mrbs.schnulli.dynalias.org
nicht ran kommt.

Lösung wäre, wenn nginx auf dem Host die Abfrage von
mrbs.schnulli.dynalias.org/.well-known/acme/challenge/ abfangen würde
und auf schnulli.dynalias.org/.well-known/acme-challenge/ umleiten
würde: dann wäre alles OK und es würde klappen.
Das konnte ich nginx aber nciht beibringen (configs stehen unten).

Also hab ich das Hemdsärmlich gelöst, indem ich die mrbs site disabeld
habe, dann eine site erstellt habe, die mrbs.schnulli.dynalias.org auf
dem Host direkt erreichbar macht und dann hat es geklappt.
Meine vorübergehende config für mrbs.schnulli.dynalias.org sah so aus:

server {
	listen 80;
	listen [::]:80;

	server_name mrbs.schnulli.dynalias.org;

	root /var/www/html;
	index index.html;

	location / {
		try_files $uri $uri/ =404;
	}
}

Ich mußte aber die Verzeichnisse .well-known/acme-challenge erschaffen
in /var/www/html
und dem dehydrated in /etc/dehydrated/config
sagen, dass er WELL-KNOWN hier sucht:
WELLKNOWN=/var/www/html/.well-known/acme-challenge/

Nachdem das gemacht war (und service nginx restart eingegeben wurde) hat
dehydrated -c funktioniert.
Danach hab ich die
mrbs.schnulli.dynalias.org
config nach root verschoben und die docker nginx config von
mrbs.schnulli.dynalias.org wieder verlinkt:

ln -s /srv/docker/linuxmuster-mrbs/config/nginx.mrbs.conf
mrbs.schnulli.dynalias.org

Viel Spass beim Nachstellen.
Natürlich wäre ich sehr dankbar, wenn mir jemand sagen könnte, wie die
nginx siteconfigs aussehen müßten, damit das wieder automatisch passiert…

LG

Holger

/etc/nginx/sites-enabled/default

[code]

Default server configuration

rettich · 14. Dezember 2019 um 08:21

Hallo Holger,
vielen Dank schon mal für deine Antwort.
Bisher bin ich noch nicht dazugekommen (Schulfest, Kollegenessen, …), aber ich hätte da eine Idee:
Könnte man nicht mit Volumes das Verzeichnis .well-known/acme-challenge/ umleiten?
Auf die Weise habe ich unsere Datenschutzerklärung in den dockerkontainer bekommen.

Gruß,

Mathias

baumhof · 14. Dezember 2019 um 14:45

Hallo Mathias,

vielen Dank schon mal für deine Antwort.
Bisher bin ich noch nicht dazugekommen (Schulfest, Kollegenessen, …),
aber ich hätte da eine Idee:
Könnte man nicht mit Volumes das Verzeichnis .well-known/acme-challenge/
umleiten?

ja: das hatte ich mir auch gedacht: wäre nachhaltiger, fand ich aber im
Moment komplizierter: ich wollte schnell zu einem Ergebniss kommen.
Ich hatte auch schon nachgeschaut mit einer shell im dock wo da die
Webseite liegt und was da alles rum liegt.
Und dann hab ich geschaut, wie man die Dateien aus dem dock heraus
kopieren kann, damit die dann außen verfügbar sind.
Noch besser wäre es natürlich, wenn man nur .well-known rausholen würde,
da ja sonst alles im www Verzeichis beim Update des docks nicht erneuert
würde … und da liegt ja der Hauptteil des mrbs …
Also auf jeden Fall nur /var/www/.well-known aus dem dock heraus irgend
wo nach /var/www/dehydratet/ hängen…

Wenn du das machst, dann nehme ich gerne die Lösung und übertrag sie in
mein System

LG

Holger

rettich · 14. Dezember 2019 um 17:40

Ich probiers…

rettich · 14. Dezember 2019 um 19:25

Hallo zusammen,
das ist die Lösung:

In der Datei /srv/docker/linuxmuster-mrbs/docker-compose.yml unter volumes: die Zeile
- /var/www/dehydrated:/var/www/html/.well-known
hinzufügen.
Das Verzeichnis /var/www/dehydrated/acme-challenge anlegen.
In der Datei /etc/dehydrated/config den Eintrag WELLKNOWN=/var/www/dehydrated in WELLKNOWN=/var/www/dehydrated/acme-challenge ändern.
raumbuchung und mariadb mit docker stop mariadb und docker stop raumbuchung stoppen.
raumbuchung und mariadb mit docker-compose up -d starten.
Mit dehydrated -c die Zertifikate erneuern.

Das war’s.

Gruß,
Mathias

baumhof · 14. Dezember 2019 um 22:50

Hallo Mathias,

In der Datei |/srv/docker/linuxmuster-mrbs/docker-compose.yml| unter
volumes: die Zeile
>- /var/www/dehydrated:/var/www/html/.well-known|
hinzufügen.

Das Verzeichnis |/var/www/dehydrated/acme-challenge| anlegen.

In der Datei |/etc/dehydrated/config| den Eintrag
>WELLKNOWN=/var/www/dehydrated| in
>WELLKNOWN=/var/www/dehydrated/acme-challenge| ändern.

>raumbuchung> und |mariadb| mit docker stop mariadb und |docker stop
raumbuchung> stoppen.

>raumbuchung> und |mariadb| mit |docker-compose up -d| starten.

Mit |dehydrated -c| die Zertifikate erneuern.

Perfekt: Danke.

LG

Holger

ironiemix · 15. Dezember 2019 um 19:03

Hallo,

ich muss mir das in den Weihnachtsferien nochmal anschauen, kann aber relativ sicher sagen, dass es so nicht gedacht ist.

Eigentlich macht der Nginx auf dem Docker Host als Reverse Proxy das Zertifikatsbusiness komplett alleine. Der Apache, der im mrbs-container mitkommt, liefert ans Internet nach aussen normalerweise nichts aus und an den Nginx auf localhost alles per http, der braucht also kein Zertifikat im Container.

Die Anfragen an .well-known von LE aus sollte ebenfalls für alle Container auf diesem Docker-Host der Nginx abfangen und korrekt beantworten, in den Containern braucht es da keine Zertifikate und keine Volumes.

Da der mrbs-Container von @Tobias weiterentwickelt wurde (auch für de v7) bin ich aber gerade nicht komplett im Bilde, wer da wo falsch abgebogen ist.

Vermuten würde ich, dass deine Nginx Konfiguration eben nicht mehr alle Anfragen für das .well_known
Zeug beantwortet, sondern diese an den (mrbs-)Container durchreicht - und das ist der eigentliche Fehler, der in der Nginx-Config behoben werden muss, nicht dadurch, dass man das alles an den Apachen des Containers durchschleift.

VG

Frank

ironiemix · 15. Dezember 2019 um 19:35

Zur weiteren Klarstellung ein Bildchen:

/.well-known/acme-challenge/ muss also in keinen Container durchgereicht werden, un der httpd keines der Container mach https, die machen alle http, der sichere Endpoint ist der Nginx als Reverse Proxy, nur der exposed die Ports 80 und 443 ins Internet.

baumhof · 15. Dezember 2019 um 21:27

Hallo Frank,

Vermuten würde ich, dass deine Nginx Konfiguration eben nicht mehr alle
Anfragen für das .well_known
Zeug beantwortet, sondern diese an den (mrbs-)Container durchreicht -
und das ist der eigentliche Fehler, der in der Nginx-Config behoben
werden muss, nicht dadurch, dass man das alles an den Apachen des
Containers durchschleift.

genau so habe ich das auch verstanden, und so war es ja auch früher mal.
Die Zeilen:

## BEGIN ANSIBLE MANAGED BLOCK
location ^~ /.well-known/acme-challenge {
    alias /var/www/dehydrated;
}
## END ANSIBLE MANAGED BLOCK

die von deinem Ansible in die /etc/nginx/sites-enabled/default
eingefügt werden, sollen ja genau das bewirken: tun sie aber nicht mehr.
Wir müssen das aber so wieder zum laufen bekommen, sonst bekommt man
Probleme, wenn eine andere Domain die auf dem Host läuft, ein neues
Zertifikat will…

LG

Holger

rettich · 15. Dezember 2019 um 22:05

Hallo Frank, hallo Holger,

bisher hat der dehyfrated seine Datei für die Überprüfung des Webauftritts in /var/www/dehydrated/ abgelegt. Wenn dann letsencrypt nach dieser Datei in .wellknown/acme-challenge gesucht hat, hat es die Datei nicht gefunden. Folge war kein Zertifikat

Mit der Umstellung, das Zertifikat in /var/www/dehydrated/acme-challenge kann letsencrypt das Zertifikat an der richtigen Stelle finden.

Wenn also nginx solche Abfragen abfängt, war der Eintrag WELLKNOWN=/var/www/dehydrated/amce-challenge in /etc/dehydrated/config allein dafür verantwortlich, dass das Zertifikat erneuert wurde.

Gruß,
Mathias

ironiemix · 16. Dezember 2019 um 07:00

Hallo,

klar, die Konfiguration in /etc/dehydrated/config:

Muss natürlich zu der des Nginx passen

## BEGIN ANSIBLE MANAGED BLOCK
location ^~ /.well-known/acme-challenge {
    alias /var/www/dehydrated;
}
## END ANSIBLE MANAGED BLOCK

ob da dann jeweils /var/www/dehydrated oder /var/www/dehydrated/acme-challenge steht ist IMHO so lang wie breit (in diesem Beispiel oben gehts also nicht, weils halt verschieden ist).

Die Frage bleibt: wann wurde das wodurch so verändert, dass es nicht mehr passt? Muss ich in den Ferien mal testen.

Was ist dann dann erst mal die Lösung? Man muss dafür sorgen, dass das passt, dann gehts, oder?

VG

Frank

baumhof · 16. Dezember 2019 um 08:47

Hallo Frank,

klar, die Konfiguration in |/etc/dehydrated/config|:
rettich:

>WELLKNOWN=/var/www/dehydrated/amce-challenge| in
>/etc/dehydrated/config|
Muss natürlich zu der des Nginx passen

BEGIN ANSIBLE MANAGED BLOCK location ^~ /.well-known/acme-challenge

{ alias /var/www/dehydrated; } ## END ANSIBLE MANAGED BLOCK |

ob da dann jeweils |/var/www/dehydrated| oder

/var/www/dehydrated/acme-challenge| steht ist IMHO so lang wie breit
(in diesem Beispiel oben gehts also nicht, weils halt verschieden ist).

das ist mir auch klar.
Michael und ich haben die dehydratet config nur geändert, weil es eben
nicht mehr funktionierte.
Vorher stand da natürlich schon
/var/www/dehydratet drin.

Du mußt also nicht suchen, was wann die config geändert hat: es waren
Michael und ich selber, nachdem es nicht merh funktioniert hatte.

Grund, dass es nicht mehr funktioniert hatte war, dass der nginx die
Anfragen von außen auf das Verzeichnis /.well-known/acme-challenge/
nicht mehr selbst direkt beantwortete, sondern an den dock weiterleitete.

LG

Holger
LG

Holger

rettich · 7. April 2020 um 10:57

Hallo zusammen,
falls das Problem in der Zwischenzeit gelöst wurde… auch gut.
Ich glaube, ich hab jetzt eine Lösung:

Das Problem war ja, dass Die Überprüfung, ob man Eigentümer der entsprechenden Domain ist, erfolgt durch Anlegen einer bestimmten Datei auf dem Server unter /.well-known/acme-challenge , die dann der Let’s Encrypt Server über http abruft.

Bei uns werden allerdings alle Seiten auf https umgeleitet. Und damit sind wir im Container von mrbs und da gibt’s die Datei nicht => Kein Zertifikat

Beim ersten mal klappt das ganz gut, weil bis dahin der mrbs-Container noch nicht existiert hat. Ab dann (drei Monate später) geht nichts mehr.

Lösung:

Wir machen die Umleitung auf den Docker-Container nur für Seiten die /.well-known/acme-challenge nicht enthalten. Und URLs die /.well-known/acme-challenge enthalten werden auf /var/www/dehydrated umgeleitet.

Dazu geht man wie folgt vor:

Editiere die Datei /srv/docker/linuxmuster-mrbs/confi/nginx.mrbs.conf:

upstream backend {
   server localhost:7777;
   keepalive 32;
}

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mrbs_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
    listen 80;
    listen [::]:80;
    server_name mrbs.staufer-gymnasium.de;

## BEGIN ANSIBLE MANAGED BLOCK
    location / {
    return 301 https://mrbs.staufer-gymnasium.de$request_uri;
    }

    location ^~ /.well-known/acme-challenge {
    alias /var/www/dehydrated;
    }
## END ANSIBLE MANAGED BLOCK

}
…

Gruß,

M. Rettich

rettich · 7. April 2020 um 12:31

… ach ja, der relevante Teil beginnt mit

## BEGIN ANSIBLE MANAGED BLOCK

und endet bei

## END ANSIBLE MANAGED BLOCK

und natürlich müsst ihr mrbs.staufer-gymnasium.de durch eure URL ersetzen…