Tag: nginx

  • Installing Vaultwarden on your VPS

    Installing Vaultwarden on your VPS

    It’s pretty simple. Seriously.

    Alright. You have finally chosen to self-host. And you realize that you’ll never have pay for a secure password manager again now that you’ve discovered Vaultwarden. All you need now is an easy-breezy install guide.

    Well lucky you! Here it is. Let’s get started installing Vaultwarden on your VPS. You’ll be living the self-hoster’s dream in no time. A quick explanation from Vaultwarden’s README:

    Vaultwarden—An alternative server implementation of the Bitwarden Client API, written in Rust and compatible with official Bitwarden clients [disclaimer], perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.


    So there you have it. When this install is done, you’ll have your own self-hosted install, and you’ll be able to point to it via the Bitwarden mobile app. Double win.

    Ok, so first, log into your VPS. If you’re logging in as root, remove the sudo part from the commands. Install the following dependency:

    Argon2 is a rock-solid password hashing algorithm. We want it for the install. Give it a moment to install. See the next steps just below.

    Just fyi, if you want to do the install elsewhere on your server, feel free. I’m just doing it from $HOME since it’s convenient and easy to follow.

    Configuring our docker-compose.yml

    Now that we’re in our install directory, let’s vim into a docker-compose.yml with the following command:

    Paste the following:

    You might be asking “why on earth is SIGNUPS_ALLOWED set to false?” Well, the reason lies in the ADMIN_TOKEN value. That token will allow you admin access at /admin, and inside you can invite users to create an account. This is the way to go to keep weirdos from flat-out creating accounts.

    Let’s create that token, shall we?

    Copy the hashed value that shows. Now let’s create the .env file so our docker-compose.yml knows where to find the ADMIN_TOKEN.

    Then add the following into the .env (and yes, the quotes are needed!):

    With that, Docker runtime configurations are complete. Let’s move along.

    If you remember in the docker-compose.yml above, we’re serving container port 80 to host port 9273 with the - "9273:80" configuration. In Nginx, we now need to set up a reverse proxy that will serve host port 9273 to our url. We also need to tell Nginx where to find ssl certificates for the site, so that you can serve it over https correctly. Let’s go.


    For now, paste the following:

    Heads-up: you’ll notice above that I’m pointing to the snakeoil temporary ssl certificates. This is strictly to pass the nginx -t config test later. You’ll need to change this out later with your actual certs. Otherwise, if you’re using Certbot, the cert paths will be overwritten automatically. I talk about how to set up certifications via Certbot in this post.

    Next, we need to create our symbolic link between sites-available and sites-enabled in Nginx.

    The nginx -t command should return a successful result. If it doesn’t, go back and fix your shit bro. Otherwise, let’s reload Nginx:

    You should still be in your working directory that contains your .env and docker-compose.yml file. Confirm with a quick pwd and/or ls -lart. At this point, we can turn on Vaultwarden, finally!

    In a browser, head to https://vault.yourdomain.here/admin. Enter the ADMIN_TOKEN value (not the hash value damnit!), and log in.

    All Systems Go! …Right?

    After logging into /admin, click on “Diagnostics”. You should see all-green indicators like the ones in the image below.

    An image from the diagnostics tab of the admin panel that shows the results of a successful install.
    Diagnostic results of a successful install

    After confirming, you can head to the “Users” section, where you can invite users (including yourself duh) to create an account via email.

    Conclusion

    We’ve been through a lot together, I know. And in the end, installing Vaultwarden on your VPS really is simple. Now go forth, and never pay for a password manager again!

  • Using Certbot to Manage SSL Certificates

    Using Certbot to Manage SSL Certificates

    Or pay $25-$200 per year to your hosting provider. Up to you!

    You know the thing where you navigate to a url, and you get one of those “gaahhh return to safety!” warnings on a dark gray screen? It’s usually do to a missing or expired SSL certificate. An SSL certificate allows your site(s) to be delivered over HTTPS, and is a crucial, baseline security feature. It encrypts all traffic between your hosted site and its visitors. It’s also proof that your site is actually your site, and not a spoof/man-in-the-middle attack lying in wait to snatch up all your highly confidential state secrets. Bottom line, you need SSL certificates. Hosting providers know this, and bet on you being spooked enough to fork over tons of loot every year for them to manage them for you. But if you use Certbot to manage SSL certificates, the control is in your hands. And the money is too. So save the money and use Certbot.

    Preparation Steps to Use Certbot

    As a word of caution to anyone reading this tutorial, I’m assuming you have already purchased a domain from your hosting provider, and added the www subdomain, and made any necessary DNS changes to link your domain to your VPS. Likewise, I recommend securing certificates before doing something like this, so make the certs happen before anything else.

    Anyway, let’s get started by installing Certbot and the Certbot Nginx plugin, and creating a root folder for your site.

    Next, if you haven’t already, we’re going to create an Nginx config file and point to the snakeoil certs temporarily, in order to pass the nginx -t config test.

    Paste the following (note the snakeoil temp certs):

    Run the commands below to generate a symlink, confirm correct syntax, and reboot Nginx:

    Just so you know, if you go to your url after this step, it still won’t load correctly. That’s due to the snakeoil temp certs in the nginx config file. We’ll run Certbot now to generate the real certificates.

    Run Certbot to Receive SSL Certificates

    The command we’ll run next creates a shared, multidomain (aka SAN) certificate for domains & subdomains indicated in the command. While it’s possible to create a wildcard certificate as well, this tutorial won’t be covering that method. It’s a pain in the neck—you can’t use the Nginx plugin, it requires DNS verification, and you have to set TXT records in your DNS manually or via API. So peace to all that noise. Let’s run Certbot like a regular person instead:

    When prompted, give a valid email, agree to the terms, and choose to direct all http traffic to https. If you want to skip the prompts altogether, structure the command like this:

    Confirm a Successful Install

    First, let’s check the certificate exists with the following command:

    You should see your certificate block print to the terminal. Under “Domains:” you should see your domain and your www subdomain. The “Expiry Date:” section will display the expiration date of the certificate.

    Now let’s confirm that the Nginx config file points to the newly-created certificates:

    You should see the certificate paths changed from the snakeoil temp paths to the path of the real certificates, like /etc/letsencrypt/live/yourdomain.here/fullchain.pem and /etc/letsencrypt/live/yourdomain.here/privkey.pem.

    Finally, let’s reload Nginx again:

    If you navigate to your domain url, with or without the “www” prefix, you’ll be routed to the index.html page we created at the beginning of the tutorial, over https. And if you click on the little slider-looking button on the left side of your browser’s url input area, you should now see a “Connection is secure” notification. Congrats! You’re all done.

    What about Certificate Renewal?

    Well yeah, that’s a fair question. Certbot adds a timer to systemctl, so let’s check that out.

    You’ll see something along the lines of:

    That timer is running twice a day, every 12 hours, with a randomizer delay baked in as well. It checks the validity of the certificate, and if it’s time to renew, it runs certbot renew for you. You’re welcome.

    And, by default, Certbot will renew a certificate 30 days before expiration date. That’s solid padding, so I recommend leaving that default setting alone.

    Conclusion

    Implementing certbot to manage SSL certificates is easy. In my opinion, the money saved, and the auto-renewal functionality alone are worth the effort.