Self-Hosted TRUST with your own Certificate Authority!

do you care about Security in your home lab are you sick of all those do you trust this website warnings all over the place telling your friends and family to ignore them every time they want to connect your Plex server today we're going to fix that by taking a little Thin Client like this and a Yuba key we're going to make our own certificate Authority this is just like let's encrypt and it works the same way only we trust it ourself we can give out certificates on our own and anyone that trusts our root key will trust all of our websites come along with me on this adventure so what is a certificate after all well certificates are part of public key cryptography essentially mathematically if I generate a private key and keep it private and from that key I generate a public key and give that out to everyone everyone can verify if something was signed using my private key so I'm Apple art I write a certificate it says I am appleard at www.appler.net then I assign that with my private key if you take that certificate you can validate my signature actually did come from me if you trust my public key so I'm a web server I do a web servers do I generate my own private key so I can sign TLS transactions I make a certificate I send it out to the client the client checks and says oh look at this web server should we trust it and we get oh we get that um I guess they don't trust my web server so why don't they trust my web server if we look at the certificate in detail over here and says the common name is tara.palent.net and sure enough that's where we're going so at least the domain name matches we're not trying to forge that so who issued the certificate well proximox cluster manager CA so it looks like my web browser doesn't trust Proxima cluster manager CA and this is what happens for most self-hosted sites and most things in the home lab we generate our own TLS certificates we get encryption but we don't get that validation that everything's truly truly up and up and truly correct so how does a real website look so this is my own website this is my certificate so I have a common name of www.appilar.net that's my domain name and it says it's issued by R3 let's encrypt so if we look at the chain details so my certificate was signed by R3 and R3 was signed by isrg root X1 so what that means is that my server www.net got it certificate and then ask someone more important to sign it and that person was less encrypt and let's encrypt went to someone even more important and they signed their own certificate isrg root X1 and my web browser Edge implicitly trusts that isrg root X1 certificate so because isrg root X1 signed a certificate for let's encrypt and let's encrypt and use that key to sign my certificate there's a chain there a chain of trust so we like to do today is establish our own chain of trust for our home lab we're going to create that top dog that root certificate and then we're going to assign an intermediate certificate that we can use to issue more certificates to all of our home Lab Services so like all of these websites out in the public they go to Let's encrypt to get their public certificates we can go to our own certificate authority to get our own internal certificates signed and verified by our certificate Authority and this works even if we don't have public internet access or even gonna have internet access at all because it's all self-contained in the home lab our certificate Authority runs on our own local hardware it's signing certificates everything's on the up and up everything's happy another advantage of this is we can use really short-lived certificates so if one of our VMS is compromised if that private key that's on the vm's drive is leaked out on the internet might only be good for 24 hours before new one gets generated and signed but if we're going to rely on that for security how do we make sure our certificate Authority stays safe we use the Yuba key you've probably heard of these things before it's called a Yuba key but these things can be used to store securely private keys and they can sign certificates using the private key in Hardware so if someone were to hack into my certificate Authority they could sign things using the hardware key but they couldn't take the key itself and copy it somewhere else they'd only be able to ask the hardware key to sign things for it if I unplug the hardware key they can't do that anymore so for someone to have access to my private key they would actually have to steal the dongle and even then they wouldn't have the private key itself they just be able to use the private key so it makes it a lot harder for a hacker to get access to all of our data not impossible but it's an extra layer of security that I like so in sense we're going to generate three three levels of hierarchy we're going to generate our root we're going to keep the root on the special Rubik's Cube flash drive and it's going to be encrypted offline never going to touch the internet then using the root we're going to generate and sign a certificate for our yubikey which is going to stay connected all the time to the certificate Authority and then the certificate Authority can use the yubikey to sign short-lived certificates for individual servers hopefully that's a good enough overview of how certificates work for you let's get to setting it up so before we can set up a certificate Authority we need that God to your private key let's generate that now I can't stress this enough don't leave your private key around your root private key is like gotta keep it safe so one way you could keep it safe is by putting it on a flash drive like this and wiping the flash drive before you generate the key generating the key on the flash drive using a live USB on like a little computer like this and then rebooting then flash drive is the only place with a root private key keep this safe as long as it doesn't erase itself you'll be fine if you copy it on a couple flash drives whatever you want to do for the sake of this video I'm doing this in Debian I'm going to install the Yuba key tools so I can add the intermediate private key directly to the Yuba key and I'm going to put all of my files in The Roots home directory slash root you could use some other folders those are the folders I use in the example if you're following along make sure you change all the domain names and stuff to match your setup this is obviously my setup so yeah let's get into it oh also a note UV Keys have pins and you need to use the PIN to access them and the default pin is the kind of thing an idiot would use in their luggage so you probably want to change it yubiki has a post on that so open SSL we're going to use openssl to generate these certificates the root private key the root certificate the intermediate private key the intermediate certificate signed by the root key and then we're going to put that key into the key openssl has a config file where we can put a whole bunch of options I wrote a config file out you can copy and paste it if you want whatever but uh yeah let's copy and paste that most of it's not that special most of the big stuff is set on the command line anyway when we generate the keys but just look through it and make sure it looks good to you over on my Debian system we're going to make ourselves root with sudo suit then we're going to move to the root home directory slash root and make a new folder for our CA we'll add this config file after we generate the config file you can make sure all the directories are there for openssl and we also need to touch some files so they're created it's going to make a file that has a list of all the certificates we've ever signed the file doesn't exist it complains things like that commands are on the blog post next up we generate our private key using openssl and then we use that key to sign the certificate valid for 69 years for ourselves this is the certificate we're going to import into all of our clients so they all implicitly trust this private key it's also going to ask us for a passphrase this is used to encrypt the private key with AES 256 type something good don't use one two three four five you know the drill [Applause] when asked for a common name this is the name that will show up on the certificate when you look it in a web browser so this should be the name of your route so the isrg root X1 that was let's encrypt root I'm going to call mine Tempest and we're all done this certificate that we just generated with the root private key this we're going to have to copy onto all of our stuff all over the network but the certificate Authority we're going to set up later is going to host it on the web for us so anyone can download it that's going to make it a lot easier for now though let's generate the intermediate key the process for the intermediates a little bit different we generate the private key as we did before but we can't sign it because the root key has to sign it so instead we generate a certificate signing request this is where we attest to all of the things the common name all that kind of stuff and sign it then we pass it Upstream to the root and ask it to sign it for us then we have a complete certificate once the root has signed up it's part of this process we're also going to need to generate a passphrase for the intermediate key which we're going to need later and we're also going to have to enter our path phrases for the intermediate key and the root key at the right times [Applause] and we're all done now that we have those intermediate key generated we're going to import it into the ubikey and then delete the private key that way the only way anyone can sign things with this private key is by using the yubikey to do it can't forget to actually install the ubiky tools first basically the set of commands you can install the UB key tools start the service to communicate and then it's going to write to the intermediate file and the intermediate certificate onto the Yuba key in slot 9C now the ubiky has multiple slots 9A 9C and 9d are the most common however there's about 20 other retired certificate slots that you can use for whatever you want so if you use this key for other things you could use one of those retired slots I'm only using this key for this this Yuba key so I'm going to use 9C which is the general certificate signing slot but you're free to you it's again going to ask you for the passphrase for the intermediate private key make sure you enter that it's also going to ask you for your ubiky PIN make sure it's not one two three four five six enter that two and we're all done let's check the status why okay man PIV info so this command shows us what's on the Yuba key in the PIV application we can see we have a 2048-bit RSA key it's named The Tempest testing yubikey1 signed by Apple Arts Adventures blah blah blah blah blah blah seems good to me so now that we have our Yuba key set let's install the certificate Authority so I'm usually a big fan of virtualizing everything in this case though I have real security Hardware plugged in and I don't want this to be able to move around a cluster because I don't want to have a bunch of Yuba Keys plugged into every node so I decided to use a real physical device running a physical operating system bare metal I know that seems wild right but in reality all the important stuff is stored on the Yuba key so I could reinstall this no problem in an hour or two this is a Dell wise 30 40 Thin Client it's like 35 bucks on eBay it's got like a dual core atom pretty awful in either 8 or 16 gigs of vmmc also pretty awful perfectly adequate for this a Raspberry Pi would be fine too but they cost more than this so this is what I got I installed Debian 11 Bullseye as of the filming of this video that is the latest version of Debian I know I'm going to hear in the comments but Bookworm but Bookworm bookworms probably like three days off as of when I'm gonna release this video so Bullseye it is also there's a lot of things in these work instructions that are fairly specific to my setup like the name of my server the admin account named appleard things like that so make sure you actually read through the instructions and change anything that's specific to your setup I'll try to call it out in the video but if you're having a problem make sure you didn't use like my fingerprint or my name or something like that in your setup oh don't forget to do your Debian upgrades too yeah want to have updated packages before we continue so the tool we're using is called small step and it has two binaries we need small step CA that's the Daemon and small step CLI that's the interface now the Daemon needs to be compiled with support for yubikey and by default it's not so we got to compile it ourselves thankfully the CLI doesn't care so we can download that from the internet I have a dead package for the latest release version in the script here currently it's 0.22 Dot o.24.2 so in the future you might want to check what the latest release is on GitHub and get the dead package for that they don't have a Debian repository but their assets on GitHub include builds for a whole bunch of different Linux distributions including a Dev package for dead based distros such as Debian so we're going to go ahead and W get that Dev file and install that Dev file so that will get us the CLI that's the easy part next up we need to install the tools we need to build the ca it's written in go so we need a modern go compiler the latest version Debian has in back ports is 19 and that's a perfectly adequate version but we need to add the back ports repository so we got a command to do that you update appsources.list add the backboards repository apt update app install go 1.19 whatever so yeah back ports we all seen a few other tools so golang 1.19 we need get so we can download gate repositories lib PCS Lite Dev that is the library that says access smart cards the Yuba key appears as a smart card GCC the compiler make the build tools curl all that good stuff then after we do that we need to add go to our path when you add Go versions that are from not the golang package they don't add themselves to the path so the Debian package golang adds this up to the path the newer version of packages don't so we have to say what version we want after that we clone the git repository and we check out to a specific version this ensures we're on release and not just the latest head from the tree so I've called out version 0.24.2 check what the latest is check that out and finally we make install and it sounds funny to make install but make install depends on the binary so we will actually build the binary and then install it how lovely then at the end of that we tell Linux that this particular binary is allowed to bind to low numbered ports and yeah that's basically the whole command listing I don't think any of this is specific to my system but uh I mean read it first I should note this will take a very long time we're going to come back when it's done now that we got that build done let's make sure it's installed so we're going to run step version and then step CA version notice there the release date for the one that I compiled is now in UTC so not in local time and the packaged one is different so that's how you can tell that you just did the build the release date matches the time you did the build at so now we're going to set up a configuration file for our step certificate Authority and in order for it to generate this ourselves we're going to call step init and it's going to generate a whole bunch of keys for us it's going to generate a root ca key it's going to assign a certificate generate an intermediate sign that and we don't really want to do that but there's no way to tell it not to so we're just going to delete those files and we're done it's going to generate a whole pki for us we're going to delete all that replace with our Yuba key but I asked you that it's in the place to put RCA so I put an Etsy step we need a user for it and name it step and uh we need an environment variable called Step path so step knows where stuff is then we have this command step CA init this is where we get a name to our certificate Authority we give it a DNS name this is how it knows how to find itself make sure this resolves properly mine is not going to resolve in your setup I also have a line here to copy certs from the root CA folder I used earlier if you keep your keys offline you need the public keys so the certificate file for the intermediate and the certificate file for root you need to copy those in so this should have generated a config file for small step it's a pretty big file it should have generated for us we put our keys in it should be happy with that since we're using a Yuba key though we need to tell it to go find the ubikey instead of using the private key file on disk let's do that now so I put a little diff in my blog post so we need to edit the ca.json file and I put a little diff in showing what it needs to look like afterward obviously you use your yubiki pin and the slot you used I used 9C and even should work [Applause] so we basically replace the key directive which has a path to the intermediate private key and we tell it that the key is on the Yuba key and then the configuration for that [Applause] make sure all your syntax is right it will not like you if you type it wrong see the death on a website make sure it looks right commas squeakily brackets all those goodies so now we can test it we're going to do that by telling sudo to run the step CA command as the user step that should make sure it has permissions and uh everything just works so we end up with surveying on https 443 that's a good sign and bound to the port happy if your UB key is unplugged you get an error saying I could not bind a smart card it says air open UB key connecting the smart card the specified reader is not currently available for use then you know you got to plug your Yuba key in just a note if you unplug the UB key later it won't crash it'll just failed issue certificates so all of your Acme challenges will happen it'll be like oh oops are rare you'd be like oh plug those ubikes in getting close to the end now now that we have a certificate Authority and it works we want to run it on boot so we're going to use system D system D is all about running services on boot I've got a systemd config file on the blog post I'm just going to copy and paste that in I don't think any configurations necessary and then of course when we're done we Dame and reload and enable now the service so enable dash dash now that enables it and starts it thank you yay so a small step can be configured with a whole bunch of provisioners which are different ways of issuing certificates by default there is just JWT and we're going to add Acme to that Acme is the protocol used by let's encrypt if we add that then we can act as our own let's encrypt to our own services so step CA provisioner ad Acme Acme is the name of the provisioner so it's going to be funny the path is going to be Acme Acme because it's an Acme type and it's the Acme name but whatever just copy and paste the command well also we need to restart when we're done restart step CA not the whole system yay great success now we're all done now they're all done setting up small step we can try using caddy see if we can get some certificates from this guy so I spun up a proximox lxc container running Debian 11. the usual stuff I installed caddy from Dev packages and now we need to make that container trust our new certificate Authority so if you come over back to the blog post I've got all the commands you need to execute so our new certificate Authority server publishes the root certificate file in a well-known location so we can just W get that onto our local system for this case we have to not check the certificate though because our system doesn't yet trust that root certificate once we download it we can put it in our systems rootstore then it will trust it from then on go over here to the container paste it in there we go added one certificate now that it's been added Caddy will trust It Caddy has a directive to trust a root certificate other than its own for TLS purposes but if the system trusted in its root store Caddy will also use that so you don't have to add it separately to caddy again not a caddy tutorial but in the global section of the caddy file you can add an alternate location instead of let's encrypt and that's what we're going to do here I have a very basic example caddy file on my website I'm just going to paste that right in Global section here just has the Acme certificate Authority and that's the end point remember how I said I was going to be Acme Acme so it's the URL of our certificate Authority slash Acme which is the type of provisioner Slash Acme which is the name of our provisioner slash directory so in my case it's tempest.palent.net Acme Acme directory and then my test server also has a valid DNS record that points back to the server so it can do the httpl1 challenge get a certificate be happy and it's all we just can reply hello world everything I didn't set up a website or anything for this copy that caddy file start caddy looks like it decided to do a TLS challenge instead of an HTTP challenge perfectly fine Katie did the challenge category certificate Caddy's happy so I took the time I downloaded that roots.m I installed it on my Windows machine I restarted Edge now we can see what it looks like in Edge proper TLS it says hello world but let's look at this trivia chain so we have our end certificate for our site it is trusted by the testing yubiki one and that is in turn sted by Tempest through lab since I installed Tempest root lab on this machine and the certificate chain is valid it implicitly trusts this website because I told it to trust Tempest root and Tempest root was used to sign the Yuba key which was then used to sign this web server via our favorite protocol Acme the same protocol that's encrypt uses so now all of my websites inside my network can get TLS certificates that are trusted by my laptop and I don't have to worry about these self-centered certificate errors all over the place nice and clean now the big reason I did this is because I'm on a path to do Mutual TLS that's where the client and server usually authenticate each other I'm not there yet so this video is just authenticating the server to the client but just like we authenticate the server and assume the server just like we verify that the server is valid the server can also verify the same for the client and that's going to come in a future video so hopefully you enjoyed this tutorial I know it was on the long side but cryptography is hard this is just an introduction I do hope to set up Mutual TLS where I can give certificates to all of my clients have them authenticate to my servers that we don't have to log into stuff I can just log in by using a physical device or a ubikey like this on the client side maybe a smaller one than this big one but that's my goal long term I got some other tiny Yuba keys I want to use on my laptop my desktop and things like that that's my goal so uh yeah follow along and don't forget to like And subscribe if you want to see more of this good stuff you can check out my Discord link down below I always love having people there you can show off your own projects the Showcase section or chat with me about Acme protocol or small step or open SSL whatever you want to talk about there and yeah as always I'll see you guys on the next adventure

Channel: apalrd's adventures

Views: 19,755

Keywords:

Id: BKCj6A4CHV4

Length: 26min 24sec (1584 seconds)

Published: Thu Jun 15 2023