Vaultwarden mit Cloudflare und Nginx Proxy Manager

[ProUbuntu]

Guten Abend,

ich brauche Hilfe beim Einrichten von Vaultwarden mit DNS Challenge Cloudflare Zertifikat.
Und zwar will ich einen Raspberry Pi mit Vaultwarden ohne das Öffnen von Ports aufsetzten.

Ich habe Portainer mit Vaultwarden und Nginx Proxy Manager aufgesetzt und alle Container laufen ohne Probleme.
Auch eine Domain habe ich bei Strato registriert und die Nameserver auf Cloudflare umgestellt.
Bei Cloudflare habe ich die Domain registriert, als A Record habe ich bei Cloudflare die Ip Adresse des Raspberry Pis (192.168.0.147) angegeben und anschließend einen Api Key für den Nginx Proxy Manager erstellt.
Des Weiteren habe ich im Nginx Proxy Manager das SSL Zertifikat via DNS Challenge und dem generierten Cloudflare Api Key erstellt.
Anschließend habe ich einen neuen Proxy Host erstellt, mit der Container Ip von Vaultwarden und dem SSL Zertifikat das ich gerade erstellt habe.

Problem: Wenn ich meine Domain aufrufe, bekomme ich folgenden Fehler:

Not Found​

The requested URL was not found on this server.

Woran kann das liegen? Ist das überhaupt möglich, wie ich das mir vorgestellt habe?

 

[redjack1000]

als A Record habe ich bei Cloudflare die Ip Adresse des Raspberry Pis (192.168.0.147)

Das kann nicht funktionieren, da Router IP-Adressen aus privaten Netzen ignorieren.

https://de.wikipedia.org/wiki/Private_IP-Adresse

Hast Du da noch ein VPN zwischen? Oder etwas anderes?

Cu
redjack

 

[Zerstoerer]

Falls du noch keine weitere Möglichkeit geschaffen hast, eine Netzwerkverbindung von außen auf deinen Raspberry Pi aufzubauen, und die IP "192.168.0.147" tatsächlich nur die private Adresse des Pis ist, dann kann das natürlich nicht funktionieren, da hier entweder eine Portfreigabe oder ein Tunnel fehlt, wie @redjack1000 schon gesagt hat.

Da du bereits Kunde von Cloudflare bist, lohnt es sich hier vielleicht, die Lösung "Cloudflare Tunnel" auf dem Pi zu nutzen, damit dieser eine direkte Verbindung zum Cloudflare Netzwerk aufbauen kann, und externe Nutzer auf deinen Vaultwarden-Dienst zugreifen können.

 

[PonyXplosion]

Ich meine das nicht böse, aber wenn du versuchst das Ganze über eine lokale IP-Adresse umzusetzen, wird dein Fachwissen faktisch nicht vorhanden sein.
Ich gehe auch stark davon aus, du hast den Raspi mit einem HowTo im Blindflug eingerichtet und das Ding ist - da du den Raspi ja aus dem WAN/Internet erreichbar machen willst - weder Grundabgesichert noch Grundgehärtet.

Wer dazu befähigt ist, würde so eine Frage nicht stellen.

Daher: Sein lassen und das Ding nicht aus dem WAN erreichbar machen und ein bezahltes Bitwarden Abo abschließen.

 

[ProUbuntu]

Ich habe auch Möglichkeiten gesehen, die dies mit Openssl nutzen.
Frage:
Ist es nicht möglich einfach ein Zertifikat von Cloudflare mit einer Länge von 15 Jahre zu generieren und dies dann zu nutzen?

 

[redjack1000]

SSL-/TLS-Zertifikate dürfen bereits seit September 2020 nur noch maximal für 1 Jahr (exakt jedoch 397 Tage, also 13 Monate) gültig sein.

Cu
redjack

 

[ProUbuntu]

Was genau spricht dagegen das ganze mit Openssl zu nutzen?
Wenn ich mir ein Bash Skript schreibe, das mir Jedes Jahr ein neues Zertifikat generiert.

 

[redjack1000]

Da spricht nichts gegen. Hilft der aber nicht, bei der nicht gewollten Portfreigabe.

Cu
redjack

 

[c[A]rm[A]]

Wenn ich mir ein Bash Skript schreibe, das mir Jedes Jahr ein neues Zertifikat generiert.

Deswegen Lets Encrypt. Aber wie schon genannt bringt dich das alles nicht weiter. Wenn du von außen zugreifen willst muss ein Port geöffnet werden.

Für das öffentliche Zertifikat müsste die IP des Servers angegeben sein. Das wäre in deinem Fall die IP des Internet Service Providers. Da die aber selten gleich bleibt, kann man da eine Domain nutzen die man dann mit der aktuellen IP versorgt. Jene Domain gibt man dann statt der IP für das Cert an.

Wenn es dir nur um intern geht und den Netzwerkdatenverkehr im Wlan lieber verschlüsselt hast reicht auch OpenSSL/Selfcert.

 

[Iqra]

Für ein Zertifikat braucht man keine IP.
Naja, oder sollte nicht. Ist komplett unsicher.

Die Meldung im OP deutet da schon drauf hin. CF kann ganz offensichtlich einen Host an 192.168.0.147 erreichen. Aber es ist wohl davon auszugehen, daß das nicht der Raspberry des TO ist. Auch ein Zertifikat mit der genannten IP-Adresse darin würde daran nichts ändern.

Zertifikate: CN=egal, SAN=FQDN des Hosts, maximale Laufzeit wie schon erwähnt 1 Jahr plus ein bißchen Kulanz (die sollte man aber nicht aktiv ausnutzen => exakt 1 Jahr Laufzeit macht auch die Verwaltung einfacher).