Vaultwarden auf Raspi nur per http nicht per https erreichbar

Piepflitze

Cadet 4th Year
Registriert
Jan. 2010
Beiträge
68
Hallo zusammen,

mein Plan ist, Vaultwarden auf einem frischen Rapi 4 zu installieren und dann aus dem Netz erreichbar zu haben, damit ich eben von überall und mit jedem Endgerät auf den Tresor zugreifen kann. Das soll natürlich möglichst sicher sein, aber alles hat ja seine Grenzen. Ich habe x Versuche nach diversen Anleitungen genommen, Reverse Proxy über Ngninx oder Traefik. Ohne bereits tief in die Details eingesteigen zu können, scheitere ich bereits direkt zu Beginn am https-Zugriff auf den Raspi.
Egal ob ich lokal per IP zugreife oder über eine freedns-subdomain, per http geht es, per https bekomme ich einen SSL-Fehler "SSL_ERROR_RX_RECORD_TOO_LONG". Ich finde nicht den Punkt, wo ich etwas falsch mache.
Das SSL-Zertifikat stammt je nach Versuch selbst erstellt mit Nginx oder automatisch bezogen von lets encrypt. Ich habe keine Ahnung mehr wo ich ansetzen soll. Bitte helft mir auf die Fährte... danke! :-)
 
funktioniert https gar nicht, also kannst du auch keine Webseite darstellen über https?
Sind Ports freigegeben?

Eventuell mal caddy testen, das kann mit einem dreizeiler automatisch https umsetzen.
 
Zuletzt bearbeitet:
Stimmt wohl, aber das ist nicht mal von den Entwicklern empfohlen.
Er sollte mal gucken, ob er mit caddy überhaupt eine https seite erreichbar machen kann:
deine-domain.com {
reverse_proxy http://backend-server:port
}

Erläuterungen:​

  • deine-domain.com: Ersetze dies mit deiner tatsächlichen Domain.
  • reverse_proxy http://backend-server:port: Dies leitet Anfragen an den angegebenen Backend-Server weiter. Ersetze backend-server:port durch die Adresse und den Port deines Zielservers (z. B. localhost:8080oder 192.168.1.100:3000).

Ich würde das einfach nutzen, um zu testen, ob er die default port 80 Caddy Seite überhaupt über https erreichen kann in seinem Setup. An einem spezifischen reverse Proxy liegt es ja scheinbar nicht, da beide nicht gehen.

:ChatGPT
 
Zuletzt bearbeitet:
@crashbandicot: Der TE schreibt: "Ich habe x Versuche nach diversen Anleitungen genommen, Reverse Proxy über Ngninx oder Traefik".
Ich frage mich, wie viele Anleitungen dabei HTTPS in Vaultwarden selbst aktivieren...

@RedPanda05: Von welcher KI hast du den Text denn generieren lassen? Könnte man wengistens kenntlich machen.
 
Ja und nein, denn:
https://www.computerbase.de/forum/threads/umgang-mit-chatgpt-llm-bots-und-ki-im-computerbase-forum.2139839/ schrieb:
Beiträge dürfen zur Unterstützung oder Ergänzung der eigenen Aussage in Auszügen KI-Content enthalten. Diese Auszüge sind jedoch eindeutig als solche zu kennzeichnen.
 
@Piepflitze sag mal, wie hast du das gemacht? „Das SSL-Zertifikat stammt je nach Versuch selbst erstellt mit Nginx“

Soweit ich weiß, kann nginx gar keine Zertifikate selbst erstellen, zumindest standardmäßig.
Ergänzung ()

@tollertyp sry ig?
 
  • Gefällt mir
Reaktionen: tollertyp
Es würde auch nicht schaden, mal zu posten, welche Anleitungen benutzt wurden, und zu erklären, warum es denn mehr als nur einer Anleitung bedurfte...
Wenn man mehrere Anleitungen nimmt, dann kann man auch schnell Dinge machen, die gegenseitig Konflikte geben, wenn man nicht alles rückgängig macht.

Und damit man sich nicht "gegenseitig" die Konfiguration zerschießt würde ich für solche Dinge wie Vaultwarden sowieso Docker auf einem raspi nehmen.
 
