Welcher unkomplizierte Zertifikatsdienst für Docker Container auf einem Pi?

[h00bi]

Hallo zusammen,

Ich habe sowohl zuhause als auch bei meinen Eltern RasPis am laufen. Die meisten Dienste laufen in Docker Containern. Damit komme ich ansich auch ganz gut klar, auch wenn es mehrere Container werden die sich teilweise überschneiden.

An was ich nun aber ständig scheitere ist die eigenständige Einrichtung eines Lets encrypt Dienstes bzw. die Abwandlung von Tutorials auf zusätzliche Container.
Ich habe nach dem ct/heise Tutorial einen RasPi mit Traefik und Vaultwarden am laufen (der ja zwingend ein Zertifikat erfordert), bekomme es aber nicht hin, dass der unifi-contoller oder plex auf dem gleichen RasPi laufen.
Habe mir auch schon nginx angeschaut, macht es auf Anhieb aber nicht leichter.

Mir würde es auch reichen wenn der Reverse Proxy z.B. den Port 8443 (für den Unificontroller) ignorieren würde (was ja aber nicht der Sinn eines Reverse Proxys ist) oder ich das untrusted Zertifikat vom Unificontoller irgendwie akzeptabel machen, was laut traefik Doku machbar sein soll, ich aber nicht hinbekomme.

Ich nutze traefik wirklich nur für die Zertifikatserstellung und -erneuerung von Vaultwarden. Die Dienste sollen sowieso nicht public erreichbar sein und ob das Zertifikat intern gültig ist, ist mir eigentlich egal.
Geht das nicht einfacher ohne Reverse Proxy, aber trotzdem automatisiert?
Bei den anderen Diensten und Containern hab ich kein Problem mit den Ports zu jonglieren, wenn nötig.

Momentan ist die Lösung einen separaten Pi für Vaultwarden zu betreiben.
Ich hätte das aber gerne gebündelt auf einem.

 

[Paddy0293]

@h00bi eventuell hilft dir das hier weiter Hatte damals ne kleine Anleitung geschrieben für das Thema

Anleitung

 

[DonConto]

Hallo zusammen,
Ich habe sowohl zuhause als auch bei meinen Eltern RasPis am laufen. Die meisten Dienste laufen in Docker Containern. Damit komme ich ansich auch ganz gut klar, auch wenn es mehrere Container werden die sich teilweise überschneiden.

Was heißt das "teilweise überschneiden"? Dass die Applikationen im Container auf dem gleichen UDP/TCP Port laufen? Das ist ja erst mal egal. Wichtig ist doch auf welchen Port der Container "lauscht".

Sofern jeder Container einen eigenen externen Port hat kann dieser ja vom Reverse Proxy angesprochen werden...

An was ich nun aber ständig scheitere ist die eigenständige Einrichtung eines Lets encrypt Dienstes bzw. die Abwandlung von Tutorials auf zusätzliche Container.
Ich habe nach dem ct/heise Tutorial einen RasPi mit Traefik und Vaultwarden am laufen (der ja zwingend ein Zertifikat erfordert), bekomme es aber nicht hin, dass der unifi-contoller oder plex auf dem gleichen RasPi laufen.
Habe mir auch schon nginx angeschaut, macht es auf Anhieb aber nicht leichter.

Ich habe jetzt dein Problem noch nicht ganz durchschaut. Ich kann dir aber als Reverse Proxy den "nginx proxy manager" ans Herz legen. Ich weiß, dass die Entwicklung da gerade stockt, aber das Ding ist wirklich gut und einfach zu administrieren. Das schafft man mit ein bisschen Hintergrundwissen sogar ohne Einarbeitung/Tutorial lesen. Vielleicht fällt dir damit die Einrichtung leichter.

 

[NeoExacun]

Wenn deine Dienste nicht von außen erreichbar sind, wirst du auch keine LetsEncrypt Zertifikate bekommen.

 

[Paddy0293]

@NeoExacun Hä klar ? Siehe Anleitung!

 

[Der Lord]

@NeoExacun klar kann man auch ohne Ports öffnen LE Zertifikate erhalten. Die DNS Challenge macht's möglich.
DNS Provider mit passender API ist dann notwendig.

 

[NeoExacun]

Das mag schon sein. Der TE schreibt allerdings, dass er Let's Encrypt Zertifikate will, schreibt aber auch, dass seine Dienste nicht von außen erreichbar sein sollen.

Daher gehe ich davon aus, dass Let's Encrypt weder seine Dienste noch einen (vermutlich nichtmal vorhandenen) DNS erreichen kann.

 

[Der Lord]

