Vaultwarden und das Thema HTTPS

[Archonw]

Was lautet dein local DNS Eintrag im Pihole?
Eventuell auch noch www.bit.deinedomain.de?

[VK28.01]

Ne, leider nicht:

 

List of local DNS domains

 

DomainIPAction

bit.meinedomain.de. -> 192.168.0.2

 

CNAME records nochmal bit.meinedomain.de. -> 192.168.0.2

[Archonw]

Merkwürdig. Es scheint für mich gerade so, als ob dein PC die DNS nicht übers Pihole auflösen würde.

Edited December 16, 2022 by Archonw

[VK28.01]

Diverse Male nach Vertippern geschaut. Keine Dreher…

Edited December 16, 2022 by VK28.01

[mgutt]

Was hat der PiHole denn jetzt noch damit zu tun?!

[mgutt]

Was gibt das zurück:

 

curl -sL -o /dev/null -w "%{http_code}" http://192.168.0.2/

 

curl -sL -o /dev/null -w "%{http_code}" http://bit.example.com/

 

curl -sL -o /dev/null -w "%{http_code}" https://bit.example.com/

 

Außerdem die Konsole von NPM öffnen und das ausführen:

 

curl -sS http://192.168.0.125:4743/ >/dev/null && echo "Container is reachable"

 

 

[Archonw]

41 minutes ago, mgutt said:

Was hat der PiHole denn jetzt noch damit zu tun?!

Der ist doch für die DNS Namensauflösung zuständig. Und wenn man er ja im NPM auf die Source klickt und sich daraufhin der Browser öffnet und die Domain nun geöffnet werden soll, kommt doch dann die dazugehörige IP vom Pihole. Und das scheint ja nicht zu klappen. Daher hatte ich da auf einen Fehler gehofft. Vor allem, da es ja zuvor mit www.bit.meinedomain.de geklappt hatte.

 

 

[VK28.01]

Guten Morgen!

 

8 hours ago, mgutt said:

Was gibt das zurück:

 

curl -sL -o /dev/null -w "%{http_code}" http://192.168.0.2/

200%

curl -sL -o /dev/null -w "%{http_code}" http://bit.example.com/

000%

curl -sL -o /dev/null -w "%{http_code}" https://bit.example.com/

000%

Außerdem die Konsole von NPM öffnen und das ausführen:

 

curl -sS http://192.168.0.125:4743/ >/dev/null && echo "Container is reachable"

Container is reachable

 

 

[mgutt]

20 minutes ago, VK28.01 said:

curl -sSLv http://bit.example.com/ | head -n 100

Und so? Achtung. Da werden viele Details zur Domain ausgegeben

[VK28.01]

