nachdem ich es geschafft hatte mir ein SSL-Zertifikat für meine Heimnetz-Services zu erstellen, fiel mir auf, dass diese dann unter der URL aus dem Internet für alle erreichbar sind. Klar kann ich den Zugriff in Nginx Proxy Manager einschränken, aber kein Zugang um Internet wäre mir lieber.
Jedoch nutze ich den Nginx Proxy Manager, der das noch immer nicht nativ unterstützt und ich deshalb das Skript oder den Container von acme.sh nutzen muss.
Aber wie erstelle ich mir jetzt ein Zertifikat, dass ich dann in Nginx Proxy Manager laden muss?
Jetzt meine Fragen:
A. Sind das die richtigen Befehle und werden damit auch wildcard-Zertifikate erstellt? Möchte nachher URLs im Heimnetz wie Service.meine.domain.de erstellen.
B. Das Skript erstellt alle 60 Tage per cron ein neues Zertifikat. Kann ich das irgendwie automatisch in meinen Docker Nginx Proxy Manager Container laden oder soll ich den acme.sh Container nutzen?
C. Muss ich für den Docker host die Ports 80 und 443 freigeben?
So ganz erschließt sich mir deine Argumentation nicht. Wenn du gar keinen Zugang aus dem Internet gewähren willst, kannst du die Ports TCP 80/443 doch nach der Erstellung der Zertifikate einfach wieder schließen. Musst die dann nur alle 90 Tage zur Erneuerung der Zertifikate kurz wieder öffnen.
So ganz erschließt sich mir deine Argumentation nicht. Wenn du gar keinen Zugang aus dem Internet gewähren willst, kannst du die Ports TCP 80/443 doch nach der Erstellung der Zertifikate einfach wieder schließen. Musst die dann nur alle 90 Tage zur Erneuerung der Zertifikate kurz wieder öffnen.
So habe ich es in der aktuellen Zoraxy-Version auch machen müssen, da dort diesmal die DNS-Challange einfach nicht klappen wollte. Diese hatte vor 90 Tagen geklappt. Erging das noch jemand so?
Auf DNS Challenege umstellen ist schon das richtige Vorgehen.
Du erzeugst ein Zertifikat für `meine.domain.de` und `www.meine.domain.de`. Wenn du ein Wildcard Zertifikat erzeugen möchtest, solltest du `*.meine.domain.de` angeben, zumindest würde ich mir vorstellen, dass auch acme.sh das so erwartet.
Natürlich. Die saubere Lösung bezüglich Container wäre bei den Zertifikaten (key und cert) mit einem mount zu arbeiten.
Wenn cert und key in `/path/to/certs` landen, dann mountest du `/path/to/certs` in deinen Container.
Dann kannst du die Files problemlos über das Host-System austauschen und deinen Container solltest du per signaling informieren können.
Ich weiß allerdings nicht genau, wie dieser Unfall namens Nginx Proxy Manager arbeitet. Vielleicht möchtest du ja stattdessen eine vernünftige Software einsetzen z.B. direkt nginx ohne die TEMU Stützräder..
Die DNS Challenge erfordert, dass acme.sh eine Verbindung zu LE und zu deinem DNS Anbieter öffnen kann. Es muss aber keinen Webserver zur Verfügung stellen.
Ob du 80 bzw. 443 auf deinem Webserver/ Reverse Proxy freigeben muss, musst du wissen. Mutmaßlich willst du das wohl schon.
Ich habe jetzt hier nicht alles gelesen, aber ich nutze acme.sh als Docker-Container. Das hat auch einen Deploy-Hook für nginx. Einmal eingerichtet läuft es und man muss sich um nichts mehr kümmern.
Ich nutze es mit netcup als DNS-Provider für meine Domain und deploye zu zweit Synology-NASe.
Wichtig ist, das der DNS-Provider eine von acme.sh unterstützte DNS-API hat (DNS-Challenge) und die Verteilziele einen von acme.sh unterstützten Deploy-Hook. Welche das sind, findet man hier in den Verzeichnissen dnsapi und deploy.
Ports müssen da eingehend keine offen sein, ist auch egal, wo der Container läuft, es müssen aber alle Ziele erreichbar sein.