Bitwarden auf der Synology (Docker)

[adahmen]

Ich habe auch das Script nochmal laufen lassen und die Dateien vorher im Zielverzeichnis "gelöscht" (also weggesichert). Danach waren 3 Dateien wieder da.
Ich sehe auch, dass das neue Zertifikat gezogen wird (Ablaufdatum ist neuer). Trotzdem das gleiche Problem.

 

[geimist]

Ich habe mich mit dem Problem jetzt noch nicht beschäftigt, aber ich würde auf jeden Fall mal die Datei acme.sh in deinem Arbeitsverzeichnis löschen / umbenennen, damit sie neu geladen wird. Ich habe gerade gesehen, dass ich auch eine noch eine ältere Version habe.

PS: Auf dem veralteten Macbook meiner Frau haben auch alle entsprechenden Seiten ein Zertifikatsproblem (Chrome & Safari). Keine Ahnung, wie das behoben wird.

 

[adahmen]

Hhmmmm, wo soll die Datei sein?
Die Zugriffsprobleme auf meine Bitwarden-Domain habe ich nicht nur vom Macbook, sondern auch vom IPhone oder Ipad.
Habe es gerade vom Windows-Rechner meiner Frau probiert (Chrome) und siehe da -- da habe ich keine Fehlermeldung.
Ist dann wohl ein Client-Problem, oder?

 

[adahmen]

Hier das Zertifikat, welches von der Webstation geliefert wird (über Port 443):





Und hier das Zertifikat, welches Bitwarden (über einen anderen Port konfiguriert) ausliefert:



Client ist ein Macbook mit aktuellem OS sowie aktuellem Chrome.

Wichtig wäre noch, dass ich die Originalversion von Bitwarden nutze. Hier läuft ein NGINX als Web-Server.


Im NGINX-Log finde ich folgende Fehlermeldungen (scheinbar bei jedem Zugriff):
2021/10/02 12:00:24 [error] 50#50: OCSP_basic_verify() failed (SSL: error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found) while requesting certificate status, responder: r3.o.lencr.org, peer: 23.xx.xx.xx:80, certificate: "/etc/ssl/www.........../certificate.crt"

Also liegt es wohl an der certificate.crt (so meine Deutung der Fehlermeldung).

Im Verzeichnis (von welchem die Dateien kopiert werden) auf der Synology sieht es wie folgt aus:

-r-------- 1 root root 1845 Oct 2 09:49 cert.pem
-r-------- 1 root root 3750 Oct 2 09:49 chain.pem
-r-------- 1 root root 1569 Oct 2 09:49 ECC-cert.pem
-r-------- 1 root root 3750 Oct 2 09:49 ECC-chain.pem
-r-------- 1 root root 5321 Oct 2 09:49 ECC-fullchain.pem
-r-------- 1 root root 241 Oct 2 09:49 ECC-privkey.pem
-r-------- 1 root root 5597 Oct 2 09:49 fullchain.pem
-r-------- 1 root root 1704 Oct 2 09:49 privkey.pem
-r-------- 1 root root 208 Oct 2 09:49 renew.json
-r-------- 1 root root 1845 Oct 2 09:49 RSA-cert.pem
-r-------- 1 root root 3750 Oct 2 09:49 RSA-chain.pem
-r-------- 1 root root 5597 Oct 2 09:49 RSA-fullchain.pem
-r-------- 1 root root 1704 Oct 2 09:49 RSA-privkey.pem

Kopiert wird die cert.pem. Es gibt aber auch noch eine ECC-cert.pem und eine RSA-cert.pem.

Kann es daran liegen?
Und wieso läuft es auf einem Windows-Client ohne Fehler?

 

[haydibe]

Im NGINX-Log finde ich folgende Fehlermeldungen (scheinbar bei jedem Zugriff):
2021/10/02 12:00:24 [error] 50#50: OCSP_basic_verify() failed (SSL: error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found) while requesting certificate status, responder: r3.o.lencr.org, peer: 23.xx.xx.xx:80, certificate: "/etc/ssl/www.........../certificate.crt"

Sowohl der Server, als auch der Client MÜSSEN mir den Kreuzsignierten-Zertifikaten umgehen können. Hier ist klar erkennbar, dass Bitwarden das nicht kann - als Ursachen komm, kommt hier nach wie vor veraltet OpenSSL Bibliotheken oder veraltete cacerts im OS in Frage. Schau mal, ob es eine neue Bitwarden Version gibt.

Viele Browser sind in der Lage mit den beiden Zertifikatsketten, die neue ein LE-zertifikat haben, umzugehen - dem Chrome reicht bspw. das eine von beiden Ketten Validate ist. Andere Browser können hier empfindlicher sein.

 

[geimist]

wo soll die Datei sein?

Sorry, ich dachte, du nutzt das Skript für die Wildcardzertifikate. Dort wird die entsprechende Datei genutzt.
Mein Fehler ????

 

[adahmen]

