Hello, and welcome to this Pluralsight presentation,
where we take a look at implementing openSSL certificate servers.
We've already seen that we can set up a web server with HTTPS,
but by using a self‑signed certificate,
we have problems with trust relationships and our browsers.
By creating and implementing a certificate authority,
we're going to look at managing the certificate authority from the command line,
and we're going to begin on our AlmaLinux system.
Once we've taken a look at that,
we're going to see how we can then sign certificate requests.
The certificate requests themselves are going to be
made from our client systems, such as our web servers, our database servers,
our identity management servers.
They will create their own public key and private key pair,
but send a certificate request for it to be signed by the CA.
Once we've done this, we're going to look at on our Ubuntu server
implementing HTTPS and the changes that we need to implement to allow
it to work with our CA signed certificate.
We'll have to also make sure that all of the client certificate
databases, they're all of our client machines, not necessarily servers,
but client machines that will be accessing our web servers, our identity
management servers, anything that's using certificates signed by ICA must
trust the certificate authority.
This is often best done through some kind of configuration management system,
but we'll be doing it on each of our systems individually.
Having seen how we can do this through the command line,
we'll also look at some of the fantastic graphical tools
that are available on openSUSE.
A certificate authority doesn't have to be a server as such.
It really is just a system that manages our certificate requests, so there's
no reason why we couldn't perhaps use graphical tools.
What we do need to ensure, though, is that we can guarantee the security
of the system being used to house our certificate authority files. The
lab systems that we are using are AlmaLinux 8.5, this is going to be used
for the command‑line interface version of our certificate authority.
Ubuntu 20.04, where this is where we're going to be using our HTTPS. So
in many respects,
we look at this as being a client to our certificate authority where
we then request our certificate to be signed by the signing
authority. Our openSUSE 15.2 system is also going to come into play,
and we're going to use this to demonstrate how we can set up a
certificate server graphically.
Now the idea of a certificate authority is it's not so much a service, but
a couple of files. Clients only need to trust the certificate of the
certificate authority. So we might have 20 or 30 services that our clients
need to access. Rather than them having to trust all 30 systems, if those
systems have requests that are signed by the CA, then only the CA needs to
be trusted. Servers request their signed certificate from the certificate
authority, and we'll see how we implement that with an HTTPS server.
When requesting the signed certificate,
the server will present its own public key or certificate
through to the CA, and the CA adds then their own public key
through to the signed certificate.
This then becomes the x509 certificate that we use
when presenting to our clients.
Intermediary CAs can also be used, in which case a certificate authority
will issue a signed certificate to an intermediary CA.
It's the intermediary CA that then in turn signed certificate requests
for the client systems, such as the web servers,
the identity management systems, and so forth.
We'll be implementing just a CA, not implementing intermediary CAs when we
look at our demonstration. To create a certificate authority from the command
line, we'll be doing this on our AlmaLinux system.
We can create a directory to house the file, but make sure then that it is
secured in the file system. Setting it to a mode of 700 ensures that only
root has access through to this directory.
We can move into this directory, of course, working as
root, and then we can go through and generate our key. Here
we're setting it to 4,096 bits.
We're using des instead of nodes to ensure that we are going to have a password
to secure this, and again, it should be a strong password.
It's a file system security, as well as our strong password that is
protecting the integrity of our certificate authority.
Once we've done this,
we can go through then and generate the public key or
certificate from the private key.
We can see that we're doing our request to the next 509
certificate. We're using the signing key, myca.key. We'll
be prompted for that password.
We're allowing the CA to last for 10 years.
That's quite normal.
We want it to last a long time, so our trust relationships last a
long time. And then we're going to send out the public key as
myca.crt. And this will be in a .pm format,
a clear text file that we'll be able to read the information from. Now every
single client system that accesses any secure service needs to be able to
trust the certificate authority, and that includes our certificate authority
itself. So we can copy across the certificate through to the correct
directory. On Red Hat‑based systems, it's /etc/pki/ca‑trust/sources/anchors.
Once we've done that, we can update the database by using the
update‑ca‑trust extract.
Now this needs to be done on every one of your client systems.
So normally we're not doing this on a machine‑by‑machine basis.
Often some kind of system management would be in place, such as Ansible or
Puppet or Salt. But we need to make sure that each of the client systems
that we have has this trust relationship in place.
But the idea is that we only need to trust the certificate authority,
not every single server that we access.
So even though it might seem like a lot of work initially, in the long run,
this is going to pay off.
We only need to trust the certificate authority; there is
no need to trust every single server.
Now, having said that,
it's about time when we found ourselves a command line and set some of this up.
Are we ready? Yes, we are!