PKI Concepts – CompTIA Security+ SY0-501 – 6.4

Our public key
infrastructures rely on trust. Usually this trust is provided
by a certificate authority. But what if someone
compromises the CA? This obviously
means that we can’t trust any of the
certificates that were generated by this
particular certificate authority. This is why we will usually
have a root certificate authority that will then
create intermediate certificate authority certificates. And these intermediate
certificate authorities are the ones that then
issue certificates. So this certificate authority
may issue 1,000 certificates, this one may issue 2,000, and
this one might issue 3,000. Once these certificate
authorities are up and running, we can then take the root
certificate authority offline. This means that we’re able
to protect the root CA. If someone does compromise
an intermediate certificate authority, the scope
of the compromise will only be for
the certificates that were issued by that
particular intermediate CA. In our last video,
we talked about OCSP, or the Online Certificate
Status Protocol, and how it’s used to check to
see if any certificates may have been revoked. This is a process that relies
on the certificate authority. But as we found, if we
have many devices that are needing to check in with
the certificate authority, it becomes very difficult
to scale this up into a very large-scale
implementation. Instead of using the
central method to the CA, we can implement OCSP stapling. This means that the device
that holds the certificate will also be the one to provide
status of any revocation. This information is
gathered directly from the device that holds
the certificate rather than going all the way back
to the certificate authority. The revocation status is
stapled into the handshake that occurs initially for
the SSL or TLS communication. There is a
digitally-signed notice in there from the
certificate authority, so the person that does receive
the OCSP-stapled information can trust that it really
did come from the CA. In certain situations,
someone may be able to sit in the middle of an
encrypted communication using a man-in-the-middle attack. One way to prevent
this from occurring is by using certificate pinning. Certificate pinning
is when an application has hard-coded the
server’s certificate into the application itself. The application will then
communicate to the server, receive a copy of
the certificate, and then compare
that certificate to the one that
has been hard-coded into the application. If the certificates
match, then we know that we’re communicating
directly to the server. But if the certificates
don’t match, the application can decide
what to do at that point. It may shut down or
show an error message about the mismatch
of certificates. Certificate authorities
start with a single CA. And if we just have that
single certificate authority, then all of the devices
that receive certificates will use that as the single
authority for everything that’s created. In most environments, though,
we have a hierarchical structure where there’s a root
certificate authority and then there may be many
intermediate certificate authorities under that one. In some environments,
you may choose to mesh these certificate
authorities together. Although, you can see, once you
get to a larger number of CAs, it becomes more and more
difficult to scale this so that you can mash all
of the CAs to each other. An alternative to a
certificate authority is to make everyone
an authority. This is called a web of trust. So I might trust you, someone
else may trust you, therefore, someone else may trust me. This is commonly
used with PGP, where people will sign other
people’s certificates so that a friend of a friend is
someone who could be trusted. And in some environments,
you not only have a scenario where you’re
trusting the certificate from a server, but the
server may be also trusting the certificate from you. We call this mutual
authentication. With key escrow, someone else
may have access, or hold, your decryption keys. These private keys would be
in the hands of a third party and that third party would
have a particular service or particular backup
function to the keys that you would normally
have internally. This may also be part of
a business arrangement, where you may need access to
certain kinds of information, but you may need to
go to a third party to gain access to
decrypt those details. When someone else is holding
these decryption keys, there obviously needs to be
very well-defined processes and procedures. These keys are incredibly
important pieces of information and you need to be sure
they’re managed appropriately. Of course, you need to be able
to trust the third party who will be holding
these keys and you need to be sure that third
party is able to secure the keys properly. In some cases, it may be
very difficult to gain access to these keys from
the third party. It might take legal proceedings
or even court orders to be able to gain
access to the keys, but that may be by design. You may not want anyone
having free access to the keys unless there’s a
very good reason. As we mentioned
earlier, there may not be just a single
certificate-authority. There may be an entire hierarchy
of certificate authorities and there may be multiple
levels within this hierarchy. We call this
connection between all of these different certificate
authorities a “chain of trust.” This would be listing out all of
the different root certificate authorities and then the
intermediate certificate authorities underneath that one. This chain would start
with the SSL certificate that’s part of a web server. You would then see the
certificate authority that assigned that
particular certificate. There might be a certificate
authority above that one. And then, finally, a root
certificate authority above that one. We call these certificates
between the web server SSL certificate and the
root certificate authority “chain
certificates,” or, “intermediate certificates.” And it’s very common
on your web server to configure not only the
SSL certificate you’ve been assigned, but to also
add the chain certificates or intermediate certificates
between that SSL certificate and the root CA.

Add a Comment

Your email address will not be published. Required fields are marked *