Good Morning from my Robotics Lab! This is Shadow_8472 and today, I am going over creating a self-signed certificate for my Vaultwarden. Let’s get started!
I’ve spent a long time trying to figure out proper HTTPS, but slapping on a solution and going without understanding the underlying workings doesn’t feel right. I don’t even have that. As long as I learn something each attempt, that should be good enough. I’ll be following the tutorial from Vaultwarden [1] with commentary from censiClick’s video [2]. My commentary here will be largely guesswork based off those and associated manual pages [that I have no idea how to properly cite but are available by typing man <command> in most Linux terminals].
https://github.com/dani-garcia/vaultwarden/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome
https://www.youtube.com/watch?v=eCJA1F72izc
Step 1: Generate Key
openssl genpkey -algorithm RSA -aes128 -out private-ca.key -outform PEM -pkeyopt rsa_keygen_bits:2048
openssl genpkey
This base command generates a private key for OpenSSL.
-algorithm RSA -aes128
RSA and aes128 are encryption algorithms for generating the key. RSA is a public/private key system and aes is a powerful single-key algorithm. Here, they can be seen working together to create a powerful encryption without having to find a relatively private back alley to exchange keys.
-out private-ca.key -outform PEM
These flags specify where to save the key after it’s generated and what format to save it as.
-pkeyopt rsa_keygen_bits:2048
(Private KEY OPTion) This flag lets you manage options for key generator algorithms, in this case: using the 2048 version of RSA.
Step 2: Generate Certificate
openssl req -x509 -new -nodes -sha256 -days 3650 -key private-ca.key -out self-signed-ca-cert.crt
openssl req
(REQuest) This command obtains certificates. In this case, it’s generating one itself, but as the name implies, it’s aimed more at requesting them from an authority.
-x509 -new -nodes -sha256 -days 3650
-x509 specifies that this root certificate will be self-signed. The -days flag will set it to expire in ten years minus leap days. The -new flag has the user fill in some additional information for the certificate, -nodes leaves private keys unencrypted, and -sha256 is a hash function.
-key private-ca.key -out self-signed-ca-cert.crt
These final flags are I/O. key loads the key from the previous command, out names the certificate.
Step Three: Preparing to Sign
openssl genpkey -algorithm RSA -out bitwarden.key -outform PEM -pkeyopt rsa_keygen_bits:2048
openssl req -new -key bitwarden.key -out bitwarden.csr
These commands are similar to before but for Bitwarden. They lack components needed to make the root certificate authority. There’s also some sort of special configuration file I’m not looking to break down, but is around under Vaultwarden’s GitHub [1].
Step Four: Signing the Certificate
openssl x509 -req -in bitwarden.csr -CA self-signed-ca-cert.crt -CAkey private-ca.key -CAcreateserial -out bitwarden.crt -days 365 -sha256 -extfile bitwarden.ext
Finally, it’s time to bring everything together to sign the certificate. Many of these flags are familiar from previous commands. Reading through it, it feels like the last stop to make sure all your papers are in order. Some operating systems are rightfully cautious about certificates signed for an overly lengthy time.
From here, it’s a matter of starting the Vaultwarden container with its new certificate and assuring whichever browsers you’re using that you trust the new certificate authority [2].
Practice to Practical
I’m glad I took the time to study this a little more closely than blindly following instructions this time. When making using openssl req, I was able to confidently regress by deleting a few files so I could give a different common name to the root CA and Vaultwarden’s certificates respectively.
The next challenge was successfully launching the Podman container. Following along with the censiCLICK tutorial, I had three new flags relative to last time I was working with Podman. One was to restart the container unless stopped (no elaboration provided).
The second flag tripped me up. I confused a pair of default ssl certificates for the of self-signed ones required later on, bitwarden.crt and bitwarden.key, created in earlier steps. I copied those two files into their own Podman-mountable directory. Once again, I added the :Z flag to tell SELinux it’s OK.
-e ROCKET_TLS='{certs="/ssl/bitwarden.crt",key="/ssl/bitwarden.key"}'
The final flag sets an environment variable as the container finishes starting. This particular one is configured to tell Vaultwarden where the files are to encrypt HTTPS. If they aren’t there –as I found out while I was still sorting the system certificates– something inside the container shuts it down; it was not a fun combo with the restart unless manually stopped flag as I had trouble removing the container so I could create a new for my next attempt. I knew I was done when podman ps returned a container running for longer than a second or two…
…or so I thought. I went to import my root certificate authority to Firefox, and I still can’t connect even when specifying https://<ButtonMashIP>:44300.
Long Story Short:
podman run -d --name vaultwarden --restart unless-stopped -v /home/vaultwardenUsr/<path/to/vw-data>/:/data/:Z -v /home/vaultwardenUsr/<path/to/private/certs>/:/ssl/:Z -e ROCKET_TLS='{certs="/ssl/bitwarden.crt",key="/ssl/bitwarden.key"}' -p 44300:443 vaultwarden/server:latest
Edit Jan. 6 2022: Vaultwarden listens on port 80, so I'm using -p 44300:80 now. And when you go to verify in a browser, be sure to use https:// or you get "The connection was reset".
This is my current command to generate a Vaultwarden container with Podman and no root privileges. In the end, the only major differences with Docker containers are the paths to mount the volumes Vaultwarden needs from the host machine and the :Z flags for SELinux. Currently, I’m not able to establish a secure connection. I have a help request out, and will edit if I get an update later today, otherwise, I already know what next week’s side project will be.
Side Project
Thursday held a startling surprise as a new zero-day exploit appeared affecting Minecraft, among other things. I must have found out within a few hours of it going public. After doing my research and checking sources, I concluded it was real and with the help of tech support, I was on a patched version of Paper within an hour or so of finding out.
Log4Shell (as this one has come to be called) is scary both because an attacker can take full control of a vulnerable computer and how common vulnerabilities are. On the other hand, once such exploits go public, things get updated pretty fast.
Here is the best article I’ve seen as of about ten hours of the exploit going public: https://www.lunasec.io/docs/blog/log4j-zero-day/
The moral of this story is to keep your software up to date, especially if you see any big stories about computer security.
Takeaway
All the HTTPS literature I found appears to be aimed at the curious pedestrian or the seasoned system administrator. This made it very difficult to be someone in an in-between level of understanding. On a personal note, I learned that pressing the / key while in a man page lets me search the document, a feature I really wished I knew about two years ago.
One important critique I’d offer the censiCLICK video is that the tutorial was dumped straight into the home directory and no effort was given to change default usernames/passwords, which I would consider very important for a monolithic tutorial.
Final Question
Have you ever had a project fight you to the bitter end?
Works Cited
[1] “Private CA and self signed certs that work with Chrome”github.com, [Online]. Available:https://github.com/dani-garcia/vaultwarden/wiki/Private-CA-and-self-signed-certs-that-work-with-Chrome. [accessed Dec. 13, 2021].
[2] censiCLICK, “Full Guide to Self-hosting Password Manager Bitwarden on Raspberry Pi,” on YouTube, Nov 15, 2020. [Online video]. Available: https://www.youtube.com/watch?v=eCJA1F72izc. [Accessed Dec. 13, 2021].