Now, moving back to our Ubuntu system,
we need to go through and generate a new key and certificate signing request,
and it's this certificate that we need to pass on back to our AlmaLinux system,
the CA, to have it signed.
As we go through, we can generate our private key.
I'm putting it in the same location as before so it
will override the existing key.
We can then make our certificate signing request.
I'm storing this in my tmp directory,
so it's going to be accessible to a standard user account to copy it across.
We also need to make sure that password authentication is allowed via SSH.
On this Vagrant virtual machine,
password authentication via SSH is disabled by default,
so I enable it, restart the SSH daemon,
and then I can go through and set a password for my vagrant account.
We need this so we can access the system from our CA over SSH.
Now the reality is there's not too much to do here,
so why don't we move out to our command line on Ubuntu and create
the new key and the certificate signing request.
We can ensure that password authentication is enabled within SSH and
ensure that my user account has a password that we can use to
authenticate to from the remote AlmaLinux system.
And here we are, look at this,
the glorious command line of our Ubuntu 20.04 system.
Now we've already got our web server up and running,
but we're going to go through and elevate our privileges and look at
creating a new private key and a certificate signing request,
and of course we want that signing request to be
signed by our certificate authority.
In doing so,
we can easily then create the trust relationship between the CA and
all of our clients that need to use our website.
So going back to our openssl command,
we're going to generate just the private key now.
So rather than generating both the private key and the public key together,
we can go through and use the genrsa ‑out. We can write to the same file
that we had before, so that's going to be /etc/ssl,
and moving into our private directory,
and I think we called it ubuntu.key before. We're
just going to overwrite that file.
This way I don't need to change too much within my configuration.
But there you go, we've got a new private key that we can use.
But, of course, with every private key we must have a
relationship with a public key.
We're going to generate a certificate signing request and
that will become then our public key,
or the certificate to use once it's been signed by the certificate authority.
So we go through and make a request for a new file based on our key.
Now this is where our shortcuts can be useful.
If we use escape and dot, we can pull up then our previous argument,
which of course made reference to our private key.
So don't worry because we use such a long path,
we don't have to always type that out twice.
We're going to then have our certificate signing request sent through to our tmp
directory and ubuntu.csr, for certificate signing request.
We're putting it in a tmp directory so it's easily accessible
by accounts other than the root account.
Now we can go through the same wizard that we saw before,
and again, as we're just doing this as a demonstration,
I'm only going to concentrate on setting the Common Name.
So we can go through and set our ubuntu,
matching the hostname that we use to access it.
We can also go through and set extra attributes.
We can see here a challenge password.
This might be used if we want,
we can enforce it that the certificate authority must know this
password. And we don't need to add in a company name.
So with this done and dusted, we're almost ready to go,
but before we get too carried away with ourselves,
let's just go through and investigate the signing request that we just created.
So, again, the file command could be really useful here.
As we go through and take a look at that,
we can see then that comes in the PEM format and it's a certificate request.
So, of course, more has to be done from this.
One of those things, of course,
though is being able to access remotely the certificate signing request.
So I'm going to make sure that my user account vagrant has a password.
Usually in Vagrant virtual boxes there is no password
because we are using key‑based authentication,
but I can easily go through and use the passwd command
to set a password for my account, so that's done and dusted,
but we're going to need to access this over the wire and via SSH.
In this virtual box, the ubuntu virtual box,
it is set up not to allow password‑based authentication.
So I could easily enable it, I can edit the file directly,
but we can also look at our stream editor sed.
If I go through and do an in‑place edit using s for substituting,
and then I can put a forward slash and the text that I want to search for, so
PasswordAuthentication, be very careful on your typing here, no. That's what I
want to search for, so I then close my forward slash, and the replacement then
is PasswordAuthentication yes. I'm obviously just replacing the yes with the
no. Once we've done that,
close off your quote. That becomes my command that I send through to the
stream editor sed, and the file we need to edit is etc/ssh and
sshd_config. Now, of course, you can edit this in the normal way if you
would prefer, but just be very careful if you are using sed that you've
got the information correct.
Obviously, slight typos here are going to result in
a messed up configuration file.
Now, of course,
we can then use systemctl to restart our SSH daemon, so those settings
are enforced. And we're pretty much ready to go.
Our next steps, though,
are going to be looking at signing the CSR, our certificate signing request,
and that's going to be done from our AlmaLinux system, the certificate authority.