CubicleSoft Presents Root CA Tutorial - Learn how to create a real
Root Certificate Authority on a budget! Hello! During this video, I will demonstrate how
to correctly set up a Root Certificate Authority. Setting up your own Root Certificate Authority,
aka a Root CA, can be a difficult process. Web browsers and e-mail clients won't recognize
your CA out-of-the-box, so most people opt to use public CA infrastructure. However, when security matters, using a public
CA is the wrong solution. Privately owned and controlled CAs can be
infinitely more secure than their public counterparts. Unfortunately, most people who set up a private
CA don't set up their CA infrastructure correctly. Here is what most private CAs look like. [Root CA cert -> Server cert] What we see here is a two layer certificate
chain, the Root CA certificate and the server certificate signed by the Root CA. This is wrong because the server certificate
has to be regenerated regularly, usually on an annual basis. If the root certificate is compromised, then
it involves fairly significant effort to replace all of the certificates that were signed by
the root, including the root. And Certificate Revocation Lists, or CRLs,
can't be used to revoke a root CA cert. What should be built is this: [Root CA cert -> Intermediate cert -> Server
cert] Here, we see a three layer certificate chain. The Root CA certificate, an intermediate certificate
signed by the Root CA, and, finally, the server certificate signed by the intermediate CA. This is, in fact, the format that most public
CAs use. The root CA certificate is generated on a
machine that isn't connected to any network. Then it is used to generate any necessary
intermediate certificates. Both the root and the intermediates are signed
for long periods of time - typically about 10-30 years for the root and 2-5 years for
the intermediates. The root CA certificate private key is then
physically secured - a physical vault of some sort helps here. The root CA is never, ever used on a network-connected
machine. It is always used offline and it is only ever
used to generate intermediate certificates. Only when specific conditions are met is the
private key ever accessed. Usually those conditions entail a paper trail
of accountability with multiple people who are physically present and are authorized
to access the root key for purposes declared in advance. After the root CA generates the intermediate
certificates and is secured, the intermediate certificates are then used to generate other
certificates, such as the server certificates. The intermediates can possibly sit on a network
connected machine, but that machine is behind a very well-guarded firewall. So how does one create this setup, while implementing
it easily and securely, AND relatively cheaply? To get started, you''ll have to acquire a
few items. Some USB thumbdrives that are preferably brand
new. You will need three (3) of them for personal/individual
use OR six (6) of them if you are creating a root CA for a small business or larger entity. You will also need a permanent marker, a pen,
a blank CD-R and a CD burner, an externally powered USB hub with at least four (4) open
ports, a label printer or some sticky labels. And multiple, physically secure locations
for storing the various thumbdrives, possibly including the use of anti-tamper technologies. You are also going to need a few pieces of
software. Oracle VirtualBox or VMWare Player/Workstation,
KeePass or KeePassX, and, finally, an ISO of a public Linux distribution such as SliTaz
or TinyCore Linux. The smaller the Linux distribution, the better
off you'll be. Now that we have gathered all of our pieces
together, let's get this Root CA built! First, make sure everyone is in the room who
needs to sign off on the construction of the root CA. Decide in advance which of the people present
will receive thumbdrives containing important data required to decrypt the virtual machine
and the Root CA private key. It speed things up considerably if the individual
doing the technical side - setting up the virtual machine, burning the CD, things of
that nature - has gone through a dry run on their computer in advance to get familiar
with the process. Now I'm going to start an audit log on my
first USB thumbdrive. This will contain various bits of information
such as date, time, and the notes for this date and time. Started audit log and, of course, I am present. If there were other people present, I would
list them on the first line as well. And I will repeat this process for every operation
that I do including every command I am going to execute against the virtual machine that
I will eventually create. If I ever access this (thumbdrive) in the
future, e.g. to generate a new intermediate certificate every couple of years, I will
also update this file at that time. The next step is to make the Linux distribution
ISO, in my case, I am using TinyCore Linux, read-only to all users. A simple solution to making any file read
only is to burn that file to a CD or DVD as an ordinary file. To save time, I'm going to go ahead and download
the ISO and prepare the CD as it should be prepared and then I'll return to the video
after I've done that. I have now completed the process of burning
the ISO to disc as well as its MD5 signature and also updated my audit log to reflect what
I have done. Now I am ready to verify the ISO against public
information such as this MD5 hash. To do this properly, I need to compare the
same public verification information from the same source at a secondary location. Here is TinyCore CorePlus 6.4.1's MD5 hash. I'm going to use a remote SSH session to one
of the Digital Ocean droplets that I have and I'm going to retrieve the same URL and
we can see that the two files are identical. Finally, we need to verify that the ISO MD5
hash matches the hashes seen so far. I've already run a built-in Windows command
and we can see that the signatures match. Thus we have mitigated the possibility of
a man-in-the-middle attack. I've also updated my audit log with the various
steps of the signature comparison process. We are now ready to construct our virtual
machine using the ISO image. Before I can set up my virtual machine, I
need to create two passwords. I'm going to use KeePass for this. To set up the KeePass database, I will open
up my second USB thumbdrive and plug it in. [Thumbdrive plugs in and sound plays] I'm going to put the portable version of KeePass
onto the same thumbdrive as the audit log and eventual virtual machine. Once again, I add an entry to my audit log. [Starts KeePass] For the purposes of a Root CA, there will
never be the opportunity to update the software, so I am going to disable automatic updates
of KeePass. Now I am in KeePass and I'm going to create
a new KeePass database on the second thumbdrive that I just inserted. You should probably be labeling the thumbdrives
at this point so that you don't lose track of which one contains what. KeePass next asks how you want your database
to be encrypted. If you are an individual, you can use the
master password by itself or master password plus key file provider. If you are an organization, you only use key
file provider and store the key file on the third (of six) USB thumbdrive. For the purposes of this video, I'm going
to set up both a master password and a key file provider. If I were using six USB thumbdrives, I would
store the key file on the third thumbdrive. Since I'm just doing this for personal use,
I'm going to store it on the same thumbdrive as the KeePass software and my audit log. Click Save. Click OK. Now I'm going to click OK. Set up an optional name and custom database
color and click OK. KeePass (inexplicably) creates some default
entries, so clear those out. Now create the first entry. Enter the title (Root CA - VirtualBox encryption
password) and then come down to this little icon that says "Generate a password", click
"Open password generator...", enter '40' as the number of characters and, going with defaults
for the rest, click OK. Now we have a much longer password that is
40 characters long. Click OK and now I've created my VirtualBox
encryption password. Now I'm going to repeat the process for the
Root CA - Root Certificate private key. I'm now ready to save and now the two passwords
have been generated. And, finally, I updated my audit log to reflect
the database creation and password generation process that I just went through. Now I am ready to create the virtual machine
(for real this time). I already have VirtualBox started. Click New and set the title to 'TinyCore Root
CA'. Select "Linux". It's a generic Linux and it is also 32-bit,
not 64-bit as VirtualBox had picked out. I'm going to click Next. 256MB RAM works for TinyCore. You might need more if you use a beefier OS
like Ubuntu. Create a virtual hard disk...VirtualBox disk
image works...dynamically allocated. I want to relocate where it will put the virtual
hard drive (disk image) because I want this to be on my thumbdrive. Excellent. I'm going to drop [storage] to 3GB since it
is a tiny OS. There is no way it will ever use that much
storage. Click Create. Now I have my virtual machine created. Before I can start the virtual machine, I
want to do a few things. I want to disable some options but, more importantly,
enable encryption. So I'm going to select AES-256 plain 64. I'm going to grab my first password out of
KeePass. Double-click on the password field to put
it on the clipboard. You never, ever, ever want to see what the
password is for security reasons. I'm going to click OK. And now the virtual disk image is encrypted. Now I am going to go back into Settings one
more time and I am going to select the IDE option and select the Live CD/DVD mode and
I'm going to choose a file to mount. Now I am going to load the ISO off of the
previously burned CD-R. I'm going to disable audio since I don't need that. I will eventually disable networking but not
yet. Everything else looks okay. I'm going to click OK. Now I am ready to start the virtual machine. And it asks me for the encryption password
right off the bat. I'm going to grab that again. Click OK. Loading everything up. And now TinyCore Linux is running but it is
running off of a Live CD so it still needs to be installed onto the virtual machine hard
drive. I'm going to go ahead and install TinyCore
Linux. Whole Disk -> sda, Next, ext4, [set boot options]. I don't need the GUI, I just need the command
line for all of this, so I'm going to go ahead and just do Core Only (text based interface)
and I don't need any of the other stuff. Start the installation -> Proceed. Now that the installation is completed, I'm
going to exit and reboot...actually, no I want to shut down first. And I'll show you why in just a second. Change my settings. Go to Storage and no more Live CD for you. Remove disc from virtual drive. Click OK. Now I'm ready to boot it up for real into
TinyCore. Of course, it asks me for the password again. I'm going to paste [the password] into the
box. TinyCore is now booted up. The next step is to install OpenSSL, but I
have to first update my audit log. And now the audit log is updated to reflect
the most recent changes. The next step is to get OpenSSL installed
into TinyCore. Gotta sudo reboot (instead of reboot). Oh, and the other thing I need to do is update
my audit log. So I'll do that really quick here. Now my audit log reflects that I have installed
OpenSSL on the VM. I'm going to go ahead and reboot. Okay, OpenSSL is installed, it looks good. Alright, now we are ready to power off the
virtual machine once again. Now things get a little more interesting. We're going to do one change to the settings
of the virtual machine. I'm going to disable the network adapter and
now this virtual machine lives in total isolation from the rest of the universe. Except for one tiny little thing. I also want to disable my host network interface
here. The easiest way to do that is to go unplug
my Ethernet cable. Now my network cable is physically disconnected
from my box. So now my entire machine is totally isolated. [updating audit log] I once again update my
audit log to reflect that I am now fully disconnected from any networking. I forgot to do one minor thing in my virtual
machine. I also need to completely remove the option
for the CD-ROM drive. It's also gone. So no more external CD-ROM drive support. Now we're ready to begin constructing the
Root CA itself. Before I start up the virtual machine, I need
to connect my last thumbdrive to the host. [USB thumbdrive connected and audio chimes]
And now my last thumbdrive is connected to the host. I'm going to go ahead and start the virtual
machine up. It's going to ask for my VirtualBox encryption
password, which I grab from KeePass one more time. Paste it in and click OK. Now I need to mount the thumbdrive that I
just connected. Because I have three identical USB thumbdrives,
it took me a bit to figure out which one I was supposed to mount. Now I need to create the directory for mounting
the thumbdrive. Alright, now I should be able to do 'blkid'
and there we go. The thumbdrive is on '/dev/sdb1' and now I
am mounting the thumbdrive into the OS. Oh, I have to be root to do that. [Looks at thumbdrive directory for verification.] [Sets up directory for the Root CA certificate
and private key.] Now I am going to update my audit log with
everything that I just did. And now my audit log is updated. It is time to create the actual root certificate. This command will create a 4096 bit RSA key
that will be valid for approximately 10 years from today. I've messed up a few times trying to get this
to work. Uh, I've had KeePass crash, I've had all sorts
of weird issues happen, but this is the correct command and I'm going to go ahead and run
it. It will generate a RSA private key and now
it is asking me the PEM passphrase. Going back over to KeePass, and I press Ctrl+V
and to paste the password to the topmost window under KeePass. And then it asks me to do it again. Now OpenSSL asks a series of questions. [Filling in various values.] E-mail address is blank and now we have our
generated Root CA. chmod 400 *.pem. Now I am going to take a quick look at the
Root CA certificate. Specifically, we are looking for CA to be
TRUE. It looks good. So this looks like a valid signed CA certificate. I'm going to sudo copy the certificate to
the mounted thumbdrive. Update the audit log [again]. Now we can see that our CA public certificate
is stored on the thumbdrive. Now we are ready to generate an intermediate
certificate, which will be used to sign all of the other certificates. To do that, I need to create a copy of the
OpenSSL configuration file and modify it so that the intermediate certificate can sign
other certificates. That is, it is its own CA. And this command does that. Now I am going to generate the certificate
signing request (CSR) and private key for the intermediate certificate. This command uses the OpenSSL configuration
file to create a certificate signing request and a 4096 bit RSA private key. The number of days specified here is part
of the request. The CA can choose to honor it or apply its
own number of days. It is just good in this particular instance
to be consistent. 1095 days is approximately three (3) years. OpenSSL is now asking for a passphrase. This will be used to protect the private keying
material as it travels on the USB thumbdrive to its destination. The passphrase can be removed once it has
reached its destination. Fill out the remaining information. A lot of this will look very similar to the
previous information entered for the Root CA certificate. Don't enter anything for the challenge password
or optional company name. Now it is time to sign the certificate signing
request (CSR). [mumbling things as part of the command-line.] This command will sign the certificate signing
request for the intermediate CA with the root CA certificate and private key as well as
utilizing the modified OpenSSL configuration file and setting the serial number of the
certificate to 01. OpenSSL is now asking for the passphrase for
the Root CA private key. Go back over to KeePass and press Ctrl+V.
And this sometimes doesn't work and you just have to retry the command again. In this case, it worked right away. Adjust the permissions of the generated files. View the newly generated certificate and we
see that it is issued by the Root CA. We also want to make sure, scroll down and
make sure that CA is TRUE. So that this certificate and private key can
be used to sign other certificates. And now we are ready to copy the intermediate
certificate...and the encrypted private key. We are now ready to power off the virtual
machine. And I have also updated the audit log with
the commands that were executed. Make sure that everything looks good before
we disconnect all the USB thumbdrives and wrap up. The one thing that is not on the main VM thumbdrive,
even though the main data, 137MB of data, is over here, uh, are all the settings for
the virtual machine. So I'm going to copy those over. Now I have the VirtualBox configuration on
the thumbdrive as well. So if the thumbdrive is put on a new machine,
the VM can be imported and will be fairly straightforward to set up and make it all
work. Move over to the password database on the
second thumbdrive. It looks good. It is tiny (2KB). This poor thumbdrive can hold 16GB and is
being used for a paltry 2KB of data. Finally, we take a look and we see our three
files that we need on our last thumbdrive. We will put it on infrastructure that we will
use for generating other certificates (don't know why I said 'keys'). Once it is on that infrastructure, we might
remove the passphrase from the encrypted private key file. And I have made one final audit log entry
that says that all the data looks good. So now I'm ready to close the audit log and
disconnect the thumbdrives. The last step of the process it to physically
secure the thumbdrives. This concludes the Root CA tutorial. The official blog post accompanying this video
is linked to in the description below. As always, thanks for liking and subscribing
and thank YOU for watching!