Und schon habt ihr mich ein wenig abgehängt.
RedPanda05 schrieb:
funktioniert https gar nicht, also kannst du auch keine Webseite darstellen über https?
Sind Ports freigegeben?
Was meinst Du mit gar nicht? Grundsätzlich im Internet, im Lan, auf dem Raspi? Ports sind nach Anleitung freigegeben. Ich komme ja quasi auf den Raspi. Nur nicht über https aufgrund des SSL_Fehlers.
crashbandicot schrieb:
Kommt der Fehler auch wenn du nicht über die Reverse Proxy zugreifst?
Verstehe ich nicht ganz. Wie ich es verstanden habe, ist der Reverse Proxy doch quasi meine Eingangstür. Wie soll ich an dem vorbei? Auf einen anderen als den weitergeleiteten Port hört doch niemand.
tollertyp schrieb:
@crashbandicot:Ich frage mich, wie viele Anleitungen dabei HTTPS in Vaultwarden selbst aktivieren...
Keine. Ich habe nicht https in Vaultwarden selbst aktiviert. Ich kann mich mangels https nicht einmal in Vaultwarden anmelden.
 
Die Frage war, ob du irgendetwas per https z.b. default nginx seite freigeben kannst?
Ergänzung ()

Ich bin eigentlich auch etwas verwirrt. Welche Ports sind im Router freigegeben, hast du eine Firewall, hast du eine statische ip oder löst du das per ddns?
 
RedPanda05 schrieb:
@Piepflitze sag mal, wie hast du das gemacht? „Das SSL-Zertifikat stammt je nach Versuch selbst erstellt mit Nginx“

Soweit ich weiß, kann nginx gar keine Zertifikate selbst erstellen, zumindest standardmäßig.
Ergänzung ()

@tollertyp sry ig?
Doch kann der Nginx Proxy Server. Hat eine Admin-Oberfläche wo man ein Zertifikat selbst erstellen kann.
tollertyp schrieb:
Es würde auch nicht schaden, mal zu posten, welche Anleitungen benutzt wurden, und zu erklären, warum es denn mehr als nur einer Anleitung bedurfte...
Wenn man mehrere Anleitungen nimmt, dann kann man auch schnell Dinge machen, die gegenseitig Konflikte geben, wenn man nicht alles rückgängig macht.

Und damit man sich nicht "gegenseitig" die Konfiguration zerschießt würde ich für solche Dinge wie Vaultwarden sowieso Docker auf einem raspi nehmen.
Das sind viele, angefangen von der auf Heise von vor 4 Jahren. Und diverse englischsprachige. Durcheinander bin ich nicht gekommen, da ich immer wieder von vorne angefangen habe, inklusive frischem Raspi-Image. Dieser Docker-Compose-Kram ist ja grundsätzlich easy. Ich vermute eben, dass an der Konfiguration des Proxys liegt. Und die aktuelle wäre diese hier:

version: "3"

services:
traefik:
container_name: traefik
hostname: traefik
image: traefik:latest
restart: unless-stopped
security_opt:
- no-new-privileges:true
ports:
- 80:80/tcp
- 443:443/tcp
environment:
TZ: Europe/Berlin
volumes:
- traefik-acme:/acme
- ./config/traefik.yml:/traefik.yml
- ./config/dynamic:/dynamic
- /etc/localtime:/etc/localtime:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
- /var/log/docker/traefik:/var/log/traefik
networks:
- traefik
labels:
# Traefik
traefik.enable: true
traefik.http.routers.traefik.entrypoints: websecure
traefik.http.routers.traefik.rule: Host(traefik.domain.tld)
traefik.http.routers.traefik.service: api@internal
traefik.http.routers.traefik.middlewares: simpleAuth@file
traefik.http.routers.traefik.tls: true
traefik.http.routers.traefik.tls.certresolver: letsencrypttls

networks:
traefik:
name: traefik

volumes:
traefik-acme:
name: traefik-acme
Ergänzung ()

Kabelanschluss mit wenig veränderlichen IP, trotzdem nutze ich eine freedns-subdomain. Sorry, in meinem Kopf hatte ich das schon geschrieben. DynDNS ist entsprechend in der Fritzbox konfiguriert. Die freedns-subdomain funktioniert grundsätzlich, aber eben mit demselben SSL-Problem als wenn ich im LAN direkt die IP des Raspis aufrufe.
Den Nginx habe ich wieder heruntergeworfen, hat ja ebenso wenig funktioniert wie Traefik. Auf die Weboberflächen von Nginx und Traefik konnte ich zugreifen, aber eben auch immer über http. Nginx hat ein customer-Zertifikat erstellt, was ich heruntergeladen und entsprechend auf dem Raspi abgelegt habe. Der Traefik hat ein Zertifikat von letsencrypt bezogen. Der Fehler ist ja auch nicht, dass kein Zertifikat vorhanden ist.

