- In this lesson, we're gonna talk
about digital certificates
because I bet you've been wondering where do these keys come
from that we've been talking about,
these private and public keys.
Well, they come from our digital certificates,
and we're gonna look at how and why.
Digital certificates are the mechanism
used to generate a private key
and to bind the public key to its owners.
The digital certificates are issued by commercial entities,
but alternately, you can actually self-generate
a digital certificate.
Not a particularly good idea, and I will be explaining why.
Now, the X.509 standard currently defines
the certificate format and fields for public keys.
That same standard X.509
also defines distribution procedures,
and we talked about the fact that public keys
are freely distributed
and the current version of X.509
for our certificates is version three.
Now, there are lots of different types
of digital certificates
'cause digital certificates are designed to prove ownership,
who somebody is, as well as produce
those public and private keys.
So we have personal, machine, domain, organization,
extended validation, code and object signing,
and trusted and intermediate.
Personal verifies the user's identity.
Machine verifies the device identity.
Domain verifies a domain including wild cards
for sub-domains.
An organization verifies a domain and an organization.
An extended validation verifies a domain
and an organization subject
to a standardized global verification process.
We used to know that as the green bar
because the URL bar would turn green.
It doesn't turn green anymore,
but it's now known as extended validation.
Then we have code and object signing,
which verifies origination
and ownership as well as the object integrity.
And lastly, trusted and intermediate certificates
which verify our root
and intermediate certificate authorities.
When you get a certificate,
it will have a finite lifecycle, right?
If you create one, well, it can go on forever,
but again, you really don't wanna create your own
and use them out in the public domain.
Commercial digital certificates have a finite life span
from enrollment to expiration.
Effective September 1st in 2020,
the certificates were valid for a year.
Certificates do need to be renewed
at the end of their life
to avoid service disruption and decreased security.
And there are scenarios where a certificate
may need to be replaced or retired early.
Perhaps there's a compromise of the private key
or there's organizational changes
or maybe it's even no longer needed.
In your browser, you can look at certificates.
You can just take a look, right?
If you're at a secure place,
you'll just see a little lock up in the URL,
and you can click on that dropdown,
and go into the certificate viewer
and look at the certificate.
Our browsers also have a built-in trust
with certificate authority.
So when they see a certificate,
it's come down to your system,
you know that has been issued by a trusted authority,
then there is transient trust or an inheritance of trust.
Now, I did mention that certificates
can be self-generated and self-signed,
so you can make them with your operating system,
you can make them with a Linux operating system,
you can make them with a Windows operating system,
but they're not a good idea.
A self-signed certificate can easily be impersonated.
If you go to use it out in the public domain,
it will present a big warning message
like, this certificate should not be trusted.
You have no way of pulling it back.
It can't be revoked.
So why would you ever create a self-signed certificate?
Really, the use case is internal development.
Maybe you're developing a secure app,
or you're doing some testing for an HTTPS website.
You may create a certificate just for testing, you know,
and development purposes.
Now, there is a way to get self-signed certificate
a modicum of trust by using what's known as a web of trust,
in which case, self-generated certificates can be signed
and validated by other users.
But generally speaking, we're gonna use commercial entities
like Network Solutions and GoDaddy and Thawte
and a host of others, right,
these commercial entities to generate our certificates.
Now, digital certificates are issued
by those commercial trusted parties,
and we refer to them as certificate authorities or CAs.
Our browsers and our devices trust
those certificate authorities
by accepting a root certificate into its root store,
which is really just a database
of approved certificate authorities
that will come pre-installed,
as I mentioned a moment ago,
with your browser or your device.
The certificate authority is who we go ask
for a certificate,
so the certificate authority receives certificate requests,
validates the application, issues a certificate,
and then publishes the ongoing validity status
of the issued certificates.
Now, there is kind of a subset of a CA known as an RA,
a registration authority,
and they offload some of the work from the CA
that they can actually accept
and process the registration request
and distribute the certificates
but they can't create the certificates.
So let's look at the certificate request process.
You go to the commercial entity
and the first thing it's gonna have you do
is actually generate your public and private key pair.
Then the applicant will submit a certificate signing request
which is you'll be sending the public key back
to the certificate authority.
You're going to keep your private key.
It's never going to go to the certificate authority.
And identifying information.
Now, what that information will be will depend
on the type of certificate.
Then the CA, or maybe the registration authority,
will validate the identity of the applicant.
The CA, the certificate authority,
is gonna generate the certificate
and sign it with their private key.
Their private key says, I'm the one, right,
who is signing it.
The CA or the RA will send the certificate
back to the applicant, and at that point,
their certificate is ready to be used.
Now, how do we know that a certificate is valid?
Well, there's really two ways.
One is using what's known as a CRL.
A CRL is a certificate revocation list.
The CA, the commercial authority,
maintains a list of certificates that have been revoked,
and we have two models, a pull model and a push model.
In a pull model, a CRL is downloaded
by a user or the organization.
A push model, the CRL is automatically sent
out by the certificate authority at regular intervals.
But there's a much more efficient way to do that,
and that's using a protocol known as OCSP,
online certificate status protocol.
Now that's a process that's designed to query
the status of a certificate in real time.
And a version of OSCP is known as OCSP stapling.
OSCP stapling is a time-stamped, or cached, OCSP response.
And that brings us to the end of certificates
and the beginning of a three-second challenge.
Are you ready?
Five challenge questions, three seconds each.
Mechanism used to generate a private key
and to bind a public key to its owner.
It's what this whole lesson has been about.
One, two, three.
It's gonna be a digital certificate.
Question two, digital certificate standard.
One, two, three.
That's X.509.
Question three.
Commercial entity that issues trusted certificates.
What are they called?
One, two, three.
It's gonna be a certificate authority.
Number four, the type of certificate
that subjects an organization
and the associated domain to additional vetting.
Remember, I said that it used to be called the green bar.
One, two, three.
And that's extended validation.
And lastly, number five,
protocol used to query the status
of a certificate in real time.
You're thinking it's oh, oh, oh, something.
One, two, three.
OCSP, online certificate status protocol.
That brings us to our security-in-action.
Your organization recently established a relationship
with a new vendor.
When you connect to their site, the following security alert
for the certificate is presented.
So what does it mean?
So you can see that there's all kinds of problems, right?
You get a message that says information you exchange
with the site cannot be viewed or changed by others.
However, there's a problem
with the site security certificate.
The security certificate was issued
by a company you have not chosen to trust.
The security certificate date is valid, that's good,
and the security certificate has a valid name matching
the name of the page you're trying to open,
but it got that big explanation point.
Security certificate was issued
by a company you have chosen not to trust.
And it goes on to say, view the certificate to determine
whether you want to trust the certifying authority.
Hmm, so you get that message.
What do you think it means?
Go ahead and put me on pause,
think about it for a few minutes, write down some notes,
and then come on back and we'll talk about the meaning.
Well, the message is warning you
that the certificate has not been issued
by a trusted authority, or at least not one that you trust.
Now, this is a really big red flag,
and your organization should absolutely proceed
with caution.
Now, what I would do in this case is I would get right
on the phone and/or the email and contact the vendor, right?
That the vendor should be contacted
before you attempt to connect to the site,
and say, Hey, what's going on here?
Then most likely what happened is the certificate
was self-signed by the issuing party.
The self-signed certificates are not validated
for authenticity and they're not gonna be trusted.
And of course, they also can't be revoked
if there's an issue.
Now, if it's self-signed,
either the vendor doesn't understand
the security implications,
so that's a big red flag, right?
You definitely wanna talk to 'em about that.
Or perhaps, a development site was published in error,
or maybe you were just sent a link for the development site
and they actually do have a correct site.
In either case, right,
you wanna be on the phone asking them.
Now there is another option
and the other possibility is that the site is being spoofed,
that someone has a fake site up there,
did a self-sign certificate, sent you the link,
and now you're at a spoofed or an impersonated site.
Again, once again, reason to be talking to your vendor,
say this is what I have, is this legitimate?
Being able to look at a certificate error messages like this
and say, wait a minute, something's fishy, something's up.
This is what I'm gonna research
and how I'm gonna respond to it,
that, my friends, is absolutely security in action.
That takes you to the word cloud.
You know what to do.
When you're ready, come on up to the next lesson,
and we're gonna be talking about emerging cryptography.