Connected to bit.meinedomain.com (3.x.x.x) port 80 (#0)

> GET / HTTP/1.1

> Host: bit.meinedomain.com

> User-Agent: curl/7.84.0

> Accept: */*

>

* Mark bundle as not supporting multiuse

< HTTP/1.1 302 Found

< content-length: 0

< date: Sat, 17 Dec 2022 09:08:09 GMT

< location: https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com

<

* Connection #0 to host bit.meindomain.com left intact

* Clear auth, redirects to port from 80 to 443

* Issue another request to this URL: 'https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com'

*   Trying 0.0.0.0:443...

* connect to 0.0.0.0 port 443 failed: Connection refused

* Failed to connect to www.hugedomains.com port 443 after 8 ms: Connection refused

* Closing connection 1

curl: (7) Failed to connect to www.hugedomains.com port 443 after 8 ms: Connection refused

[VK28.01]

Es ist vollbracht! 🥳

Nachdem ich mich nach vielen weiteren erfolglosen Versuchen komplett in der Sackgasse wähnte, habe ich das ganze nochmals komplett neu, inkl. neuer Subdomain auf anderer Domain auf dem Reserveserver gemacht, auch erfolglos.

 

Einziger offener Punkt war, den PiHole komplett aus dem Spiel zu nehmen und es nochmals auf dem Hauptserver zu probieren. Ging sofort!! Wenn ich meine Malereien so im Nachgang betrachte, habe ich mir eine Reihe von (überflüssigen)Schleifen eingebaut, was den DNS angeht. Da das leicht willen- und kenntnisslose initiale einrichten von PiHole den gewünschten Effekt hatte, die Werbung war weg, hab ich nicht weiter ins Detail geschaut.

Ich habe das ganze dann nochmal mit sauber gemacht und siehe da, es läuft alles perfekt.

 

@Archonw&@mgutt ganz herzlichen Dank für die Hilfe und Denkanstöße! Ne Menge gelernt. Nochmals Danke!

Edited December 17, 2022 by VK28.01

[mgutt]

9 hours ago, VK28.01 said:

HTTP/1.1 302 Found

< content-length: 0

< date: Sat, 17 Dec 2022 09:08:09 GMT

< location: https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com

Häh warum wolllte der auf "hugedomains" weiterleiten?!

 

Da muss es wirklich irgendeine komische Weiterleitung in PiHole gegeben haben.

[VK28.01]

Die „Hugedomain-Nummer“ ist nach wie vor da, wenn ich den Curl mache Die Domain ist mir vollkommen unbekannt und taucht im übrigen natürlich nirgendwo im PiHole auf….

[FIetch]

Hi,

ich hänge mich mal hier rein

Ich bin mal wieder am überlegen auf Bitwarden bzw. Vaultwarden umzusteigen...

Ich bin eigentlich immer wieder an diesem SSL Thema gescheitert und würde das gerne doch nochmal versuchen.

Über das "My Server" Plugin gibt es doch ein Let´s Encrypt SSL Zertifikat.

Kann man das nicht auch leicht hier für nutzen? Anstatt extra Programme wie zB Nginx Proxy?!

[mgutt]

25 minutes ago, FIetch said:

Über das "My Server" Plugin gibt es doch ein Let´s Encrypt SSL Zertifikat.

Kann man das nicht auch leicht hier für nutzen?

Nein, weil das Zertifikat dann auf dem unRAID Server liegt und nicht in dem Vaultwarden Container. Davon abgesehen wirst du ja hoffentlich nicht die dumme Idee haben deine unRAID GUI per MyServers Adresse über das Internet verfügbar zu machen.

[Archonw]

Man kann Bitwarden auch mit einem lokalen ssl Zertifakt versehen. Die ersten Schritte zur Vorbereitung sind hier beschrieben.

 

https://github.com/dani-garcia/vaultwarden/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome

 

hier ein passendes Video dazu

 

https://www.youtube.com/watch?v=eCJA1F72izc

 

Ich habe dazu nun folgenden gemacht:

 

- per Apps Vaultwwarden installiert; den Container danach wieder gestoppt

- per ssh auf meinen Unraid Server verbunden und in den Ordner von Vaultwarden in Appdata gegangen 

- hier jetzt nach der Reihe die Befehle aus der Anleitung eingegeben.

 

1.

openssl genpkey -algorithm RSA -aes128 -out private-ca.key -outform PEM -pkeyopt rsa_keygen_bits:2048

 

hier ein muss ein Password eingegeben werden. Das später noch mal gebraucht wird.

 

2.

openssl req -x509 -new -nodes -sha256 -days 3650 -key private-ca.key -out self-signed-ca-cert.crt

 

hier wird das Password aus Schrit 1 benötigt.

Im weiteren dürfen die Felder leer bleiben. ein Punkt reicht dabei.

Bei "Common" eine eindeutige Bezeichnung z.B. Unraid-Vaultwarden, zur Wiederekennung des Zertifikats

 

3.

openssl genpkey -algorithm RSA -out bitwarden.key -outform PEM -pkeyopt rsa_keygen_bits:2048

 

4.

openssl req -new -key bitwarden.key -out bitwarden.csr

 

Wieder die Felder nicht leer lassen.

Achtung! Hier muss bei "Common Name" die IP rein, unter der Vaultwarden erreicht werden soll. Wer das per local DNS machen möchte trägt hier den DNS namen ein.

 

5.

Es muss noch eine letzte Datei erzeugt werden. Dazu 

 

nano bitwarden.ext

 

und folgendes einfügen

 

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
IP.1 = die_ip_von_vaultwarden

(wenn ein DNS anstelle von IP genutzt wird dann die letzte Zeile in    DNS.1 = eigener_DNS     ändern.)

mit Strg+O abspeichern und mit Strg+X schliessen.

 

6.

 

openssl x509 -req -in bitwarden.csr -CA self-signed-ca-cert.crt -CAkey private-ca.key -CAcreateserial -out bitwarden.crt -days 365 -sha256 -extfile bitwarden.ext

 

Jetzt wird das eigentliche Certifikat erstellt. Dieses ist dann 365 Tage gültig. Nach Ablauf von 365 Tagen müssen die oberen Schritte dann wiederholt werden und damit die beiden Dateien (bitwarden.crt und bitwarden.ext) ersetzt werden.

 

 

 

 

 

Danach muss noch ein Pfad (der wo die SSL Zertifakte hinterlegt werden) und eine Variable im Template hinzugefügt werden. Und schon kann es losgehen.

 

 

 

 

{certs="/ssl/bitwarden.crt",key="/ssl/bitwarden.key"}

 

 

Wer jetzt noch die Standardwarnung wegen des selbst erstellten Zertifikats wegbekommen möchte muss noch das Zertifkat auf den entsprechenden Endgeräten importieren. 

 

Die Datei liegt im Vaultwarden Ordner: self-signed-ca-cert.crt

Edited February 17, 2023 by Archonw

[fiR3W4LL]

On 12/29/2022 at 12:13 PM, Archonw said:

Man kann Bitwarden auch mit einem lokalen ssl Zertifakt versehen. Die ersten Schritte zur Vorbereitung sind hier beschrieben.

 

https://github.com/dani-garcia/vaultwarden/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome

 

hier ein passendes Video dazu

 

https://www.youtube.com/watch?v=eCJA1F72izc

 

Ich habe dazu nun folgenden gemacht:

 

- per Apps Vaultwwarden installiert; den Container danach wieder gestoppt

- per ssh auf meinen Unraid Server verbunden und in den Ordner von Vaultwarden in Appdata gegangen 

- hier jetzt nach der Reihe die Befehle aus der Anleitung eingegeben.

 

1.

openssl genpkey -algorithm RSA -aes128 -out private-ca.key -outform PEM -pkeyopt rsa_keygen_bits:2048

 

hier ein muss ein Password eingegeben werden. Das später noch mal gebraucht wird.

 

2.

openssl req -x509 -new -nodes -sha256 -days 3650 -key private-ca.key -out self-signed-ca-cert.crt

 

hier wird das Password aus Schrit 1 benötigt.

Im weiteren brauchen die Felder nicht ausgefüllt werden. Ich vergebe hier lediglich bei Common eine eindeutige Bezeichnung z.B. Unraid-Vaultwarden

 

3.

openssl genpkey -algorithm RSA -out bitwarden.key -outform PEM -pkeyopt rsa_keygen_bits:2048

openssl genpkey -algorithm RSA -out bitwarden.key -outform PEM -pkeyopt rsa_keygen_bits:2048

 

4.

openssl req -new -key bitwarden.key -out bitwarden.csr

 

Achtung! Hier muss bei Common Name die IP rein, unter der Vaultwarden erricht werden soll. Wer das per local DNS machen möchte trägt hier den DNS namen ein.

 

5.

Es muss noch eine letzte Datei erzeugt werden. Dazu 

 

nano bitwarden.ext

 

und folgendes einfügen

 

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
IP.1 = die_ip_von_vaultwarden

(wenn ein DNS anstelle von IP genutzt wird dann die letzte Zeile in    DNS.1 = eigener_DNS     ändern.)

mit Strg+O abspeichern und mit Strg+X schliessen.

 

 

Danach muss noch ein Pfad (der wo die SSL Zertifakte hinterlegt werden) und eine Variable im Template hinzugefügt werden. Und schon kann es losgehen.

 

 

 

 

Wer jetzt noch die Standardwarnung wegen des selbst erstellten Zertifikats wegbekommen möchte muss noch das Zertifkat auf den entsprechenden Endgeräten importieren. 

 

Die Datei liegt im Vaultwarden Ordner: self-signed-ca-cert.crt

Hi @Archonw

Besten Dank für die Anleitung.

 

Irgendwie bin ich zu dumm  aber mir erscheint nun die folgende Meldung in den Logs:

Kann somit den Container nicht starten, fehlen evtl. noch schritte in der Anleitung oder wie gesagt, es kann sein dass ich zu dumm bin

 

Besten Dank 

Freundliche Grüsse

[Archonw]

Ich werde das heute abend nochmal durch führen. Mal sehen, ob ich was entdecken kann.

[fiR3W4LL]

4 hours ago, Archonw said:

Ich werde das heute abend nochmal durch führen. Mal sehen, ob ich was entdecken kann.

Ich habe auch einiges probiert, jedoch ohne erfolg

[Archonw]

43 minutes ago, fiR3W4LL said:

Ich habe auch einiges probiert, jedoch ohne erfolg

Ich habe die  Anleitung aktualisiert.

Da hat der Punkt 6 gefehlt, und der Pfad im ersten Bild war nicht korrekt. Muss natürlich dann auf den Appdata Ordner von Vaultwarden zeigen. 

 

Sorry für die Verwirrung. Hätte doch nochmal genauer korrektur Lesen sollen.

Edited February 16, 2023 by Archonw

[fiR3W4LL]

Besten Dank für die Aktualisierung

Funktioniert weiterhin nicht  ERR_CONNECTION_REFUSED

Aber der Container startet immerhin korrekt nun

 

Edit: tls handshake with "Client-IP" failed: tls handshake eof

Edited February 16, 2023 by fiR3W4LL

[Archonw]

Rufst du Vaultwarden über IP oder DNS auf? 

[fiR3W4LL]

über die IP

[Archonw]

 

Ist das eine der Warnungen wie diese?

Hast du da auch die Möglichkeit auf "Erweitert" oder ähliches zu klicken?

[fiR3W4LL]

Nö es kommt connection refused und im Log kommt folgende Meldung:
[17-02-2023 00:02:25.503][rustls::conn][ERROR] TLS alert received: AlertMessagePayload {
    level: Fatal,
    description: CertificateUnknown,
}
[17-02-2023 00:02:25.503][rocket_http::tls::listener][WARN] tls handshake with IP failed: received fatal alert: CertificateUnknown
[17-02-2023 00:02:25.503][rustls::conn][ERROR] TLS alert received: AlertMessagePayload {

 

[17-02-2023 00:02:25.503][rocket_http::tls::listener][WARN] tls handshake with IP failed: received fatal alert: CertificateUnknown
[17-02-2023 00:02:50.423][rocket_http::tls::listener][WARN] tls handshake with IP failed: received corrupt message
[17-02-2023 00:03:42.758][rocket_http::tls::listener][WARN] tls handshake with IP failed: tls handshake eof

Edited February 16, 2023 by fiR3W4LL