{"id":724,"date":"2019-10-09T18:38:00","date_gmt":"2019-10-09T23:38:00","guid":{"rendered":"http:\/\/zewwy.ca\/?p=724"},"modified":"2023-09-19T22:12:44","modified_gmt":"2023-09-20T03:12:44","slug":"run-bitwardenrs-with-internal-pki","status":"publish","type":"post","link":"https:\/\/zewwy.ca\/index.php\/2019\/10\/09\/run-bitwardenrs-with-internal-pki\/","title":{"rendered":"Run BitWardenRS with Internal PKI"},"content":{"rendered":"

I recently covered installing BitWarden_RS, that used let’s encrypt which is great for public service type.<\/p>\n

Private industry that like to run on prem sometimes doesn’t want to have the front end exposed to the interwebs, and without any direct NAT and sec rules to allow external entities to hit the bitwarden server at all, HTTP validation (which these scripts use) will fail, even if you configured them to use DNS validation, getting the certs on the server still requires access of some kind if automation is wanted.<\/p>\n

With an internal PKI the life of certs can be greatly extended and also kept entirely in-house, if one so pleases.<\/p>\n

So this Guide continues on after the last just before letsencrypt is installed but after the NginX setup as been configured to allow the challenges, I might simply pull that part of the includes part of the NginX config as it won’t be needed but lets move on.<\/p>\n

Now the letsencrypt uses etc\/letsencrypt path to store certs n keys. Since I will be using this all just for nginx, i’lll use \/etc\/nginx\/certs:<\/p>\n

mkdir \/etc\/nginx\/certs<\/pre>\n
cd \/etc\/nginx\/certs<\/pre>\n
openssl req -new -newkey rsa:2048 -nodes -keyout bwserver.key -out bwserver.csr<\/pre>\n
\"\"<\/a><\/p>\n
use cat to open the CSR n copy n paste the contents:<\/p>\n
\"\"<\/a><\/p>\n
Navigate to your internal CA server, request cert -> advanced template to use: Web Server, Paste your CSR<\/p>\n
\"\"<\/a><\/p>\n
THen save the file (for now I saved both Base 64 and DER and used WinSCP to copy them to the server<\/p>\n
\"\"<\/a><\/p>\n
now I noticed that the config uses PEM files so I found out how to convert the certs<\/a> into what I need:<\/p>\n
openssl x509 -inform der -in \/home\/zewwy\/bwserverCert.der -out \/etc\/nginx\/certs\/bwserver.pem<\/pre>\n
$EDIT sites-available\/bitwarden<\/pre>\n
Adjust the HTTPS section under the HTTP section accordingly:<\/p>\n
#\r\n# HTTPS\r\n#\r\n# This assumes you're using Let's Encrypt for your SSL certs (and why wouldn't\r\n# you!?)... https:\/\/letsencrypt.org\r\nserver {\r\n    # add [IP-Address:]443 ssl in the next line if you want to limit this to a single interface\r\n    listen 0.0.0.0:443 ssl;\r\n    ssl on;\r\n    ssl_certificate \/etc\/letsencrypt\/live\/[your domain]\/fullchain.pem;\r\n    ssl_certificate_key \/etc\/letsencrypt\/live\/[your domain]\/privkey.pem;\r\n    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;\r\n    # to create this, see https:\/\/raymii.org\/s\/tutorials\/Strong_SSL_Security_On_nginx.html\r\n    ssl_dhparam \/etc\/ssl\/certs\/dhparam.pem;\r\n    keepalive_timeout 20s;<\/code>     server_name [your domain];\r\n    root \/home\/data\/[your domain];\r\n    index index.php;<\/code>     # change the file name of these logs to include your server name\r\n    # if hosting many services...\r\n    access_log \/var\/log\/nginx\/[your domain]_access.log;\r\n    error_log \/var\/log\/nginx\/[your domain]_error.log;<\/code>     location \/notifications\/hub\/negotiate {\r\n        proxy_pass http:\/\/127.0.0.1:8080;\r\n        proxy_set_header Upgrade $http_upgrade;\r\n        proxy_set_header Connection \"upgrade\";\r\n        proxy_set_header Host $http_host;\r\n        proxy_set_header X-Real-IP $remote_addr;\r\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\r\n        proxy_set_header X-Forwarded-Host $server_name;\r\n        proxy_set_header X-Forwarded-Proto https;\r\n        proxy_connect_timeout 2400;\r\n        proxy_read_timeout 2400;\r\n        proxy_send_timeout 2400;\r\n    }<\/code>     location \/ {\r\n        proxy_pass http:\/\/127.0.0.1:8080;\r\n        proxy_set_header Upgrade $http_upgrade;\r\n        proxy_set_header Connection \"upgrade\";\r\n        proxy_set_header Host $http_host;\r\n        proxy_set_header X-Real-IP $remote_addr;\r\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\r\n        proxy_set_header X-Forwarded-Host $server_name;\r\n        proxy_set_header X-Forwarded-Proto https;\r\n        proxy_connect_timeout 2400;\r\n        proxy_read_timeout 2400;\r\n        proxy_send_timeout 2400;\r\n    }<\/code>     location \/notifications\/hub {\r\n        proxy_pass http:\/\/127.0.01:3012;\r\n        proxy_set_header Upgrade $http_upgrade;\r\n        proxy_set_header Connection \"upgrade\";\r\n    }\r\n    #\r\n    # These \"harden\" your security\r\n    add_header 'Access-Control-Allow-Origin' \"*\";\r\n}<\/code><\/pre>\n
in this case I adjusted my certs to my now internal signed ones:<\/p>\n
\"\"<\/a><\/p>\n
After this follow the remaing part of the bitwarden install guide… when I did I was able to get it up but I got a cert error, at first it was cause in my enviroment, I didn’t have my offline-root cert installed on the client, so after I got that, and verified my intermidate sub CA was good, I verified it by navigating to my CA certsrv site and it was all green… yet I was getting an error even though my chain was green across the board….<\/p>\n
\"\"<\/a><\/p>\n
Oh yeah…. shit Chrome requires a SAN even if no alternative names is ever planned to be used, …. THanks Google!<\/p>\n
\"\"<\/a><\/p>\n
ok… lets backup a bit… stop the docker instance::<\/p>\n
docker-compose stop<\/pre>\n
Now I should just need to reconfigure that nginx bitwarden file after creating new certificates with a SAN in it… but how to do that with OpenSSL…. lil more googling I found this great guide<\/a> by Paul Kehrer almost 10 years ago… first thing I read is …<\/p>\n
“SAN CSRs cannot be generated using the interactive prompt in OpenSSL” … Why?! it’s now literally standard… and the prompts don’t even ask for it.. what is this an IMSVA?! :@<\/p>\n
anyway… lets following along<\/p>\n
cd \/etc\/nginx\/certs\r\nnano req.conf<\/pre>\n
[ req ]\r\ndefault_bits        = 2048\r\ndefault_keyfile     = bwserverSAN.key\r\ndistinguished_name  = req_distinguished_name\r\nreq_extensions     = req_ext # The extentions to add to the self signed cert\r\n\r\n[ req_distinguished_name ]\r\ncountryName           =\r\n \r\n\r\nCA\r\ncountryName_default   = CA\r\nstateOrProvinceName   = MB\r\nstateOrProvinceName_default = MB\r\nlocalityName          = WPG\r\nlocalityName_default  = WPG\r\norganizationName          = ZWY\r\norganizationName_default  = ZWY\r\ncommonName            = bitwarden.zewwy.ca\r\ncommonName_max        = 64\r\n\r\n[ req_ext ]\r\nsubjectAltName          = @alt_names\r\n\r\n[alt_names]\r\nDNS.1   = bitwarden.zewwy.ca\r\nDNS.2   = www.bitwarden.zewwy.ca\r\nDNS.3   = bw.zewwy.ca\r\n\r\n<\/pre>\n
openssl req -new<\/span> -nodes<\/span> -out<\/span> myreq.csr -config<\/span> req.conf<\/code><\/pre>\n
k… checking our files, we just need to resign our new CSR…copy it back to the server with WinSCP, convert it with the openssl command, check our files are as needed:<\/p>\n
\"\"<\/a><\/p>\n
lets change our nginx files:<\/p>\n
nano \/etc\/nginx\/sites-available\/bitwarden<\/pre>\n
test it, confirm it, apply it, and bring up our docker instance again:<\/p>\n
\"\"<\/a><\/p>\n
and test it from the client side…<\/p>\n
\"\"<\/a><\/p>\n
I hope this helps someone, mainly future me.<\/p>\n
Cheers.<\/p>\n
*UPDATE 2023* Very helpful thank you.
\nNote 1) When generating a new certificate, the old private key is used unless you generate a new private key.<\/p>\n
Note 2) you only need to restart nginx service, you don’t need to drop the container, and repull it, unless you want the latest updates to the container software.<\/p>\n","protected":false},"excerpt":{"rendered":"
I recently covered installing BitWarden_RS, that used let’s encrypt which is great for public service type. Private industry that like to run on prem sometimes doesn’t want to have the front end exposed to the interwebs, and without any direct NAT and sec rules to allow external entities to hit the bitwarden server at all, … <\/p>\n
Continue reading “Run BitWardenRS with Internal PKI”<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"sfsi_plus_gutenberg_text_before_share":"","sfsi_plus_gutenberg_show_text_before_share":"","sfsi_plus_gutenberg_icon_type":"","sfsi_plus_gutenberg_icon_alignemt":"","sfsi_plus_gutenburg_max_per_row":"","footnotes":""},"categories":[8],"tags":[243,244],"class_list":["post-724","post","type-post","status-publish","format-standard","hentry","category-server-administration","tag-bitwarden","tag-internal-pki"],"_links":{"self":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/724","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/comments?post=724"}],"version-history":[{"count":3,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/724\/revisions"}],"predecessor-version":[{"id":1502,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/724\/revisions\/1502"}],"wp:attachment":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/media?parent=724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/categories?post=724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/tags?post=724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\"\"<\/a><\/p>\n