So oder so ist auf Basis dieser Faktenlage deine Aussage ("ohne offene Ports keine LE-Zertifikate") schlicht falsch.

Es spielt auch keine Rolle ob seine Dienste vom Internet aus erreichbar sind. LE muss nur die DNS-Server der betroffenen Domain erreichen können, die normal bei einem großen Registrar liegen und natürlich immer erreichbar sein sollten - sonst bräuchte dieser keine Domains verkaufen weil nutzlos...

 

[Helge01]

Wenn deine Dienste nicht von außen erreichbar sind, wirst du auch keine LetsEncrypt Zertifikate bekommen.

Nicht ganz, hat man einen DynDNS Anbieter mit API dann geht das auch ohne Zugriff.

Würde aber in dem Fall eine eigene CA mit Hilfe von XCA aufbauen. Das ganze dauert keine 10 Minuten und man ist unabhängig auch in der Laufzeit.

 

[Renegade334]

DNS Provider mit passender API ist dann notwendig.

Oder man nutzt weiterhin http solange der Traffic zum passenden Cert Dienst umgeleitet wird.
Machbar ist beides.

@NeoExacun
Wenn er eine externe Domain hat, die über den internen FQDN liegt, ist das auch komplett isoliert kein Problem.
Notfalls kann man das sogar mit DynDNS machen, wenn man mit der Adresse leben kann und die Abfragen für alle internen Adressen auf den Cert Dienst umleitet.

 

[NeoExacun]

Wenn ihr meint, dann ist meine Faktenlage halt falsch^^ Ich kann jedenfalls beim TE nirgends was von Domain oder DNS lesen.

 

[Der Lord]

Die Frage ist doch viel mehr, braucht es überhaupt gültige LE-Zertifikate?
Weil:

und ob das Zertifikat intern gültig ist, ist mir eigentlich egal.

Hab mit dem Unificontroller nix am Hut, daher bin ich hier leider raus. Aber sollte man doch sicher irgendwo auch ignorieren können bzw. als trusted abstempeln können.

 

[h00bi]

Bevor ihr euch hier an einer Formuluierung aufhängt:
Vaultwarden will zwingend ein Zertifikat. Alles was dazu public erreinbar gemacht werden muss wird auch erreichbar gemacht.

In den gängigen Tutorials wird das LE Zertifikat immer über einen reverse proxy realisiert, mit dem ich aber aktuell nicht klar komme und daher nichts anderes mehr auf dieser Kiste hosten kann.
Daher suche ich entweder einen anderen Weg oder einen wink mit dem Zaunpfahl um mit einem der gängigen Reverse Proxies klar zu kommen.

Was heißt das "teilweise überschneiden"? Dass die Applikationen im Container auf dem gleichen UDP/TCP Port laufen? Das ist ja erst mal egal. Wichtig ist doch auf welchen Port der Container "lauscht".

Sofern jeder Container einen eigenen externen Port hat kann dieser ja vom Reverse Proxy angesprochen werden...

ich meine damit dass man bei zwei Containern die per default auf 8443 laufen halt einfach einem einen anderen Docker Host Port zuweist.

@Paddy0293
das trifft sich gut, ich hab meine Domain auch bei netcup liegen.
Ich schau mir die Anleitung mal an.

Aber sollte man doch sicher irgendwo auch ignorieren können bzw. als trusted abstempeln können.

Sag das mal dem installierten Traefik. Laut Doku geht das. Ich bin aber scheinbar zu blöd dafür.

Ich habe jetzt dein Problem noch nicht ganz durchschaut. Ich kann dir aber als Reverse Proxy den "nginx proxy manager" ans Herz legen. Ich weiß, dass die Entwicklung da gerade stockt, aber das Ding ist wirklich gut und einfach zu administrieren.

habe mir auch schon nginx angeschaut, macht es auf Anhieb aber nicht leichter.

vielleicht ist mein Hirn aktuell noch zu verquer wegen den ganzen traefik configs.
Vielleicht geh ich in ein paar Tagen nochmal open-minded an den nginx.

 

[Der Lord]

das trifft sich gut, ich hab meine Domain auch bei netcup liegen.

ich auch. und nutze für mein Homelab eine wildcard-Subdomain (in meinem Fall *.home.example.tld). In einem Container läuft der acme.sh Client und mittels DNS-Challenge lasse ich mir automatisch ein Zertifikat erstellen/verlängern, das folgendes abdeckt:
example.tld, home.example.tld, *.home.example.tld
(example.tld habe ich nur inkludiert, weil sonst der XMPP-Server meckert , in deinem Fall also sicher unwichtig)
Durch das WIldcard-Zertifikat kann ich hier jedem Gerät nach Lust und Laune einen eigenen Hostnamen verpassen und das Zertifikat bleibt gültig.

