Wiki update: Setting up TLS #562

Closed
opened 2026-02-04 21:33:43 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @Dubz on GitHub (Jan 13, 2020).

Unless I overlooked them, there aren't any notes specifying these key points when configuring SSL for containers.

  • Certificates must be in RSA format. If they aren't, it will complain it could not parse the environment variables and fail to start. I spent a lot of time trying to use an ECDSA key not realizing this. Switched to RSA and things started working (after cleaning up other debugging steps I took)
  • Use the environment variable ROCKET_PORT to change the system to listen on 443 if necessary. I had to do this for it to run on Google Cloud Platform (GCP). You could probably also just port forward 443 to 80 if you'd like, but this seems to be a more ideal solution, at least for me. You can always change the port to something completely different as well if desired (ex. 8443).
  • If you plan on using Cloudflare in front of your install, I highly recommend using the Full (Strict) SSL/TLS option if possible. This ensures the highest level of security (meaning your server has a valid signed certificate being used).

To use Cloudflare with minimal hassle and not having to fight with LetsEncrypt:

  1. Generate an origin certificate if desired, it's free for all plans on Cloudflare
  2. Install the certs to your container storage somewhere
  3. Use ROCKET_TLS to point to both files
  4. Use ROCKET_PORT to change the default port to 443
  5. Switch Full (Strict) SSL/TLS on for the domain on Cloudflare

Note the longest period a generated origin cert can be set valid for is 15 years. Additionally, these certs are only trusted by Cloudflare's origin servers (hence why it's signed by them). The general public's browsers will still freak out. There is a possibility the cert will be terminated earlier than 15 years at Cloudflare's discretion, and you would need to update your cert again if/when it expires or gets revoked. This is just a matter of signing in to your control panel, clicking a few things, copying the text, and pasting it over the files on your server, then reloading it. Sure, not automated like LE, but considering the time it takes in comparison, it's not that bad. You can always regenerate new certs ahead of time as well, to extend the final expiration date.

I'm not expecting all of this to be added to the wiki. I'm just dropping it here in case anyone else is having issues and can't figure it out. Might save them some time.

Originally created by @Dubz on GitHub (Jan 13, 2020). Unless I overlooked them, there aren't any notes specifying these key points when configuring SSL for containers. - Certificates must be in RSA format. If they aren't, it will complain it could not parse the environment variables and fail to start. I spent a lot of time trying to use an ECDSA key not realizing this. Switched to RSA and things started working (after cleaning up other debugging steps I took) - Use the environment variable `ROCKET_PORT` to change the system to listen on 443 if necessary. I had to do this for it to run on Google Cloud Platform (GCP). You could probably also just port forward 443 to 80 if you'd like, but this seems to be a more ideal solution, at least for me. You can always change the port to something completely different as well if desired (ex. 8443). - If you plan on using Cloudflare in front of your install, I highly recommend using the `Full (Strict)` SSL/TLS option if possible. This ensures the highest level of security (meaning your server has a valid signed certificate being used). --- To use Cloudflare with minimal hassle and not having to fight with LetsEncrypt: 1. Generate an origin certificate if desired, it's free for all plans on Cloudflare 1. Install the certs to your container storage somewhere 1. Use `ROCKET_TLS` to point to both files 1. Use `ROCKET_PORT` to change the default port to 443 1. Switch `Full (Strict)` SSL/TLS on for the domain on Cloudflare Note the longest period a generated origin cert can be set valid for is 15 years. Additionally, these certs are only trusted by Cloudflare's origin servers (hence why it's signed by them). The general public's browsers will still freak out. There is a possibility the cert will be terminated earlier than 15 years at Cloudflare's discretion, and you would need to update your cert again if/when it expires or gets revoked. This is just a matter of signing in to your control panel, clicking a few things, copying the text, and pasting it over the files on your server, then reloading it. Sure, not automated like LE, but considering the time it takes in comparison, it's not that bad. You can always regenerate new certs ahead of time as well, to extend the final expiration date. I'm not expecting all of this to be added to the wiki. I'm just dropping it here in case anyone else is having issues and can't figure it out. Might save them some time.
Author
Owner

@dani-garcia commented on GitHub (Jan 14, 2020):

Yeah the wiki is a bit lacking in some places, if you could help complete it that would be great, I think mentioning at least the RSA format and the port info would help. I think a short mention about the cloudflare setup wouldn't hurt either.

https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS

@dani-garcia commented on GitHub (Jan 14, 2020): Yeah the wiki is a bit lacking in some places, if you could help complete it that would be great, I think mentioning at least the RSA format and the port info would help. I think a short mention about the cloudflare setup wouldn't hurt either. https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS
Author
Owner

@dani-garcia commented on GitHub (May 14, 2020):

Closed due to inactivity.

@dani-garcia commented on GitHub (May 14, 2020): Closed due to inactivity.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#562