Danke für die Hilfe - aber ich habe auch schon die neueste Version von Bitwarden installiert - leider ohne Erfolg :-(

Wenn es ein Problem bei Bitwarden gibt, sollte ich sicherlich nicht der Einzige sein ... aber leider finde ich auch keine weiteren Hinweise auf gleiche Fehler bei anderen Usern.

Kann es nicht an den kopierten Dateien liegen?
Kopiert werden ja die

privkey.pem als private.key
cert.pem als ca.crt
chain.pem als certificate.crt

 

[adahmen]

Ich finde Hinweise, dass man nicht die chain.pem nehmen sollte, sondern die fullchain.pem
Siehe hier: https://apple.stackexchange.com/que...ed-even-though-the-certificate-is-still-activ

Könnte das das Problem lösen?

Welche Dateien nimmt der interne Web-Server der Synology?

 

[haydibe]

fullchain.pem = cert.pem + chain.pem

Unterstützt der Services (bei dir Bitwarden), sowohl die cert.pem (=Öffentlicher Teil des Zertifikats)) + chain.pem (=Öffentlicher Teil der Zertifikate ALLER intermediate CA's), dann kann man das bedenkenlos verwenden. Einige Services unterstützen nur ein Zertifikat, da muss man dann die fullchain.pem verwenden. Die cert.pem, chain.pem oder fullchain.pem werden dem Browser durch den Service zugesandt, so dass er anhand dieser die Zertifikatskette überprüfen kann.

 

[adahmen]

Nur zur Sicherheit: Soll ich dann einfach anstelle der chain.pem die fullchain.pem nehmen und als certificate.crt kopieren?
Ist das nicht genau die Zeile, die im Script auskommentiert ist?

Ich meine ich hätte es probiert und NGINX ist nicht mehr gestartet (bzw. direkt nach dem Start „abgeraucht“).

 

[haydibe]

Wozu hast Du das denn vor? Entweder unterstützt es chain.pem oder nicht. Da es es das bisher verwendet wird, warum willst Du dann etwas verändern und dann am Ende einen gleichwertigen oder nicht funktionierenden Zustand herzustellen? Ohne die nginx.conf zu kennen, in der die Zertifikatseinbindung konfiguriert wird, würde ich da gar nichts ändern.

 

[adahmen]

Also, erstmal Danke für die Hilfe

Na ja - am Ende möchte ich nur eine lauffähige Konfiguration, so dass ich per Internet auf Bitwarden zugreifen kann. Bitwarden mag nur https-Verbindungen und insofern brauche ich eine Konfiguration, so dass meine Devices zugreifen können (was aktuell aufgrund der Zertifikats-Fehlers nicht geht).

Hier die Konfiguration des NGINX (an dieser habe ich nach der Installation per Install-Script nichts geändert:

#######################################################################
# WARNING: This file is generated. Do not make changes to this file.  #
# They will be overwritten on update. You can manage various settings #
# used in this file from the ./bwdata/config.yml file for your        #
# installation.                                                       #
#######################################################################

server {
  listen 8080 default_server;
  listen [::]:8080 default_server;
  server_name www.meinedomain.org;

  return 301 https://www.meinedomain.org:444$request_uri;
}

server {
  listen 8443 ssl http2;
  listen [::]:8443 ssl http2;
  server_name www.meinedomain.org;

  ssl_certificate /etc/ssl/www.meinedomain.org/certificate.crt;
  ssl_certificate_key /etc/ssl/www.meinedomain.org/private.key;
  ssl_session_timeout 30m;
  ssl_session_cache shared:SSL:20m;
  ssl_session_tickets off;

  ssl_protocols TLSv1.2;
  ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256";
  # Enables server-side protection from BEAST attacks
  ssl_prefer_server_ciphers on;

  # OCSP Stapling ---
  # Fetch OCSP records from URL in ssl_certificate and cache them
  ssl_stapling on;
  ssl_stapling_verify on;

  # Verify chain of trust of OCSP response using Root CA and Intermediate certs
  ssl_trusted_certificate /etc/ssl/www.meinedomain.org/ca.crt;
  resolver 1.1.1.1 1.0.0.1 9.9.9.9 149.112.112.112 valid=300s;

  include /etc/nginx/security-headers-ssl.conf;
  include /etc/nginx/security-headers.conf;

  location / {
    proxy_pass http://web:5000/;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com; child-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-src 'self' https://*.duosecurity.com https://*.duofederal.com; connect-src 'self' wss://www.sualdali.org https://api.pwnedpasswords.com https://twofactorauth.org; object-src 'self' blob:;";
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Robots-Tag "noindex, nofollow";
  }

  location /alive {
    return 200 'alive';
    add_header Content-Type text/plain;
  }

  location = /app-id.json {
    proxy_pass http://web:5000/app-id.json;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    proxy_hide_header Content-Type;
    add_header Content-Type $fido_content_type;
  }

  location = /duo-connector.html {
    proxy_pass http://web:5000/duo-connector.html;
  }

  location = /u2f-connector.html {
    proxy_pass http://web:5000/u2f-connector.html;
  }

  location = /webauthn-connector.html {
    proxy_pass http://web:5000/webauthn-connector.html;
  }

  location = /webauthn-fallback-connector.html {
    proxy_pass http://web:5000/webauthn-fallback-connector.html;
  }

  location = /sso-connector.html {
    proxy_pass http://web:5000/sso-connector.html;
  }


  location /attachments/ {
    proxy_pass http://attachments:5000/;
  }

  location /api/ {
    proxy_pass http://api:5000/;
  }

  location /icons/ {
    proxy_pass http://icons:5000/;
  }

  location /notifications/ {
    proxy_pass http://notifications:5000/;
  }

  location /notifications/hub {
    proxy_pass http://notifications:5000/hub;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
  }

  location /events/ {
    proxy_pass http://events:5000/;
  }

  location /sso {
    proxy_pass http://sso:5000;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    add_header X-Frame-Options SAMEORIGIN;
  }

  location /identity {
    proxy_pass http://identity:5000;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    add_header X-Frame-Options SAMEORIGIN;
  }

  location /admin {
    proxy_pass http://admin:5000;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    add_header X-Frame-Options SAMEORIGIN;
  }

  location /portal {
    proxy_pass http://portal:5000;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    add_header X-Frame-Options SAMEORIGIN;
  }
}

 

[adahmen]

Ich habe nochmal ein wenig gelesen und die Lösung gefunden
Das Script muss angepasst werden und anstelle der cert.pem kopiere ich nun die fullchain.pem und nutze diese dann als certificate.crt im nginx.
Damit geht der Zugriff wieder ohne Fehlermeldung.

Danke für die Fragen und damit auch die Unterstützung.

 

[haydibe]

Ich hab gerade mal in die nginx doku geschaut: http://nginx.org/en/docs/http/configuring_https_servers.html

Es gibt bei nginx gar keine Möglichkeit cert + chain separat zu konfigurieren. Der Weg mit Fullchain.pem ist der absolut richtig. Stellt sich nur die Frage warum das vorher funktioniert hat, da die chain.pem vorher wirkungslos im Dateisystem rumlag aber gar nicht hätte verwendet werden können....

Ich bin am Anfang davon ausgegangen, dass nginx auch eine direktive für die chain.pem hat - und das man die nginx configuration gar nicht manuell anpassen kann. Um so besser das man es kann.

 

[tritor100]

Ich hatte dafür schon vor längerem ein Gemeinsamen Ordner "Docker" erstellt. Dort dann einen Apps Ordner. In dem gibts dann Verzeichnisse für jeden Docker App.

Im großen und ganzen habe ich bitwarden jetzt am laufen. Allerdings bekomme ich es nicht mit certbot (LetsEncrypt) ans laufen. Grund ist mir klar; die Synology hat bereits einen Webserver mit Port 80 am laufen, denn auch sie holt sich schon von LetsEncrypt Zertifikate.
Aber so kann ich keinen zweiten certbot ans laufen bekommen? Port 80 ist ja soweit ich weiss ein MUSS für Letsencrypt.

Bliebe noch das importieren des vorhanden Letsencrypt Certs, aber das ist nicht so genial weil man das dann immer wieder machen muss... Jemand ne Idee?

Hi,

Ich habe auch mehrere Webservices am Laufen und es mittels Nginx Proxy Manager (https://nginxproxymanager.com/) gelöst.
Lauft auf einem kleinen Linux Rechner, bei mir ist es ein Intel Nuc und die einzelnen Services werden perfekt geroutet.

ist halt ein zusätzlicher kleiner Rechner oder RaPi.

 

[Kachelkaiser]

Hallo,

hat noch jemand das Problem, dass in den Android Apps die Website Icons nicht angezeigt werden? Im Tool, im Web-Client und in den FF-Extensions sind sie da.

 

[update-freak]

ja, das Problem habe ich derzeit auch wieder.

 

[Kachelkaiser]

Wieder? Habe das Problem das erste Mal. Wie konntest du es bisher lösen?

 

[update-freak]

Habe nochmal nachgeschaut, da ich es auch nicht mehr genau wusste. Ich hatte damals geschrieben, dass es einfach so wieder ging (https://www.synology-forum.de/threads/bitwarden-auf-der-synology-docker.90435/page-10#post-916268).
Des Weiteren habe ich in meinen Aufzeichnungen den Hinweis für Pi-Hole entdeckt (Also wenn du Pi-Hole hast, wäre das evtl ein Lösungsansatz):
Settings > DNS > interface listening behavior > Listen on all interfaces, permit all origins

 

[Kachelkaiser]

Ok dann warte ich mal ab. Pihole habe ich laufen aber genau in dem Setting. Auch wenn ich rein über Mobilfunk gehe, habe ich die Icons nicht. Da sollte ja dann pihole außen vor sein.