Läuft anstandslos. Also bei Netcup-API Fragen, kennen sich hier offenbar neben mir einige aus - einfach fragen.

 

[DonConto]

vielleicht ist mein Hirn aktuell noch zu verquer wegen den ganzen traefik configs.
Vielleicht geh ich in ein paar Tagen nochmal open-minded an den nginx.

Der nginx proxy Manager ist eine docker Applikation mit eigener GUI. Also ein eigener Container.

Ich habe ähnliches wie du. Vaultwarden mit Reverse Proxy. Und dazu einige andere Services wie Gotify, Uptime Kuma, Webserver etc die über den Reverse Proxy laufen.

 

[h00bi]

Der nginx proxy Manager ist eine docker Applikation mit eigener GUI. Also ein eigener Container.

Der läuft auch schon seit gestern. Muss nur noch die Domain einbinden für die Zertifikate.

Würdest du mir bitte deine compose datei(en) zur Verfügung stellen? Ich geh jetzt einfach mal davon aus dass du compose nutzt.
Gerne auch per PN.

 

[DonConto]

Ich mache wenig mit compose. Ich starte die Container einfach mit den entsprechenden Parametern und alles weitere verwalte ich dann mit Portainer.

 

[h00bi]

verwalte ich dann mit Portainer

so, habe mich mit frischem Kopf auch nochmal nginx gemacht und verwende nun auch portainer.
Hat ansich erstmal alles geklappt was ich vor hatte.
Der nginx proxy manager ist deutlich simpler als traefik.
Besten Dank hierfür.

Was ich in Portainer aber nicht hinbekomme:

Wie kann ich /home/h00bi/video/serien/ in den "plex" container einbinden?

Unter volumes kann ich nur neue im Pfad /var/lib/docker/volumes/ anlegen lassen.
Als "driver" hab ich nur local zur Auswahl.

Ich hab das jetzt so gemacht, dass ich das Volume per docker run eingebunden habe.

docker run \
-d \
--name plex \
--volume $(echo $HOME)/video/serien:/serien \
greensheep/plex-server-docker-rpi:latest

und dann wird es in Portainer auch angezeigt.
Es würde mich aber trotzdem interessieren wie ich das in der Portainer Oberfäche machen kann.

 

[DonConto]

Das weiß ich ehrlich gesagt auch nicht.

Wenn du eine Container editierst im Portainer und dann ganz runter scrollst kannst du über den Reiter "Volumes" neue Volumes mappen. Vielleicht hast du das gesucht.
Das Volume musst du wahrscheinlich vorher anlegen über den Portainer Menübaum auf der linken Seite.

Wie gesagt, k.a., ich hatte bisher nie den Bedarf dafür...

 

[h00bi]

@DonConto
habe diesen Thread von dir gefunden:
https://www.computerbase.de/forum/threads/nginx-proxy-manager-wildcard-ssl-und-custom-dns.2058015/
Bist du zu einem anderen Anbieter umgezogen oder nutzt du doch keine Wildcard?

Läuft anstandslos. Also bei Netcup-API Fragen, kennen sich hier offenbar neben mir einige aus - einfach fragen.

Ich versuche mich grade auch an einem Wildcard Zertifikat über npm und deren implementierte Netcup API Ansteuerung. Allerdings erhalte ständig Fehler und beim versuch diese zu fixen ständig neue Fehler.

Error: Command failed: pip install certbot-dns-netcup~=1.0.0

Building wheel for cffi (setup.py): finished with status 'error'
        error: subprocess-exited-with-error

Wenn ich pip install certbot-dns-netcup~=1.0.0 auf der shell des npm containers ausführe, erhalte ich einer Fehlermeldung zu python.h

Wenn ich diese per apt-get install python3-dev fixe, erhalte ich beim nächsten Versuch die Fehlermeldung:
rustc: 1.41.0
This package requires Rust >=1.48.0.

Auch wenn ich das Image jc21/nginx-proxy-manager:2.9.18 verwende klappt das nicht.
rustc: n/a
This package requires Rust >=1.48.0.

rustc zu aktualisieren bekomme ich nicht hin.

Ich suche hier kein Lösung zu dem Problem, sondern habe eine Verständnisfrage:
Das sollte in einem populären Container Image wie jc21/nginx-proxy-manager:latest (müsste 2.9.19 entsprechen) doch eigentlich alles drin sein, oder?
Ist das nicht der Sinn eines Containers, dass das ganze Zeugs gleich mit kommt bzw. miteinander harmoniert?