Zertifikatsprobleme mit Docker + mrbs

ironiemix · 8. Dezember 2019 um 21:54

Das könnte sein. Mach mal die 80 auf.

rettich · 10. Dezember 2019 um 11:07

Halllo Frank,

wie verhindere ich, dass Anfragen auf Port 80 auf Port 443 umgeleitet werden?

Gruß,

Mathias

baumhof · 10. Dezember 2019 um 12:56

Hallo Mathias,

Das könnte sein. Mach mal die 80 auf.
wie verhindere ich, dass Anfragen auf Port 80 auf Port 443 umgeleitet
werden?

das wird in der /etc/apache2/sitres-enabled/???
geregelt.
Da hab ich das zumindest drin.

Ich meine, ich hätte das auch mal temporär für ein certbotlauf
rausnehmen müssen.

Ich nehme an, dass du das dort eingetragen hast und dass du dir einen
Vermerk dazu gemacht hast, damit du es nach Jahren wieder erkennst.

LG

Holger

rettich · 10. Dezember 2019 um 22:19

Halllo Holger,

vielen Dank schon mal für deine Antwort.
Wie mach’ ich das? Der Apache läuft ja in einem Docker-Container.

Gruß,
Mathias

baumhof · 10. Dezember 2019 um 23:56

Hallo Mathias,

Wie mach’ ich das? Der Apache läuft ja in einem Docker-Container.

echt?
Ein Apache?
Und der sitzt vor allen anderen Maschinen?
… du meinst einen nginx als Reverseproxy, oder?

Beschreib mal dein setup genauer.
Wo steht den der docker?
Wo läuft welcher reverseproxy?
Wo läuft der certbot?

LG

Holger

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