Server: Admin portal uses http:// when behind https:// proxy

[stevenhrabok]

Similar to https://github.com/bitwarden/core/issues/248
Currently if you go to https://bw.domain.com/admin it redirects to http://bw.domain.com/admin/login?returnUrl=%2Fadmin
When behind an reverse proxy with "https only" can the proto be set to https?
This also shows http:// in the email sent instead of https://

[kspearrin]

For now as a workaround, just navigate directly to https://bw.domain.com/admin/login so no redirect occurs.

[stevenhrabok]

That works, thanks!

[kspearrin]

Should be fixed in next release.

[kspearrin]

Actually, nevermind. Wrong issue.

[Mart124]

@stevenhrabok certainly you did not generate a certificate during Bitwarden installation ?
Perhaps that generating at least a self-signed certificate, so that Bitwarden will know it runs over HTTPS, will solve the issue. Furthermore, your proxy will discuss with Bitwarden over HTTPS 👍
You could also redirect 80 to 443 at your proxy level.

[stevenhrabok]

@Mart124 That is correct. I'm using Synology DSM with a Proxy from 443 to the internal HTTP port.
I do not use port 80 since it's Synology only offers proxy not redirect and I wanted to avoid manually modifying the config which could be lost when updates occur for Synology. Ideally though when specifying that bitwarden is behind a proxy with https we shouldn't depend on the redirect, this was discussed before for the main bitwarden email urls in this ticket https://github.com/bitwarden/core/issues/248
The same should apply.

[kspearrin]

This happens because the internal URL for the portal is seen through the proxy as http:// . When ASP.NET does the unauthorized redirect is maintains the current protocol. The fix will be to either fix forwarded proxy headers or figure out a way to always redirect as https on forbidden requests.

[kspearrin]

https://github.com/bitwarden/core/commit/9cf036227e7f10c2f72c447b440deab0591a8592 might fix it, but needs to be tested.

[kspearrin]

@stevenhrabok Are you forwarding proper proto headers through your proxy?

[stevenhrabok]

