That for sure. Depending on your setup, it may be possible to configure everything on the server end from docker environment variables, which is awesome for use with docker-compose.
Also, if you are using Bitwarden_rs, make sure that you read through this document:
Oh wait, is mssql Microsoft SQL? OMG. I don’t understand why the Bitwarden devs like Microsoft so darn much xD.
They’re probably boomers.
“Microsoft means I’m a professional”
Insert simpsons ralphie meme
rofl
Also, just to sort of boast here: https://www.ssllabs.com/ssltest/analyze.html?d=bitwarden.linuxdragon.dev&s=2600%3A3c02%3A0%3A0%3Af03c%3A92ff%3Afe78%3A2587&latest
In the selfhosting spirit, you might want to use testssl.sh instead. It captures a couple of more things.
server_tokens off;)Yeah, I haven’t figured out how to set that up with Nginx quite yet (I switched over from apache, so I do know how to set it up there), but like you said it isn’t a big deal. In /etc/letsencrypt/options-ssl-nginx.conf it has ssl_prefer_server_ciphers off; set. I tried to override this in the http block of /etc/nginx/nginx.conf but it didn’t seem to work.
Yeah I know. But if someone is going to attack my server does this really mitigate a lot of things tbh?
Idk what that is xD.
You can just edit /etc/letsencrypt/options-ssl-nginx.confdirectly. It will complain if you update certbot, in which case you can manually merge in the changes the update wants.
Not really, unless you are using an out of date nginx version with a security vulnerability, in which case you probably have bigger issues.
It means they have to randomly spray attacks, rather than target.
I use the repository from https://nginx.org/en/linux_packages.html#Debian for Nginx, but I went ahead and set the header.