On-Prem Windows 10 installation Help

I’ve searched the help and forums and have not found the answer .
Scenario: I want to have BW On-Prem installation that is only accessible from behind my firewall, but one that also allows the Android & iOS apps to update. I tried setting up as “Self signed” and Let’s Encrypt, but both would not allow the iOS app to connect as SSL. I purchased a DV cert from DigiCert for my registered domain and reran the BW install script. Once completed I checked the logs and Docker and there were no errors, but when trying to access the BW server from a browser, it couldn’t be found, using my domain URL. I assume the issue is with my DNS record not being able to find or get through my firewall even though I’ve port forwarded ports 80 and 443. I can connect to the server via IP from a computer, but it is not using SSL and IP will not work from the Mobile app because it’s not a Secure connection. I tried pointing the app to the DDNS entry for my firewall, and used VPN, but still no luck.
My perfect install would allow me to use VPN from my mobile devices to connect to the firewall rather than opening ports and allow me to sync to the server. If possible I would rather use a generated Cert from Lets Encrypt or other CA and not one from my registered Domain. Any assistance you can provide would be greatly appreciated… :grinning:

But confused here, in one instance you have said

Yet later you mention

If you want BW self hosted to be installed on prem but only be accessible in your LAN or via VPN then you should NOT have to forward any port at your firewall. Doing so expressly opens and forwards those ports from your public internet at the firewall to the BW server behind the firewall.
Now that’s perfectly fine for most use cases to be available online, but you specifically stated you’d like this to only be available behind the firewall and not opened to the greater internet.
(This also can greatly decreases your attack surface.)

The client apps are independent of the server, mobile apps should be able to update from their respective app stores.

This can be handled a few ways depending on your environment, public DNS could point to the local IP of your BW server which would only work on your local LAN or on VPN.
Or have your firewall set with some type of internal DNS server for your bitwarden.domain.com

Thanks for the reply Kent and sorry for the confusion, seems I can loose my grammatical skills after only 3 hrs of sleep.
For the security reason you mentioned, yes I would prefer to not punch a hole in my firewall to allow clients to connect to the server, but if that was the only way I could get it to work, I would simply enable and disable the ports when needed. I currently use VPN on my router to access my security system, so one more app shouldn’t be an issue and I guess that would be the preferred method of connecting to the BW server.

As for the Android and iOS apps, yes I completely understand that the apps version will update from their app store, I was referring to updating the data, not the app, again my poor choice of words. :frowning_face:

After spending a few more hours today and working with my hosting company I feel confident that the issue is with my BW installation or some setting on my laptop. My domain DNS record is resolving to my routers ip and port forwarding was enabled on it to to send port 80 & 443 to my Laptop which hosts the BW server. So regardless of trying to connect from the Intranet or Internet to the laptop which hosts the BW server, I’m unable to connect to it using my domain name it times out, but as I mentioned if I use the IP address of the server in my browser on the laptop, it connects but the connection is Not secure.

I’ve tried troubleshooting the issue by.

  1. Confirmed Docker is running without errors, ran docker ps all containers are “healthy”

  2. Checked BWdata\Logs\mssql, and did see this “Service Master Key could not be decrypted using one of its encryptions. See sys.key_encryptions for details” but I’m not sure how to find this log/reference.

  3. As noted in the “Certificates” section of the Installation guide, I bundled the Root and Intermediate certs to prevent ssl errors, but it made no difference.

Hopefully some this information will be useful in narrowing down the issue.


One more thing to add. When I initially configured the servers domain name, I used “mydomain.com” but later I noticed that the Certificate I ordered used “www” in front of my domain name. I changed the “config.yml” file and added the “www” and ran the “rebuilt” script and then “Start”. That said, I just checked the “global.override.env” variable file and noticed that it was still showing “globalSettings__baseServiceUri__vault=https://mydomain.com” as the URL, without the “www” . Could this be the issue?

No problem at all @floored.1 it can happen to the best of us, it tends to be that those of us in IT get the least sleep so I can relate to that :joy:

Bitwarden can be ran without network ports open, this would be the best from a security aspect but would require either to be on the internal LAN as the server, or have a VPN connection to the firewall or something behind this locally to your server.
This also means either connecting to the VPN whenever you need to update Bitwarden entries or sync a new client, or having an always on VPN for this to work without firewall ports forwarded.

If you feel comfortable with having Bitwarden publicly accessible then this will allow for Bitwarden clients to connect without the need for VPN, this will also allow you to automatically receive renewing SSL certs with certbot.

This support article may assist further

In reference to this do you know what the cert you are trying to use has for a valid certificate? If this was purchased from a company it should have either yourdomain.com or something like a wildcard *.yourdomain.com
The domain will need to match in order for the certificate to be used, so if it is the root domain with only yourdomain.com then only that can be used for that certificate.

The cert may also show something like:

A wildcard cert is the most versatile as this will allow you to use this for any subdomain at your FQDN *.yourdomain.com would be able to be used in as many subdomains as you wanted such as,