Hi @kspearrin, Synology looks to be forwarding the X-Forwarded-Proto header so I think that should work.

    location / {
        proxy_set_header        Host                $http_host;
        proxy_set_header        X-Real-IP           $remote_addr;
        proxy_set_header        X-Forwarded-For     $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto   $scheme;
        proxy_intercept_errors  on;
        proxy_http_version      1.1;

        proxy_pass http://localhost:8123;

[D4rkiii]

Hey guys, i am running into the same issue today after installing a fresh new version of bitwarden on my synology ds 916+. I am running bitwarden under https through synology lets encrypt and route them via a synology reverse proxy to my internal mapped ports (http). If i am trying to call the admin page i am getting redirected to the http site.

[stevenhrabok]

Hi @D4rkiii, I believe this issue is still outstanding. you can work around it using the method posted by @kspearrin:

For now as a workaround, just navigate directly to https://bw.domain.com/admin/login so no redirect occurs.

There was mention of a fix but I don't believe the issue was resolved.

[c4539]

You probably could set an STS header in your Apache config:

Header always set Strict-Transport-Security "max-age=15768000; preload"

This does not fix the issue at its root, however, it's certainly a good idea to use STS anyway.

[winkler-winsen]

For now as a workaround, just navigate directly to https://bw.domain.com/admin/login so no redirect occurs.

Thanks. Works fine for me behind my reverse proxy (Synology DSM)

[arrmo]

FYI, workaround also verified here - any fix coming though, just to avoid the (minor) issue?

Thanks!

[LiaraAlis]

This is very annoying. I don't understand why the setting globalSettings__baseServiceUri__adminin the global.override.env isn't used for redirection?

[winkler-winsen]

This is very annoying. I don't understand why the setting globalSettings__baseServiceUri__adminin the global.override.env isn't used for redirection?

Sure. I changed every 'http' to 'https' in bwdata/env/global.override.env, but 'https://FQDN/admin/' still redirects to 'http://FQDN/admin/login?returnUrl=%2Fadmin'. (https --> http).

I didn't find the place where the redirect comes from. Searched server and web repos. Any Ideas?

Running docker version on Synology DS918+

[winkler-winsen]

What about this to fix the protocol change on redirect/rewrite when running plain HTTP Bitwarden (without own SSL capabilities) server after HTTPS/SSL reverse proxy?

1. Add an new option in 'config.yml': something like 'behindsslproxy: true'
2. Catch this value to handle nginx redirects/rewrites in created configs

This catches all users running own SSL reverse proxy.

[Mart124]

I don't understand why you don't simply install Bitwarden with a self signed certificate.
You'll be httpS all the way, from your client, through your SSL reverse proxy (with your own proper certificate), up to Bitwarden itself.
You won't face httpS to http redirection anymore...

# ./bitwarden.sh install
 _     _ _                         _            
| |__ (_) |___      ____ _ _ __ __| | ___ _ __  
| '_ \| | __\ \ /\ / / _` | '__/ _` |/ _ \ '_ \ 
| |_) | | |_ \ V  V / (_| | | | (_| |  __/ | | |
|_.__/|_|\__| \_/\_/ \__,_|_|  \__,_|\___|_| |_|

Open source password management solutions
Copyright 2015-2020, 8bit Solutions LLC
https://bitwarden.com, https://github.com/bitwarden

===================================================

Docker version 18.09.1, build 4c52b90
docker-compose version 1.21.0, build unknown

(!) Enter the domain name for your Bitwarden instance (ex. bitwarden.example.com): bitwarden.mydom.com

(!) Do you want to use Let's Encrypt to generate a free SSL certificate? (y/n): n

1.34.0: Pulling from bitwarden/setup
Digest: sha256:e529c155e033bf3dbfb9f0a4e9c1b69eafd9becd3eba406d868173f431c01bca
Status: Image is up to date for bitwarden/setup:1.34.0

(!) Enter your installation id (get at https://bitwarden.com/host): ...

(!) Enter your installation key: ...

(!) Do you have a SSL certificate to use? (y/n): n

(!) Do you want to generate a self-signed SSL certificate? (y/n): y

Generating self signed SSL certificate.
Generating a RSA private key
........................++++
............................................................++++
writing new private key to '/bitwarden/ssl/self/bitwarden.mydom.com/private.key'
-----
Generating key for IdentityServer.
Generating a RSA private key
.....................................++++
.......................++++
writing new private key to 'identity.key'
-----

(...)

[winkler-winsen]

Hi @Mart124,

thanks for reply. I thought the same you do before an wondered why not using Bitwardens integrated SSL/cert management.

@D4rkiii , @stevenhrabok an me (for example) are using Docker on Synology DSM. Reverse proxy on Synology DSM is called "Application Portal".

1. Reverse proxy on Synology DSM does certificate management itself.
   1.1 Cert management cannot be deactivated in DSM.
   1.2 Once you select protocol HTTPS, DSM makes use of the standard cert. (changeable)
   1.3 You cannot select no certificate, after creation reverse proxy rule for HTTPS.

2. Tested docker installation with 'Do you want to use Let's Encrypt to generate a free SSL certificate? (y/n): y', following error comes up showing ACME/cert bot is unable to register
   Digest: sha256:568b8ebd95641a365a433da4437460e69fb279f6c9a159321988d413c6cde0ba Status: Downloaded newer image for certbot/certbot:latest docker: Error response from daemon: driver failed programming external connectivity on endpoint certbot (99d354dc58db7d7714dbb4396deab98263919c29189101df7a6cb886aebc9f84): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use.

3. Threads from Bitwarden community forums which seems to be related to this issue:
   3.1 https://community.bitwarden.com/t/admin-login-self-hosted/4142
   3.2 https://community.bitwarden.com/t/on-premise-hosting-synology-android-app-connection-error/3059
   3.3. https://community.bitwarden.com/t/bitwarden-on-premise-docker-behind-haproxy-help-needed/8759

Hope you to explain the situation for Synology Docker users.

CU!Lars

[Mart124]

Hi @winkler-winsen, read and look carefully at my example above, I talk about installing Bitwarden with a self signed certificate, not with Let's Encrypt certificate !
Once done, your Synology reverse proxy (or whatever reverse proxy, depending what you are working with) will then communicate with Bitwarden over HTTPS thanks to this self signed certificate, and with clients (you) over HTTPS thanks to its standard / Let's Encrypt / CA signed... certificate.

[winkler-winsen]

Thanks @Mart124

Didn't read this. I'll give it a try next days.

[winkler-winsen]

Thank @Mart124 it really works.

I've tested this on Synology DSM 6.2 with LE cert.

It it possible to create an Help/FAQ article or make an section on Installing and deploying for this work around?

Are Help/FAQ available on GitHub so I can propose this work around or do you write these articles yourselfs?

CU!Lars

[Mart124]

A modification has been made to encourage generating a self-signed certificate during the install process.

[winkler-winsen]

Hi @Mart124 Good Idea.

Can I encourage you to put an advice on https://bitwarden.com/help/article/install-on-premise/ or create a extra Help/FAQ article about this issue when using Docker container behind own SSL proxy. Maybe with a intro word for Synology DSM users. This can help to find the article when searching Help/FAQ section with word synology.