Creating TLS Certs for a Bare Metal Cloud

Okay, now it's time to start building out the cloud. In my last video, I talked about certificate signing requests and how they're used to generate certificates. We'll take that knowledge and create a wildcard. The domain name I'll be securing is called heavy metalcloud.land. Now, originally I was going to use heavy metalcloud.local, but local is reserved for some multiccast operations. So to avoid collisions, I'll use LAN instead. Before I get started, I want to talk about my sources. If you want to dive deep into the topic of public key infrastructure, check out this book from the Feisty Duck. It's available as a download or a hard copy from Amazon. I'm not sponsored or affiliated with the author, but I do appreciate his work, so please check out the links down below. The author also has a GitHub page that contains example scripts for creating TLSerts and I'll be using these scripts as a starting point for my own certificates. Now let's talk about the certificate creation process for my cloud. I'll create a chain of trust that contains three certificates. the rootert which is at the top of the trust hierarchy, the subordinate or sometimes called the intermediate and finally a leafert that will be used to protect my domains. Okay, from here on out I'll be pasting in commands into a terminal. To follow along, check out my GitHub page linked in the description below. I'll have all the commands that I use in this video. Okay, to create theerterts, I'll use a tool called OpenSSL. First, I'll create a few directories that'll be used during the process. Next, I'll create three config files, one for each of theerts in the chain of trust. Let's start by looking at the root CA config file. Scrolling down a bit, we have a section called CA_DN. DN stands for distinguish name, and this section is used to identify the entity or owner. In my case, that'll be heavy metal cloud along with some location information. Scrolling down further, we have default days. This defines the expiration and how long theert will be valid. In this case, it's 10 years. So, I know what you're thinking. 10 years is a long time. Why is the expiration so far out? And the reason is that the certificate authority has to be stored in your operating systems trust store. So when the cert expires, you'd have to update all the trust doors of all the operating systems and browsers in the world, which isn't something you want to do every day. Okay, let's keep going. At the bottom, we have a section called name constraints. And this is an optional section and actually an extension to the X509 certificate standard. In this case, we only want to assign certificates containing heavy metal cloud.land. And by the way, the servicecluster.local local will be used for Kubernetes, but uh don't worry about that right now. With the configs in place, let's create our CSR to generate theert. The wreck argument means that this will be a certificate signing request. The new flag is just like it sounds. We're creating a new CSR. Next, we'll point to our config file, and we'll add two outputs. The first one will be the CSR itself and the second one will be our private key which we'll be using for signing. Running the command prompts us with a password. And here you can see the CSR file that was created. You can also see our private key in the private folder. Let's use another OpenSSL command to inspect the CSR. Okay, scrolling up a bit, you can see we have our subject which contains the distinguished name from our config file. The modulus and exponent are the public key and at the bottom you can see where the CSR was signed using our private key. Now that we have our CSR, let's create the actual root certificate. Again, let's look at the arguments for the OpenSSL command. Here we have a reference to our config file and we'll be taking in the CSR as an input. The output will be the root CA certificate. Okay, running the command, I'm prompted for the password again. We're then asked to sign the certificate and finally commit the changes. Now let's inspect the certificate using another OpenSSL command. Scrolling to the top, you can see the issuer. And since this is a self-signed certificate, the casert was issued by itself. We also have the subject section which came from our config file. And again, we have our public key with the modulus and the exponent. At the bottom, you can see theert was signed using our private key. Let's open up the config file for the subordinate. You can see it looks pretty similar to the caert, but I want to show you the expiration. Scrolling down, you can see the default days is now 365. So theert expires in one year. And since these subordinate or intermediates typically aren't installed in the trust store, you can make the expiration much shorter. Okay, I'll run the open SSL command again to create the CSR and private key for the subordinate. Next, we'll create theert using our rootert to sign it. And the result looks something like this. Finally, let's create the leaf certificate. Okay, one more time, I'll open up the config file for the leafert. This config file is smaller than the others. And one area of interest is at the bottom, the alt name section. This is where we define the domain names that we want to secure. You can see I also have one at the bottom called star.heavy metalcloud.lan. This is called a wildcardert and will allow us to use any subdomain where the star is located. Just like before, I'll run the open SSL command to create the CSR and the private key. With the CSR created, we can now run another command to create the actualert. So the full chain of trust now looks something like this. Let's take a look inside the leert to see what's going on. All right, this should look familiar by now. At the top, we can see the issuer is a subordinate and again we have our subject section along with the public key. The interesting part is further down and this section is called the subject alternative name or sand. It shows the domains that will be protected by thisert. And then finally we have the signature which was created by the private key. Now that we have our certificates created, we can start to build out our servers. In the next video I'll be using this server to install OpenSense for my cloud. I'll use OpenSense as a DNS server and also to allocate IP addresses using DHCP. Thanks for stopping by and I'll see you in the next video.

Before I build out my Bare Metal Cloud, I'll create TLS certificates that will be use to encrypt everything in transit! In this in-depth tutorial, we use OpenSSL to establish a complete Public Key Infrastructure (PKI) for a self-hosted cloud environment. Learn step-by-step how to create and manage your own three-tier Chain of Trust: the Root CA, the Intermediate/Subordinate CA, and a Wildcard Leaf Certificate to secure multiple subdomains like `*.heavymetalcloud.lan`. *To follow along, check out my GitHub page! All the commands and instructions from this video are in a README file:* *https://github.com/heavy-metal-cloud/youtube/tree/main/videos/build-your-own-cloud-series/03-tls* 00:00:00 - Intro 00:01:21 - Where to Find the Commands (GitHub Reference) 00:01:48 - Reviewing the Root CA Config File 00:04:55 - Reviewing the Subordinate/Intermediate CA Config File 00:05:45 - Reviewing the Leaf Certificate Config File 00:07:00 - Next Steps: Setting up the Servers and OPNSense (DNS/DHCP) Links referenced in this video: https://www.feistyduck.com/ https://github.com/ivanr/bulletproof-tls Amazon Affiliate Links - The Cloud Hardware: https://amzn.to/49GQo81 https://amzn.to/48c5nUT https://amzn.to/48bkX38 https://amzn.to/43Qeh9o https://amzn.to/43J6TfV https://amzn.to/4p7dsBx Amazon Affiliate Links - My recording Studio: - Cameras https://amzn.to/4pwfUBu https://amzn.to/4oVvBC6 - Lenses https://amzn.to/48v210x https://amzn.to/4rfyG1p - Audio https://amzn.to/4oU93lh https://amzn.to/3JU1w6Z https://amzn.to/48dJS5Y https://amzn.to/4icWkYk https://amzn.to/43Lq096 https://amzn.to/4rcGDER - Lighting https://amzn.to/48cgJYV https://amzn.to/49CYQFi https://amzn.to/4abTMYt https://amzn.to/48vdKfE - Tripods, etc. https://amzn.to/4obC2zK https://amzn.to/4ofcemq https://amzn.to/4oe0zV4 https://amzn.to/4abDDSX https://amzn.to/47Vl6Ja https://amzn.to/3XaaRdQ