Ich probiere auch jede andere Anleitung aus. Dauert ja nur ein paar Minuten ein frisches Rapi-Image zu erstellen und von vorne anzufangen. Ich poste auch gerne alle Anleitungen, aber fremde Seiten sind ja im Forum nicht so gerne gesehen.
 
Zuletzt bearbeitet:
So, nach weiteren zwei Stunden Erfolglosigkeit habe ich jetzt den Raspi neu gemacht. Falls mich jemand auf die richtige Schiene setzen kann, wäre ich dankbar.
Ich habe mir wie gesagt diverse Anleitung durchgelesen und es klang alles sehr quick&easy. Scheint mir nicht zu gelingen. Vielleicht ist es auch nicht der beste Weg. Wenn z.B. die Lösung ein kostenpflichtiges Zertifikat ist, würde ich das auch in Kauf nehmen. Falls das hilft, ich hätte auch noch ein Webhosting bei all-inkl, vielleicht eröffnet mir das noch andere Optionen. Je länger ich lese, desto unsicherer bin ich, dass Vaultwarden/reverse-Proxy/Pi/Fritzbox/freedns ein guter Weg für mich ist. Vielleicht bin ich gerade aber auch nur genervt. Heute Abend starte ich einen frischen Versuch nach dieser Anleitung:
https://computingforgeeks.com/install-vaultwarden-password-manager-with-nginx-and-lets-encrypt/
 
Kann deinen Frust verstehen, das Problem ist, dass der Frust da ist und erst weg, wenn du es geschafft hast. Und du halt dabei nie weißt, wie nahe du am Ziel bist.

Würde auch sagen: mach es in Ruhe nochmal.

Welche Anleitung? Das ist eigentlich aus meiner Sicht sekundär, das hängt von persönlichen Präferenzen ab.

Ohne auf das einzugehen, was bislang geschrieben wird sondern eher allgemeiner Natur:
Wenn etwas nicht geht, dann am besten hierdie Frage konkret stellen zu der Anleitung, die du gerade machst.
"Geht nicht" ist keine Fehlerbeschreibung. Und "ich habe gemacht, was in der Anleitung" steht ist auch keine wirklich hilfreiche Aussage. Am besten genau sagen was gemacht wurde und was zur Fehlerbehebung schon probiert wurde.
Das ist aus mehreren Gründen sinnvoll (und gibt bestimmt noch mehr Argumente):
a) zeigt es, dass du als Fragesteller dich auch bemühst, es dir nicht egal ist, es aber deine Probleme sind, für die du gerne von anderen Hilfe möchtest
b) es ist für Leute, die helfen wollen, mitunter frustrierend, wenn sie immer wieder Dinge vorschlagen und kommt "habe ich schon probiert"
c) durch dieses Ping-Pong zieht sich auch die Lösung des Problems heraus
 
Ich kenne mich leider mit den von dir genutzten Reverse Proxys zu wenig aus, um den Fehler gerade zu finden. Normalerweise sollte es auch wirklich einfach sein: Docker Vaultwarden, dann entweder einen reverse proxy container und dessen Ports weiterleiten und eventuell config Datei oder Vaultwarden Port exposen aus docker und auf dem Host einen Reverse Proxy nehmen (caddy) und den Vaultwarden Post in https überführen.
 
Also mit Verlaub: Die Anleitung der c't war m.M.n. einfach, bei mir scheiterte es an anderen Problemen (Provider-NAT).
Ja, die Anleitung ist 4 Jahre alt und das ist doof. Da hat sich dann das Docker-Image glaube ich geändert und womöglich heißen auch einige Variablen in der Konfiguration nun anders.
 
@tollertyp : Die grundsätzlichen Vorgehensweisen bei Schilderungen im Forum sind mir bewusst. Ich saß viele Jahre auf der Helfer-Seite, ich bin mittlerweile nur sehr deutlich abgehängt. Wenn ich irgendwo auf ein Problem getroffen wäre, hätte ich es ja geschrieben. Das Endergebnis passt halt nicht. Vermutlich habe ich unterwegs unbemerkt einen Fehler gemacht. Ich fange nochmal von vorne an.
 
  • Gefällt mir
Reaktionen: tollertyp
Zurück
Oben