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.