>> Implementing PKI solutions.
The learning objectives for this lesson
are to define trust models for PKI,
to describe digital certificates and their uses,
and to explore the certificate life cycle.
Let's get started. Now,
continuing where we were from the previous lesson,
we're going to dig a little bit deeper into this.
Public key infrastructure would
be the software, the hardware,
and the services that all work
together to create digital certificates,
and also give us the capabilities
of public key encryption.
It provides public key encryption
along with identification.
PKI helps us to prove who a user is,
since each user has
their own unique digital certificate,
and then that is issued by a CA that we trust.
By doing this, we now have non-repudiation.
A user cannot deny who they are because they have
a unique certificate that has been
issued by a CA that we trust.
A certificate authority.
This is an entity that is responsible for the issuing
and then guaranteeing of digital certificates.
Organizations can set up
their own private CAs internally.
But when we're doing business to business sales and work,
we have to have a way of
validating each business to each other,
so we go on to third parties and
we use third party trusted CAs.
Examples of these would be Digicert,
Comodo, GoDaddy, and GlobalSign.
When I'm setting up a public website,
I want everyone to be able to trust that
my website is who I say it is.
If I used a self-signed certificate,
then we're back to the fake ID thing we discussed in
the previous lesson where anyone could do that.
But if I go to someone like GoDaddy,
they're going to validate that I'm who I say I am,
that my organization is who it says it is.
That helps to prove to
people who are coming to my website,
or maybe users who are going to
use my apps or customers who
are going to purchase from me
that I really I'm who I say I am.
Let's go over some of the functions
of a certificate authority.
They provide certificate services to
the community that utilize the certificate authority.
They also ensure that certificates are valid and that
the identity of those that are
applying for the certificates is also valid.
This would be true even
though we were setting up one internally.
Our own internal CA would need to validate
that Susie is definitely Susie
when we issue that certificate to her so that we can
validate Susie when she
needs to go throughout the organization.
CAs also establish trust
of the CA by users, governments,
and regulatory authorities and
they manage these certificate repositories.
Another function is the key and
certificate lifecycle management;
they can help us revoking invalid certificates.
Subordinate and intermediate certificate authority.
When we're using a hierarchical model,
a single CA known as the root CA will
issue certificates to several intermediate CAs.
This allows for different CAs to have
different policies and separate CAs into roles.
Each certificate issued from these can be
seen as a leaf from the main root,
which is known as certificate chaining.
The root CA is a single point of failure.
We might want to divide up our organization where we
have a different certificate authority
for our sales department,
one for our HR department,
and one for our legal department.
Each of those would be
intermediate CAs underneath the main root CA.
Registration authority.
The registration authority will accept
requests for digital certificates.
It will then validate that the one
requesting the certificate is who they say they are.
Certificate signing requests or CSRs.
These are created on any device that is
requesting a certificate from a CA.
It will contain the information that
the CA will need to generate the certificate.
Common information would be the common name,
the subject alternative name,
the organization, the organizational unit,
the city or locality, the state,
country or region, and then the country.
When we're doing this, this helps to identify all of
the organization's information that will be
contained in this certificate when it's issued.
If you're doing a self-sign,
you can see this when you're using OpenSSL,
you can generate your own self-signed certificates.
It will ask you all of these questions.
What it's going to be used for, the common name,
would be the company name,
what the organization is going to be,
organizational unit might be that HR department,
that type of thing,
and then more detailed information about the address.
The public key will also be included
with the certificates once it has been issued.
Then the CA will
validate the public key and this is proof.
This will also have
the information about the key type that you use,
the key length, the algorithm, that type of thing.
For example, RSA 2048,
2048 is the bit length of the key.
Digital certificates.
These are often used to
prove and guarantee the identity of
website assuming that
the certificate provider is trustworthy.
If we have a fake or
maybe a less reputable certificate authority,
they could be issuing a lot of invalid,
they're actually valid from the certificate authority,
but they're fake domains.
Because certificates can be fairly easy to obtain,
it's easy for us to get these certificates
in four domains that maybe we shouldn't necessarily do.
A good example here is Amazon spelled
with an O, amazOn.com.
We actually did this with my corporation where we set up
a phishing site so we can
do fishing training for customers.
We set up one that was similar to Amazon
and we were able to get a certificate for it.
It took a little bit because we had to
explain and prove that we weren't going to be
doing anything negative with this
because it was fairly obvious from
the domain name what we're going to be using it for.
But after proving what we were going to do and
validating who we were as a company
as well as myself as the owner,
we were able to do it.
But we also need to consider domain validation,
and this is when we're proving
the ownership of a specific domain.
But unfortunately, this is very easy to compromise.
We have extended validation,
which is a more rigorous process to
validate a requestor's legal identity.
It cannot be issued for a wildcard certificate.
This is what we end up
having to go through when we set up
our own phishing training site is they wanted
a more detailed process to prove who we were.
Wildcard certificates.
This is where the domain contains
the wildcard character in
the domain name field for the certificate.
It allows us to use this certificate for
all of the subdomains that we might
have and not just the root domain.
For example, where we may have had
a certificate issued for www.domain.com,
with a wildcard certificate,
we would also be able to do
blog.domain.com or mail.domain.com or anything else.
The wildcard certificate allows
us to use this certificate for
all of the subdomains within
a domain for that particular certificate.
Let's talk about using digital certificates.
We can use it for client authentication.
This is when we're validating that a client is
authorized to connect to a given server or service.
An example of this is SSH.
We can configure SSH to use keys rather than passwords,
and then the client can use that key to connect.
We can also use them for server authentication.
This is where clients can validate that
a server is legitimate using the same mechanisms.
This is the same as when you serve to
a website and then you've checked
the certificate on the site is
actually protecting the site that it says that it is.
You go to cnn.com and you look at their certificate.
You want to make sure that the certificate
is issued to cnn.com.
>> We can also use digital signatures.
This is public key cryptography
being used so that we can validate an identity.
Messages can be signed with the sender's private key,
and then the recipient can validate the signature is
legitimate by validating that
with the sender's public key.
This is similar to sending
the encrypted message that we did in
the previous lesson where
instead of encrypting the message,
we're signing it and when the person who receives it,
they know that not only can they
prove where the message came from,
but the message hasn't been
altered while it was being sent to them.
We can also use digital certificates for
code signing so that we can ensure that
the software developers are who they say
they are and that we can trust
those before we install those.
Trust models. The first trust model is a single CA.
This is responsible for issuing certificates and
users only trust certificates from this CA.
If we have a hierarchical model,
this is a single CA will issue certificates to
several intermediate CAs who in
turn issue certificates to subjects.
Each leaf can be traced back to the root CA.
The root CA again is a single point of failure.
Cross certification and trusted providers.
Cross certification is where a certificate that is
issued to establish trust between two different CAs,
the CA of one will sign
the public key, establishing trust.
Trusted providers are where the root CA,
they can be trusted to validate
the identities of those that are requesting it.
Browsers contain a list of
CAs that will trust certificates issued from them.
Certificate profiles.
Certificate profiles define the type of
certificates that are allowed and
expected within a given organization.
An example of this is the US federal public trust.
Let's talk about the certificate life cycle management.
We begin by generating,
this is where we create the certificate to be used.
Then we move it to the provision.
Then from there it goes into discover.
Then we move to our inventory.
Now it's ready for use,
and it'd be used in our organization.
From there we monitor it,
make sure that it's not being used in
an improper way, we protect it,
we secure it to make sure that we've
handled it properly and that
we've got our private key saved,
RID symmetric keys that might be used.
We've got those protected.
We renew it if necessary because of the validity period,
and then finally, we revoke it when
that certificate is no longer needed.
You've got to make sure when you're
using your digital certificates that you're
following through this process
because sometimes things get
stuck where maybe a certificate
needs to be revoked that wasn't,
and maybe it was breached and we
never got around to revoking it and that
can be used to further breach our organization.
Or maybe it was time to renew one
and people forgot, and then it expired.
This has happened several times in
big profile news cases where websites
forgot to renew
certain digital certificates for their websites.
I think there was one a long time ago where
an engineer had to re-register the one for hotmail.com.
He had to do that with his own credit card
because someone just simply forgot to take care of it.
We have to make sure we're managing this all
the way through at each stage,
and we don't miss anything because missing that
can cause serious problems
if we don't take care of things properly.
Certificate revocation list or CRL.
From time to time, certificates will need to be revoked.
We might want to do this because
the certificate has been compromised,
or maybe it's no longer in use within an organization.
Or we've changed our domain name,
or many other reasons.
But CAs will maintain a list of
certificates that have been revoked or suspended.
This is the certificate revocation list.
This list is sent throughout the organization so that
the revoked certificates are no longer
accepted by any entity.
Online Certificate Status Protocol or OCSP.
Rather than having them send the entire CRL,
OCSP can be used.
This allows end-users to query
the status of a single certificate.
That way they're not having to download
the entire CRL every
single time they just want to check one certificate.
In smaller organizations,
maybe this is not such a big deal,
but in large enterprises
this could become very cumbersome.
By doing this, it's kept up-to-date,
and it's easier to distribute
than sending out the whole CRL to everyone.
Again because of bandwidth and the number of users,
this could become a very complicated process.
So using OSEP really helps cut down on that.
Protecting web traffic.
Certificate pinning is a technique that will
ensure that when a client inspects a certificate,
it is inspecting the proper certificate.
Due to chains, there could be many certificates in
this entire chain and if one of
these were swapped out with a malicious certificate,
it would compromise traffic.
We want to make sure that we're able to check
that all the way through the entire chain.
Certificate stapling is where
web servers will periodically
obtained the OSEP responses and these are time-stamped.
When the clients submit an OCSP request,
the web server will send the time-stamp response.
This helps to ensure that that is not being swapped out
because it has a limited time for its validity.
HTTPS Strict Transport Security or HSTS.
This is computed as a response header on a web server.
It will notify browsers to use HTTPS rather than HTTP.
It helps protect against
downgrade attacks or SSL stripping.
It's preferred to a redirect because it tells
the browser to never load the page if it's using HTTP.
We do this to ensure that users,
maybe they forget to type in
HTTPS and this way it forces it to happen that way.
Users might not notice that their connection
has been downgraded from HTTPS or HTTP.
So this keeps that from being able to happen.
We're trying to help users protect themselves.
Let's summarize. This is a long lesson,
but we went over our public key infrastructure
and certificate authorities.
We discussed digital certificates and their uses,
we went over trust models and
their certificate lifecycle management,
and we also went over web traffic protections.
Let's do some example questions.
Blank is when a certificate is used to create
new trust relationship with another CA.
Cross certification. Question 2.
This type of certificate allows for
sub domains to be used with a certificate.
Wildcard certificate. Question 3,
this is a list of all certificates
that should not be accepted.
It is maintained by the CA.
Certificate revocation list or CRL.
Finally, Question 4.
This is an alternative to a CRL.
It provides current information about
specific certificates requested by a client.
Online certificate status protocol or OCSP.
I hope this lesson was helpful
for you, and I'll see you in the next one.