Now, of course, we've been able to test our connection has been okay.
We've seen a little bit about our certificate information,
but not too much is available necessarily through a standard browser.
Using the openssl command again, and the s_client module,
we can go through and connect to a website and interrogate the SSL information,
which, of course, has all of the information on the certificates and issuers.
We can also just look at specific information to show those certificates,
so ‑showcerts.
We can do this to our own server, but we can also do it to public servers,
and it can be quite then interesting to take a look at this.
So we're going to move out to our command lines where we're going to start
verifying some of this HTTPS our certificate information.
We're going to do it by checking that our redirect is working; however,
kind of we already know that.
We tested that before.
But we can test it using openssl and w3m,
but more importantly,
we want to check with openssl and see how we can use
the command to test our connections.
And look at this, our glorious command line,
and a command line where we're running as a standard user.
The reality is we shouldn't be running elevated
privileges if we don't need them.
And we don't need it in this case to run openssl when
we're just running our s_client module.
This can be used then to test connection through to SSL sites.
So we can go through and specify the option ‑connect to Ubuntu on 443.
As we hit our big Enter key, we can see we get lots of information coming back.
Now, we can see we don't get the prompt at the moment.
I can try and arrow around, and we're just getting weird characters,
and now as I hit the Enter key, we can see then that we're getting a bad request.
That was because we were in the negotiation as to
what certificates we wanted to use.
We didn't complete the correct request, so we're getting a bad request.
We could also just leave it to time out, and that would work for us as well.
But if we up arrow key,
we can also drill down to see specific information that we want.
So if I go through and use the option ‑showcerts,
well, you can probably guess,
we're going to show the certificates. Now, of course though, again, we get a
lot of information coming back, and we can see we're into that read block at
the moment where it's expecting us to send requests back. I can allow it just
to time out so we can see the connection has been closed, but it still comes
back as a bad request.
Now I could try scrolling back so we could read the information, but,
of course, there are better ways to be able to do this. And this is
where our good friend less will come in. If I up arrow key and pipe the
output through to the less command, the first thing we see at the top
is the certificate chain.
We have s and i, that's subject and issuer.
This is what we mean by self‑signed, where the subject and issuer are the same.
As we move further down, we get to look at our server certificate, and again,
we can see the subject issued to Ubuntu, but who issued it, Ubuntu! So again,
we get more validation. Even when we look at the server certificate, rather
than the issuing certificate, we can see then that this is self‑signed.
We can see a little bit more about the protocol that's being used here, so
TLSv1.3. And again, we can just follow our way through the rest of the
information, and we can see again our connection has been closed off now as
we failed to negotiate what we wanted to use. But that's okay, we're just
looking at the information.
Well, okay, that's looking at our own system, but it can be much
more fun when we go through and take a look at someone else's
system. And this is perfectly okay.
This is normal browser activity where we negotiate what's going to be used.
So again, I'm still using less, but using the up arrow key to change,
and we can go through and look at pluralsight.com.
Let's go through and interrogate the certificates that they are
using. Now, when we first look at now our certificate chain, we
can see the subject and issuer.
The subject is then to *.pluralsight.com, and we've got the issuer
then being Go Daddy, the certificate authority.
But there will be multiple certificates in this chain, and we're going to be
able to go through and investigate this a little bit more.
So as we continue through, our next stop or port of call is going to
be taking a look towards the bottom of the screen now where we can
see the subject and issuer, and we can see that we've got the issuer
being the root certificate authority and then being issued to our
intermediary authority.
As we continue our way down, we're able to see the certificates
that make up this chain, so we can see that at the top of the
chain, we've got our certificate authority and then intermediary
authorities in between.
At the very end, we then have our final server certificate, and this is then
for pluralsight.com that's been issued by one of our intermediary authorities
controlled by the root authority from Go Daddy.
So it gives us an idea or an insight into the way these certificate chains work.
We can continue through. Again, we get to the end where we then not
answered their request, but we understand now that this is a negotiation
and we're failing to negotiate. But it's great to be able to get some
insight into what's inside of a signed server certificate and the
difference between a self‑signed certificate and those where a certificate
authority have been involved. And in our next module, we'll be taking a look at our certificate authorities.