Homelab - Create your own local SSL Certificate Authority
Now that I had my own Ovirt infrastructure and local DNS (DNSSEC enabled in case you forgot) server I was finally able to get rid of the host file maintaining pain and start accessing different URLs just by adding them in my local DNS zone file. So instead of the uggly old URL https://10.0.0.3/ovirt-engine/ that i was using to access my Ovirt Dashboard, I could finally access it by typing its dns record, https://ovirt.homelab.home, instead of the IP.
But the pain never stops!
I couldn’t get over the fact that each time that I wanted to access a newly created HTTPS service the browser would inform me about the Plagues of Egypt that would be casted upon me in case I decided to proceed and connect to the desired endpoint. It was then that Bruce Lee’s most famous quote hit me! “Be the Water”! And before start wondering how this is connected to my realization, let me explain myself!
In order to resolve this I would need an SSL certificate from an official Authority but this would mean money and let’s be honest, my projects didn’t have any potentials on conquering the world!(yet)
Next step was to think about configuring Let’s Encypt which is awesome and totally free! But at that point there was no wildcard support from their side and didn’t want to set it up for each and every server ,so I decided to be Water! To be my own local SSL Certificate Authority and issue as many different certificates as I wanted! Thank you Bruce!
A certificate authority (CA) is actually an organization that signs digital certificates. Those digital documents bind the identity that is requesting the certificate with cryptographic keys, securing the validity of the entity. Such organizations are internationally trusted and their Root Certificates are pre-installed in all browsers and devices.
We could get into more details in regards of the different CA hieraches and Subordinate (Sub) CA’s but I will limit this post to the basic configuration that anyone needs to understand in order to create his own Root Authority and Self Signed Certificates!
How SSL Issuing actually Works
In a real life production scenario the procedure that someone would follow in order to receive an SSL certificate would be to first create a Certificate Signing Request (CSR). Generating a CSR means that a pair of keys is created, a public key which contains information regarding the organization that has applied for an SSL certificate and a private one which is a unique cryptographic key related to the corresponding CSR and should never be shared with anyone outside your secured environment.
Attention: If the private key is either lost or compromised the certificate will no longer work or malicious users could potentially read your encrypted communications and put your organization at risk.
Last step after CSR generation would be to sent the public key to the official authority which would then give back a certificate which is signed by their root private key and can be installed to any of your servers.
Creating our local Root CA
There are different ways to become a Root CA, if you are a GUI person there is an amazing free tool called TinyCA which has a ton of features and if you are a terminal enthusiast you are going to use two simple commands.
First you need to create the Root’s private key,
It is highly recommended that you provide a passphrase and secure your private key!
Take a look at the content of the created private key,
Let’s now generate the Root Certificate. You will be prompted for the passphrase of your private key from the previous step and a bunch of questions will come up. As an advise the only question that makes sense at this step is the Common Name (CN) as this name will help you recognize your authority in a list of others (for example when imported in a browser and you need to confirm that your Root Authority is actully present , you will thank me later!).
Our Root CA will be valid for the next 20 years but feel free to adjust to your needs,
You can check the contents of your Authority’s certificate by issuing,
Also to make sure that this is a CA you can also issue this command,
At this point you should now have two files:
You can now go grab a beer because you are now a CA and cash is gonna flow, baby! Hm.. the second part of course isn’t actually true and you will not be able to sell certificates but at least you got a beer!
Import your Root CA to any browser or keystore
In order to act as an actual local CA you have to import the root certificate you created on all of the devices that you own. You can either add it to OS’s keycain/Certificate Store or directly to your browser generally by going to Preferences -> Certificates -> View Certificates -> Authorities Tab and Import you pem file.
When finished you should see your Authority in the list! Aren’t you glad that you picked a name that can be spotted easily?
So congratulations but no more beer for you.. let’s continue!
Create Self Signed Wildcard Certificate
Now we have to create the actual certificate that is going to be installed in our homelab servers. The only difference from a production SSL certificate issuing procedure is that instead of sending the csr that we are going to create in the next steps to Comodo or Verisign, is that we will bypass them and sign it with our own CA! (who needs them now, right? :P )
There are different certificate types (OV, EV, Wildcard etc.) and authority hierarchies (Root, Intermediate, Sub CA etc.) and for our case we only created a Root Authority and will continue by issuing a Wildcard certificate so as to have one SSL certificate for all of our homelab.home internal domains.
You can find a lot of great articles if you need more information on the different types that will help you purchase the correct type for your production environment (and I would say that you already stopped reading the rest of the post and started googling around) or your homelab.
In order for you to understand why i chose a wildcard certificate and what is the difference with a single one, I have to provide some basic information. A wildcard certificate can be applied to a domain and all its subdomains. Instead of having a separate certificate for each of your domains (mail.homlab.home,ovirt.homelab.home etc.) you can create or purchase a wildcard certificate which will protect all of you domains and save you money. Of course there are always advantages and disadvantages in the wilcard village but I will skip this discussion for now.
We can now create our self-signed wildcard certificate by creating our csr and private key. Do not be confused with the csr and key that we created in the previous step, this was Root’s files and in real life we wouldn’t have access to those!
Instead of typing again all the information needed by a csr as we did in the Root creation we will use a config file. We will mostly do that though because we have to define a Subject Alternative Name (SAN) extension. As explained here
RFC 2818 describes two methods to match a domain name against a certificate - using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName.
at some point when Chrome and Firefox ignorred CN the user would receive privacy errors because subjectAlternativeName would be empty! There is a great free tool which is called testssl which checks a server’s service on any port for the support of TLS/SSL ciphers and can be downloaded from here.
So let’s create our private key,
Then we will create the certificate request by using the config file found below, do you see the alt_names section? This is the SAN option we where talking about before,
After the previous command 2 more files are added to our folder, the request (csr) and private key (key) for our self signed certificate.
Now instead of sending the csr to a legitimate certificate authority so as to sign it with its private key, we will sign it with our own!I hope you remember the password that you have picked for your Root CA’s private key because the next command will ask you to enter it! If not don’t worry, just delete everything and restart the process and this time keep a note! :)
You should now have one more file added to the list of the wildcard* related ones which is the issued certificate!
Let’s verify that the certificate is correct and the chain is trusted,
Nice! Let’s take a look at our Wildcard Certificate,
Do you spot the differences from the Root certificate? Our certificate is now issued and valid for the next 20 years (how lazy am I?).
All those files including wildcard.homelab.home.crt (certificate), wildcard.homelab.home.key (private key) and probably the root.pem (CA certificate) will be used in one way or another to configure SSL in any of your web servers.
It is great to have my personal CA and be able to issue any certificate on my own. I didn’t configure an Intermediate CA just for simplicity but this would be a great side project for you to understand the hierarchy and how all the different levels are connected to each other in order to create the necessary Chain of Trust!
As a final step I could wrap this in a bash script or an ansible playbook and automate the process but I won’t be using any other certificate other than the wildcard one, at least for now! But maybe I can create a post about this in the near future! (Dear FutureMe..)
In my next post I will try to install the newly created Wildcard SSL to my Ovirt Engine which was the initial spark that started the idea of hosting my own CA!
Until my next post and as Dr Wallace Breen says in Half-Life 2.. Be wise. Be safe. Be aware!
Subscribe via RSS