So welcome to our first demonstration,
a demonstration where we're going to dive through to the
command line to create the certificate authority.
We'll be working on our AlmaLinux system,
and we'll be creating the certificate authority from the command‑line interface.
Once we've created the public key, the certificate for our certificate authority,
we're going to move that certificate into our client trust database.
We'll talk more about that whilst we're doing that,
but that's where we need each of our clients to be able
to trust the certificate authority.
Come on, let's go find that command line.
Now I'm working at the command line on my AlmaLinux 8 system,
and we're going to gain our root privileges,
so I can do a sudo ‑i.
Once we're here, we're going to create a directory.
I'm in the home directory, so I'm just going to go mkdir,
and we're going to go through and specify the mode,
the permissions, and we can make sure then that it's set to 700.
So this directory is definitely only going to be accessible by root.
The more belt and braces security that we can put into place,
the more secure this is going to be.
So don't just think because it's in a root user's home directory,
nobody will have access to it.
Why not secure the directory itself?
I'm just going to call this ca.
We can move into that, so cd, and Escape and dot just brings up my last argument,
and I can print then the working directory where we
can see that we're in /root/ca.
Where we create the certificate authority doesn't really matter,
other than the security that we're creating around it.
There is not an overriding service that looks for files in a certain place.
We manually will go in and sign our certificate
request using the certificate authority.
Of course, this is a brand‑new directory,
so as I go through and list it, even if I do an ls ‑a,
we can see that we don't have anything here.
So I can clear out and carry on my generations.
So that's going to be openssl, and we're going to create the private key,
so genrsa.
We're going to use ‑des now to make sure that we are
going to be prompted for a password,
so we can encrypt with des encryption our private key.
To open it, we'll need to provide the passphrase.
We want this for security.
We can specify where we write out to, and I'm just going to call it myca.key.
Obviously, I'm in the CA directory, so it's going to be /root/ca/myca.key.
We can set a higher bit strength than we had before.
Again, security is the key here.
As we go through, we're prompted now to secure it.
This is then going to encrypt my private key with ‑des encryption.
And we should be choosing a strong password.
As I go through, again, using ls ‑a, we're not hiding anything from you.
We can see now that we've just got this private key.
If I go through and use the file command,
we can interpret what type of file this is,
and if I use then myca.key,
we can see then that this is a PEM formatted RSA private key.
We now need to create the certificate from this.
So we can go through our openssl again.
I'm going to move this to the top of the screen.
We can set up our request.
And we're requesting an x509 certificate.
This is all coming from new.
We don't have an existing public key to refer to.
So I can then go through and specify that this is all from new,
‑new ‑key, the private key that we want to use.
So this then becomes the key we've just created,
myca.key, and of course,
I need to know the passphrase of that to be able to use it.
We can set up then our sha256 cipher.
And as we continue, we can specify in this case,
as this is our certificate authority, I'm going to set up 10 years.
On our keys that we sign for servers,
generally we don't have longer than one year,
but this is a certificate authority.
We're setting this up to be trusted for 10 years because we
need to have a big effort in pushing this all out to every
single client in our enterprise,
and we don't really want to have to do that every year.
So, 10 years is certainly nothing to be concerned about.
Minus out, that's the name of the file that we write to,
so I'm putting myca.crt.
Some people use .pem, but .crt is fine.
We, of course,
have to put in the passphrase to give our authority to use the private key.
Remember, we're saying when we're creating that private key,
it should be a strong password.
Now we get into what we've seen before with our wizard.
We're going to go through and leave everything at the default.
It's less important on the common name now because people
aren't accessing this as a host itself.
The certificate authority is not so much a service,
but just the two files, the certificate and the private key.
So even though my hostname is going to be Alma 8,
I'm just putting almalinux here, and that will be good enough.
Of course, though, if you are working for an enterprise,
you're probably going to put in more of that enterprise details,
so you're documenting the solution that you've created.
We've created stuff, haven't we?
Let's go through and list that.
So we can see then the private key and we can see the certificate file we've
just created, and we can further interrogate that certificate file. And say,
I put a .crt for certificate as my extension.
Many people put .pem. When we go through and take a look at it, again,
we're going to see that this is a .pem file, which is really just saying
they're using clear ASCII text inside. Now,
believe it or not,
this is our certificate authority up and running in its very basic sense.
However,
the whole idea of this certificate authority is the single
trust relationship, that our clients,
the clients are the devices that use clients, such as browsers,
to access web servers is those clients that need to trust the
certificate authorities' certificate.
So we've got to find ways of injecting that into our systems. Now, quite often
we could look at in an organization we would use configuration management
products, like Puppet or Ansible to push them out.
If you're working in an Active Directory environment,
you might well be using Group Policies to push it out to your Windows desktops.
So there are many ways that we can do it; however,
we're going to be looking at pushing it out individually to each of our
clients, as we're only going to be working with a couple of clients. Makes
it easy for us to carry it out directly from the command line. And working
on the AlmaLinux, which is based around Red Hat, we can copy myca.crt, and
we can then go through and copy this across to our /etc/pki/ca‑trust and
source/anchors directory.
It's this directory that we can use then to update our database.
When we take a look at it, though, inside of this directory, we're going
to have just the one certificate that we've added in.
This isn't the database itself,
it's the source of where we get our certificates from.
So our certificate authority certificate is in here, but this,
as I say,
is not the real database. Why have we put it in here? Well, this is where it
looks for it to add to the database. The database itself, we can look in the
extracted directory, and when we see we've got subdirectories here looking at
different types of files that we can add in. And these are very much put in by
the operating system supporting so many of our root authorities that we need to
make the internet and infrastructure work for us. Using the command
update‑ca‑trust and extract, we then go through to our anchors directory and add
the certificate that we find from there, adding it in through to the correct
location in our database. Now, we don't get any feedback, but it will have
worked.
We've kind of just got to trust that it works.
We'll see on the Ubuntu system when we run it on our Ubuntu system,
it's a little bit better is it gives you feedback. But there you go.
We've now got our certificate authority and at least one
client trusting our certificate authority.
But we've now got to start issuing certificates through to our devices,
and that's what we're going to be looking at now,
making sure that our web server can work in a more robust way having a trusted root certificate sign the certificate for our web server.