# Zertifikatsprobleme mit Docker + mrbs **URL:** \ **Category:** Docker\ **Created:** [8. Dezember 2019 um 19:28 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594 "2019-12-08T19:28:17Z")\ **Posts on this page:** 19\ **Page:** 2
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [11. Dezember 2019 um 08:18 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/21 "2019-12-11T08:18:17Z")
Hallo Holger, ich hab’ den genau wie von Frank in [Docker KISS + linuxmuster-mrbs](https://ask.linuxmuster.net/t/docker-kiss-linuxmuster-mrbs/3327) beschrieben aufgesetzt. Genaueres sag ich dir heute Mittag, muss schon wieder weiter… Gruß, Mathias ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [11. Dezember 2019 um 18:59 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/22 "2019-12-11T18:59:16Z")
Hallo Holger, > [@baumhof](#): > > echt? > Ein Apache? > Und der sitzt vor allen anderen Maschinen? > … du meinst einen nginx als Reverseproxy, oder? 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 ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [11. Dezember 2019 um 20:05 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/23 "2019-12-11T20:05:04Z")
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 ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [11. Dezember 2019 um 20:49 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/24 "2019-12-11T20:49:10Z")
Hallo Holger, ich habe das System, das in [Docker KISS + linuxmuster-mrbs](https://ask.linuxmuster.net/t/docker-kiss-linuxmuster-mrbs/3327) beschrieben ist. Der Reverseproxy häuft auf dem Host. Ich komme also in das Verzeichnis `/etc/nginx`. > [@baumhof](#): > > Wo läuft den der certbot? Naja, das läuft alles über dehydrate (läuft halt nicht) ☹ > [@baumhof](#): > > Ist das jwilder mit le erweiterung? Hab die Frage nicht verstanden … ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [13. Dezember 2019 um 10:06 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/25 "2019-12-13T10:06:30Z")
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 ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [13. Dezember 2019 um 15:35 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/26 "2019-12-13T15:35:51Z")
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](http://schnulli.dynalias.org) erreichbar ist. Darauf läuft linuxmuster-mrbs im docker, welches unter [mrbs.schnulli.dynalias.org](http://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](http://mrbs.schnulli.dynalias.org) in der domain.txt drin stehen. Das Problem ist nun, dass ein Aufruf von [mrbs.schnulli.dynalias.org](http://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/](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](http://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/](http://mrbs.schnulli.dynalias.org/.well-known/acme/challenge/) abfangen würde und auf [schnulli.dynalias.org/.well-known/acme-challenge/](http://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](http://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](http://mrbs.schnulli.dynalias.org) sah so aus: ```auto 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](http://mrbs.schnulli.dynalias.org) config nach root verschoben und die docker nginx config von [mrbs.schnulli.dynalias.org](http://mrbs.schnulli.dynalias.org) wieder verlinkt: ```auto 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 ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [14. Dezember 2019 um 08:21 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/27 "2019-12-14T08:21:59Z")
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 ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [14. Dezember 2019 um 14:45 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/28 "2019-12-14T14:45:15Z")
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 ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [14. Dezember 2019 um 17:40 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/29 "2019-12-14T17:40:45Z")
Ich probiers… ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [14. Dezember 2019 um 19:25 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/30 "2019-12-14T19:25:21Z")
Hallo zusammen, das ist die Lösung: 1. In der Datei `/srv/docker/linuxmuster-mrbs/docker-compose.yml` unter volumes: die Zeile `- /var/www/dehydrated:/var/www/html/.well-known` hinzufügen. 2. Das Verzeichnis `/var/www/dehydrated/acme-challenge` anlegen. 3. In der Datei `/etc/dehydrated/config` den Eintrag `WELLKNOWN=/var/www/dehydrated` in `WELLKNOWN=/var/www/dehydrated/acme-challenge` ändern. 4. `raumbuchung` und `mariadb` mit docker stop mariadb und `docker stop raumbuchung` stoppen. 5. `raumbuchung` und `mariadb` mit `docker-compose up -d` starten. 6. Mit `dehydrated -c` die Zertifikate erneuern. Das war’s. Gruß, Mathias ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [14. Dezember 2019 um 22:50 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/31 "2019-12-14T22:50:53Z")
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. > > ``` > > 1. > > ``` > Das Verzeichnis |/var/www/dehydrated/acme-challenge| anlegen. > > ``` > > 1. > > ``` > In der Datei |/etc/dehydrated/config| den Eintrag > >WELLKNOWN=/var/www/dehydrated| in > >WELLKNOWN=/var/www/dehydrated/acme-challenge| ändern. > > ``` > > 1. > > ``` > >raumbuchung> und |mariadb| mit docker stop mariadb und |docker stop > raumbuchung> stoppen. > > ``` > > 1. > > ``` > >raumbuchung> und |mariadb| mit |docker-compose up -d| starten. > > ``` > > 1. > > ``` > Mit |dehydrated -c| die Zertifikate erneuern. > > ``` Perfekt: Danke. LG Holger ---
**Author:** ![ironiemix](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/i/a6a055/32.png) [@ironiemix](https://ask.linuxmuster.net/u/ironiemix)\ **Post date:** [15. Dezember 2019 um 19:03 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/32 "2019-12-15T19:03:28Z")
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 ---
**Author:** ![ironiemix](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/i/a6a055/32.png) [@ironiemix](https://ask.linuxmuster.net/u/ironiemix)\ **Post date:** [15. Dezember 2019 um 19:35 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/33 "2019-12-15T19:35:44Z")
Zur weiteren Klarstellung ein Bildchen: ![le_nginx(1)](https://ask.linuxmuster.net/uploads/default/original/2X/4/4617920a9fb68ba5df29b37cfbcbeaaf03debdab.png) `/.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. ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [15. Dezember 2019 um 21:27 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/34 "2019-12-15T21:27:32Z")
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: ```auto ## 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 ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [15. Dezember 2019 um 22:05 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/35 "2019-12-15T22:05:34Z")
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 ---
**Author:** ![ironiemix](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/i/a6a055/32.png) [@ironiemix](https://ask.linuxmuster.net/u/ironiemix)\ **Post date:** [16. Dezember 2019 um 07:00 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/36 "2019-12-16T07:00:30Z")
Hallo, 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 ```auto ## 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 ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [16. Dezember 2019 um 08:47 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/37 "2019-12-16T08:47:59Z")
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 ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [7. April 2020 um 10:57 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/38 "2020-04-07T10:57:45Z")
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 ---
**Author:** ![rettich](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/rettich/32/52_2.png) [@rettich](https://ask.linuxmuster.net/u/rettich)\ **Post date:** [7. April 2020 um 12:31 UTC](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594/39 "2020-04-07T12:31:52Z")
… ach ja, der relevante Teil beginnt mit ```auto ## BEGIN ANSIBLE MANAGED BLOCK ``` und endet bei ```auto ## END ANSIBLE MANAGED BLOCK ``` und natürlich müsst ihr [mrbs.staufer-gymnasium.de](http://mrbs.staufer-gymnasium.de) durch eure URL ersetzen… 😉 [Vorherige Seite](https://ask.linuxmuster.net/t/zertifikatsprobleme-mit-docker-mrbs/4594.md?page=1)