WEBVTT

00:00.019 --> 00:03.645
>> Implementing PKI solutions.

00:03.645 --> 00:06.030
The learning objectives
for this lesson

00:06.030 --> 00:08.354
are to define trust
models for PKI,

00:08.354 --> 00:11.145
to describe digital
certificates and their uses,

00:11.145 --> 00:13.560
and to explore the
certificate life cycle.

00:13.560 --> 00:15.630
Let's get started. Now,

00:15.630 --> 00:17.900
continuing where we were
from the previous lesson,

00:17.900 --> 00:20.085
we're going to dig a little
bit deeper into this.

00:20.085 --> 00:22.200
Public key infrastructure would

00:22.200 --> 00:23.700
be the software, the hardware,

00:23.700 --> 00:25.410
and the services that all work

00:25.410 --> 00:27.825
together to create
digital certificates,

00:27.825 --> 00:29.720
and also give us
the capabilities

00:29.720 --> 00:31.385
of public key encryption.

00:31.385 --> 00:33.575
It provides public
key encryption

00:33.575 --> 00:35.645
along with identification.

00:35.645 --> 00:39.620
PKI helps us to
prove who a user is,

00:39.620 --> 00:40.850
since each user has

00:40.850 --> 00:42.710
their own unique
digital certificate,

00:42.710 --> 00:45.890
and then that is issued
by a CA that we trust.

00:45.890 --> 00:48.620
By doing this, we now
have non-repudiation.

00:48.620 --> 00:51.710
A user cannot deny who
they are because they have

00:51.710 --> 00:53.270
a unique certificate
that has been

00:53.270 --> 00:55.450
issued by a CA that we trust.

00:55.450 --> 00:58.940
A certificate authority.

00:58.940 --> 01:01.850
This is an entity that is
responsible for the issuing

01:01.850 --> 01:05.090
and then guaranteeing of
digital certificates.

01:05.090 --> 01:06.770
Organizations can set up

01:06.770 --> 01:08.705
their own private
CAs internally.

01:08.705 --> 01:12.140
But when we're doing business
to business sales and work,

01:12.140 --> 01:13.820
we have to have a way of

01:13.820 --> 01:17.060
validating each
business to each other,

01:17.060 --> 01:18.740
so we go on to third parties and

01:18.740 --> 01:20.630
we use third party trusted CAs.

01:20.630 --> 01:22.590
Examples of these
would be Digicert,

01:22.590 --> 01:24.630
Comodo, GoDaddy, and GlobalSign.

01:24.630 --> 01:26.465
When I'm setting up
a public website,

01:26.465 --> 01:28.370
I want everyone to be
able to trust that

01:28.370 --> 01:31.115
my website is who I say it is.

01:31.115 --> 01:33.320
If I used a self-signed
certificate,

01:33.320 --> 01:35.810
then we're back to the fake
ID thing we discussed in

01:35.810 --> 01:38.300
the previous lesson where
anyone could do that.

01:38.300 --> 01:40.205
But if I go to
someone like GoDaddy,

01:40.205 --> 01:42.530
they're going to validate
that I'm who I say I am,

01:42.530 --> 01:45.885
that my organization
is who it says it is.

01:45.885 --> 01:47.430
That helps to prove to

01:47.430 --> 01:49.295
people who are coming
to my website,

01:49.295 --> 01:50.690
or maybe users who are going to

01:50.690 --> 01:52.250
use my apps or customers who

01:52.250 --> 01:53.495
are going to purchase from me

01:53.495 --> 01:56.160
that I really I'm
who I say I am.

01:57.620 --> 01:59.930
Let's go over some
of the functions

01:59.930 --> 02:01.400
of a certificate authority.

02:01.400 --> 02:03.650
They provide
certificate services to

02:03.650 --> 02:07.295
the community that utilize
the certificate authority.

02:07.295 --> 02:10.460
They also ensure that
certificates are valid and that

02:10.460 --> 02:11.810
the identity of those that are

02:11.810 --> 02:13.850
applying for the
certificates is also valid.

02:13.850 --> 02:15.470
This would be true even

02:15.470 --> 02:17.675
though we were setting
up one internally.

02:17.675 --> 02:20.000
Our own internal CA
would need to validate

02:20.000 --> 02:22.280
that Susie is definitely Susie

02:22.280 --> 02:25.040
when we issue that certificate
to her so that we can

02:25.040 --> 02:26.660
validate Susie when she

02:26.660 --> 02:28.960
needs to go throughout
the organization.

02:28.960 --> 02:31.550
CAs also establish trust

02:31.550 --> 02:33.440
of the CA by users, governments,

02:33.440 --> 02:35.480
and regulatory authorities and

02:35.480 --> 02:37.925
they manage these
certificate repositories.

02:37.925 --> 02:39.590
Another function is the key and

02:39.590 --> 02:41.610
certificate lifecycle
management;

02:41.610 --> 02:45.180
they can help us revoking
invalid certificates.

02:46.570 --> 02:50.400
Subordinate and intermediate
certificate authority.

02:50.400 --> 02:52.595
When we're using a
hierarchical model,

02:52.595 --> 02:55.310
a single CA known
as the root CA will

02:55.310 --> 02:58.685
issue certificates to
several intermediate CAs.

02:58.685 --> 03:01.010
This allows for
different CAs to have

03:01.010 --> 03:04.430
different policies and
separate CAs into roles.

03:04.430 --> 03:06.740
Each certificate issued
from these can be

03:06.740 --> 03:09.170
seen as a leaf from
the main root,

03:09.170 --> 03:11.525
which is known as
certificate chaining.

03:11.525 --> 03:14.245
The root CA is a single
point of failure.

03:14.245 --> 03:17.510
We might want to divide up
our organization where we

03:17.510 --> 03:19.160
have a different
certificate authority

03:19.160 --> 03:20.870
for our sales department,

03:20.870 --> 03:22.505
one for our HR department,

03:22.505 --> 03:24.170
and one for our
legal department.

03:24.170 --> 03:25.220
Each of those would be

03:25.220 --> 03:29.850
intermediate CAs underneath
the main root CA.

03:31.310 --> 03:33.815
Registration authority.

03:33.815 --> 03:35.870
The registration
authority will accept

03:35.870 --> 03:38.015
requests for digital
certificates.

03:38.015 --> 03:39.995
It will then validate
that the one

03:39.995 --> 03:43.380
requesting the certificate
is who they say they are.

03:45.830 --> 03:49.405
Certificate signing
requests or CSRs.

03:49.405 --> 03:51.470
These are created on
any device that is

03:51.470 --> 03:54.385
requesting a
certificate from a CA.

03:54.385 --> 03:56.540
It will contain the
information that

03:56.540 --> 03:59.075
the CA will need to
generate the certificate.

03:59.075 --> 04:01.565
Common information would
be the common name,

04:01.565 --> 04:04.530
the subject alternative name,

04:04.530 --> 04:07.625
the organization, the
organizational unit,

04:07.625 --> 04:09.440
the city or locality, the state,

04:09.440 --> 04:13.310
country or region,
and then the country.

04:13.310 --> 04:17.510
When we're doing this, this
helps to identify all of

04:17.510 --> 04:19.490
the organization's
information that will be

04:19.490 --> 04:22.220
contained in this certificate
when it's issued.

04:22.220 --> 04:23.840
If you're doing a self-sign,

04:23.840 --> 04:25.970
you can see this when
you're using OpenSSL,

04:25.970 --> 04:27.860
you can generate your own
self-signed certificates.

04:27.860 --> 04:29.645
It will ask you all
of these questions.

04:29.645 --> 04:31.760
What it's going to be used
for, the common name,

04:31.760 --> 04:33.170
would be the company name,

04:33.170 --> 04:35.495
what the organization
is going to be,

04:35.495 --> 04:39.290
organizational unit might
be that HR department,

04:39.290 --> 04:39.890
that type of thing,

04:39.890 --> 04:42.530
and then more detailed
information about the address.

04:42.530 --> 04:44.945
The public key will
also be included

04:44.945 --> 04:47.330
with the certificates
once it has been issued.

04:47.330 --> 04:48.860
Then the CA will

04:48.860 --> 04:51.840
validate the public
key and this is proof.

04:53.180 --> 04:55.310
This will also have

04:55.310 --> 04:57.315
the information about the
key type that you use,

04:57.315 --> 04:59.615
the key length, the algorithm,
that type of thing.

04:59.615 --> 05:01.760
For example, RSA 2048,

05:01.760 --> 05:04.590
2048 is the bit
length of the key.

05:05.600 --> 05:07.930
Digital certificates.

05:07.930 --> 05:09.200
These are often used to

05:09.200 --> 05:11.060
prove and guarantee
the identity of

05:11.060 --> 05:12.590
website assuming that

05:12.590 --> 05:14.615
the certificate provider
is trustworthy.

05:14.615 --> 05:16.770
If we have a fake or

05:16.770 --> 05:19.160
maybe a less reputable
certificate authority,

05:19.160 --> 05:24.770
they could be issuing
a lot of invalid,

05:24.770 --> 05:26.540
they're actually valid from
the certificate authority,

05:26.540 --> 05:28.420
but they're fake domains.

05:28.420 --> 05:31.610
Because certificates can
be fairly easy to obtain,

05:31.610 --> 05:34.535
it's easy for us to
get these certificates

05:34.535 --> 05:38.090
in four domains that maybe
we shouldn't necessarily do.

05:38.090 --> 05:39.890
A good example here
is Amazon spelled

05:39.890 --> 05:42.110
with an O, amazOn.com.

05:42.110 --> 05:44.780
We actually did this with my
corporation where we set up

05:44.780 --> 05:46.520
a phishing site so we can

05:46.520 --> 05:48.630
do fishing training
for customers.

05:48.630 --> 05:50.855
We set up one that
was similar to Amazon

05:50.855 --> 05:54.155
and we were able to get
a certificate for it.

05:54.155 --> 05:55.790
It took a little bit
because we had to

05:55.790 --> 05:57.440
explain and prove that
we weren't going to be

05:57.440 --> 05:58.460
doing anything
negative with this

05:58.460 --> 05:59.540
because it was
fairly obvious from

05:59.540 --> 06:02.495
the domain name what we're
going to be using it for.

06:02.495 --> 06:05.150
But after proving what
we were going to do and

06:05.150 --> 06:07.070
validating who we
were as a company

06:07.070 --> 06:09.320
as well as myself as the owner,

06:09.320 --> 06:10.510
we were able to do it.

06:10.510 --> 06:13.130
But we also need to
consider domain validation,

06:13.130 --> 06:14.360
and this is when we're proving

06:14.360 --> 06:16.175
the ownership of a
specific domain.

06:16.175 --> 06:18.995
But unfortunately, this is
very easy to compromise.

06:18.995 --> 06:20.930
We have extended validation,

06:20.930 --> 06:22.700
which is a more
rigorous process to

06:22.700 --> 06:24.830
validate a requestor's
legal identity.

06:24.830 --> 06:27.635
It cannot be issued for
a wildcard certificate.

06:27.635 --> 06:28.640
This is what we end up

06:28.640 --> 06:30.035
having to go through
when we set up

06:30.035 --> 06:32.540
our own phishing training
site is they wanted

06:32.540 --> 06:35.940
a more detailed process
to prove who we were.

06:37.490 --> 06:39.845
Wildcard certificates.

06:39.845 --> 06:41.650
This is where the
domain contains

06:41.650 --> 06:42.880
the wildcard character in

06:42.880 --> 06:44.800
the domain name field
for the certificate.

06:44.800 --> 06:47.440
It allows us to use
this certificate for

06:47.440 --> 06:49.090
all of the subdomains
that we might

06:49.090 --> 06:50.590
have and not just
the root domain.

06:50.590 --> 06:53.170
For example, where
we may have had

06:53.170 --> 06:56.725
a certificate issued
for www.domain.com,

06:56.725 --> 06:58.165
with a wildcard certificate,

06:58.165 --> 06:59.320
we would also be able to do

06:59.320 --> 07:04.255
blog.domain.com or
mail.domain.com or anything else.

07:04.255 --> 07:06.850
The wildcard certificate allows

07:06.850 --> 07:08.350
us to use this certificate for

07:08.350 --> 07:10.435
all of the subdomains within

07:10.435 --> 07:13.550
a domain for that
particular certificate.

07:14.780 --> 07:18.070
Let's talk about using
digital certificates.

07:18.070 --> 07:20.815
We can use it for
client authentication.

07:20.815 --> 07:23.950
This is when we're
validating that a client is

07:23.950 --> 07:26.740
authorized to connect to a
given server or service.

07:26.740 --> 07:28.900
An example of this is SSH.

07:28.900 --> 07:32.185
We can configure SSH to use
keys rather than passwords,

07:32.185 --> 07:35.275
and then the client can
use that key to connect.

07:35.275 --> 07:38.245
We can also use them for
server authentication.

07:38.245 --> 07:40.390
This is where clients
can validate that

07:40.390 --> 07:43.225
a server is legitimate
using the same mechanisms.

07:43.225 --> 07:44.920
This is the same as
when you serve to

07:44.920 --> 07:46.960
a website and then
you've checked

07:46.960 --> 07:48.640
the certificate on the site is

07:48.640 --> 07:52.045
actually protecting the site
that it says that it is.

07:52.045 --> 07:54.415
You go to cnn.com and you
look at their certificate.

07:54.415 --> 07:55.720
You want to make sure
that the certificate

07:55.720 --> 07:58.430
is issued to cnn.com.

07:59.509 --> 08:02.640
>> We can also use
digital signatures.

08:02.640 --> 08:04.755
This is public key cryptography

08:04.755 --> 08:07.965
being used so that we can
validate an identity.

08:07.965 --> 08:12.270
Messages can be signed with
the sender's private key,

08:12.270 --> 08:14.610
and then the recipient can
validate the signature is

08:14.610 --> 08:16.350
legitimate by validating that

08:16.350 --> 08:17.805
with the sender's public key.

08:17.805 --> 08:19.650
This is similar to sending

08:19.650 --> 08:21.270
the encrypted message
that we did in

08:21.270 --> 08:23.115
the previous lesson where

08:23.115 --> 08:24.510
instead of encrypting
the message,

08:24.510 --> 08:27.420
we're signing it and when
the person who receives it,

08:27.420 --> 08:28.740
they know that not only can they

08:28.740 --> 08:30.225
prove where the
message came from,

08:30.225 --> 08:31.335
but the message hasn't been

08:31.335 --> 08:33.715
altered while it was
being sent to them.

08:33.715 --> 08:35.900
We can also use digital
certificates for

08:35.900 --> 08:38.210
code signing so that
we can ensure that

08:38.210 --> 08:40.670
the software developers
are who they say

08:40.670 --> 08:41.900
they are and that we can trust

08:41.900 --> 08:44.220
those before we install those.

08:45.350 --> 08:49.965
Trust models. The first
trust model is a single CA.

08:49.965 --> 08:52.590
This is responsible for
issuing certificates and

08:52.590 --> 08:55.935
users only trust
certificates from this CA.

08:55.935 --> 08:57.885
If we have a hierarchical model,

08:57.885 --> 09:00.390
this is a single CA will
issue certificates to

09:00.390 --> 09:02.760
several intermediate CAs who in

09:02.760 --> 09:05.529
turn issue certificates
to subjects.

09:05.529 --> 09:08.705
Each leaf can be traced
back to the root CA.

09:08.705 --> 09:12.240
The root CA again is a
single point of failure.

09:13.810 --> 09:17.465
Cross certification
and trusted providers.

09:17.465 --> 09:20.480
Cross certification is
where a certificate that is

09:20.480 --> 09:24.290
issued to establish trust
between two different CAs,

09:24.290 --> 09:26.330
the CA of one will sign

09:26.330 --> 09:29.125
the public key,
establishing trust.

09:29.125 --> 09:32.370
Trusted providers are
where the root CA,

09:32.370 --> 09:33.990
they can be trusted to validate

09:33.990 --> 09:36.225
the identities of those
that are requesting it.

09:36.225 --> 09:37.860
Browsers contain a list of

09:37.860 --> 09:41.770
CAs that will trust
certificates issued from them.

09:43.130 --> 09:45.885
Certificate profiles.

09:45.885 --> 09:48.780
Certificate profiles
define the type of

09:48.780 --> 09:50.550
certificates that
are allowed and

09:50.550 --> 09:52.875
expected within a
given organization.

09:52.875 --> 09:56.950
An example of this is the
US federal public trust.

09:58.310 --> 10:02.475
Let's talk about the certificate
life cycle management.

10:02.475 --> 10:04.214
We begin by generating,

10:04.214 --> 10:06.675
this is where we create the
certificate to be used.

10:06.675 --> 10:08.700
Then we move it
to the provision.

10:08.700 --> 10:11.535
Then from there it
goes into discover.

10:11.535 --> 10:13.815
Then we move to our inventory.

10:13.815 --> 10:15.270
Now it's ready for use,

10:15.270 --> 10:17.249
and it'd be used in
our organization.

10:17.249 --> 10:19.080
From there we monitor it,

10:19.080 --> 10:20.790
make sure that it's
not being used in

10:20.790 --> 10:22.950
an improper way, we protect it,

10:22.950 --> 10:25.065
we secure it to make
sure that we've

10:25.065 --> 10:26.400
handled it properly and that

10:26.400 --> 10:28.050
we've got our private key saved,

10:28.050 --> 10:29.910
RID symmetric keys
that might be used.

10:29.910 --> 10:31.245
We've got those protected.

10:31.245 --> 10:34.680
We renew it if necessary
because of the validity period,

10:34.680 --> 10:36.480
and then finally,
we revoke it when

10:36.480 --> 10:38.295
that certificate is
no longer needed.

10:38.295 --> 10:40.140
You've got to make
sure when you're

10:40.140 --> 10:41.910
using your digital
certificates that you're

10:41.910 --> 10:43.560
following through this process

10:43.560 --> 10:45.240
because sometimes things get

10:45.240 --> 10:47.700
stuck where maybe a certificate

10:47.700 --> 10:49.380
needs to be revoked that wasn't,

10:49.380 --> 10:51.150
and maybe it was breached and we

10:51.150 --> 10:52.800
never got around to
revoking it and that

10:52.800 --> 10:56.535
can be used to further
breach our organization.

10:56.535 --> 10:58.350
Or maybe it was
time to renew one

10:58.350 --> 11:00.270
and people forgot,
and then it expired.

11:00.270 --> 11:01.740
This has happened
several times in

11:01.740 --> 11:03.810
big profile news
cases where websites

11:03.810 --> 11:05.025
forgot to renew

11:05.025 --> 11:07.650
certain digital certificates
for their websites.

11:07.650 --> 11:10.275
I think there was one
a long time ago where

11:10.275 --> 11:13.770
an engineer had to re-register
the one for hotmail.com.

11:13.770 --> 11:15.420
He had to do that with
his own credit card

11:15.420 --> 11:17.805
because someone just simply
forgot to take care of it.

11:17.805 --> 11:19.950
We have to make sure
we're managing this all

11:19.950 --> 11:21.870
the way through at each stage,

11:21.870 --> 11:24.690
and we don't miss anything
because missing that

11:24.690 --> 11:26.190
can cause serious problems

11:26.190 --> 11:28.690
if we don't take care
of things properly.

11:30.530 --> 11:34.184
Certificate revocation
list or CRL.

11:34.184 --> 11:37.500
From time to time, certificates
will need to be revoked.

11:37.500 --> 11:39.480
We might want to do this because

11:39.480 --> 11:41.565
the certificate has
been compromised,

11:41.565 --> 11:44.115
or maybe it's no longer in
use within an organization.

11:44.115 --> 11:45.660
Or we've changed
our domain name,

11:45.660 --> 11:47.145
or many other reasons.

11:47.145 --> 11:49.110
But CAs will maintain a list of

11:49.110 --> 11:51.975
certificates that have
been revoked or suspended.

11:51.975 --> 11:54.690
This is the certificate
revocation list.

11:54.690 --> 11:57.330
This list is sent throughout
the organization so that

11:57.330 --> 11:58.980
the revoked certificates
are no longer

11:58.980 --> 12:01.960
accepted by any entity.

12:03.350 --> 12:07.635
Online Certificate
Status Protocol or OCSP.

12:07.635 --> 12:10.575
Rather than having them
send the entire CRL,

12:10.575 --> 12:12.360
OCSP can be used.

12:12.360 --> 12:14.370
This allows end-users to query

12:14.370 --> 12:16.620
the status of a
single certificate.

12:16.620 --> 12:18.030
That way they're not
having to download

12:18.030 --> 12:20.370
the entire CRL every

12:20.370 --> 12:22.425
single time they just want
to check one certificate.

12:22.425 --> 12:23.730
In smaller organizations,

12:23.730 --> 12:24.990
maybe this is not
such a big deal,

12:24.990 --> 12:26.100
but in large enterprises

12:26.100 --> 12:28.635
this could become
very cumbersome.

12:28.635 --> 12:31.260
By doing this, it's
kept up-to-date,

12:31.260 --> 12:32.939
and it's easier to distribute

12:32.939 --> 12:35.505
than sending out the
whole CRL to everyone.

12:35.505 --> 12:40.020
Again because of bandwidth
and the number of users,

12:40.020 --> 12:41.850
this could become a very
complicated process.

12:41.850 --> 12:45.280
So using OSEP really
helps cut down on that.

12:46.370 --> 12:48.915
Protecting web traffic.

12:48.915 --> 12:51.330
Certificate pinning is
a technique that will

12:51.330 --> 12:54.285
ensure that when a client
inspects a certificate,

12:54.285 --> 12:56.955
it is inspecting the
proper certificate.

12:56.955 --> 13:01.170
Due to chains, there could
be many certificates in

13:01.170 --> 13:03.450
this entire chain and if one of

13:03.450 --> 13:05.775
these were swapped out with
a malicious certificate,

13:05.775 --> 13:07.290
it would compromise traffic.

13:07.290 --> 13:09.270
We want to make sure
that we're able to check

13:09.270 --> 13:11.520
that all the way through
the entire chain.

13:11.520 --> 13:13.770
Certificate stapling is where

13:13.770 --> 13:15.090
web servers will periodically

13:15.090 --> 13:18.930
obtained the OSEP responses
and these are time-stamped.

13:18.930 --> 13:21.540
When the clients submit
an OCSP request,

13:21.540 --> 13:24.300
the web server will send
the time-stamp response.

13:24.300 --> 13:27.570
This helps to ensure that
that is not being swapped out

13:27.570 --> 13:31.540
because it has a limited
time for its validity.

13:32.990 --> 13:37.935
HTTPS Strict Transport
Security or HSTS.

13:37.935 --> 13:41.160
This is computed as a response
header on a web server.

13:41.160 --> 13:45.510
It will notify browsers to
use HTTPS rather than HTTP.

13:45.510 --> 13:46.890
It helps protect against

13:46.890 --> 13:49.470
downgrade attacks
or SSL stripping.

13:49.470 --> 13:52.350
It's preferred to a
redirect because it tells

13:52.350 --> 13:55.620
the browser to never load
the page if it's using HTTP.

13:55.620 --> 13:58.230
We do this to ensure that users,

13:58.230 --> 13:59.925
maybe they forget to type in

13:59.925 --> 14:04.210
HTTPS and this way it forces
it to happen that way.

14:07.550 --> 14:10.710
Users might not notice
that their connection

14:10.710 --> 14:13.350
has been downgraded
from HTTPS or HTTP.

14:13.350 --> 14:15.480
So this keeps that from
being able to happen.

14:15.480 --> 14:19.210
We're trying to help
users protect themselves.

14:20.150 --> 14:23.535
Let's summarize. This
is a long lesson,

14:23.535 --> 14:25.710
but we went over our
public key infrastructure

14:25.710 --> 14:27.210
and certificate authorities.

14:27.210 --> 14:30.015
We discussed digital
certificates and their uses,

14:30.015 --> 14:31.740
we went over trust models and

14:31.740 --> 14:33.645
their certificate
lifecycle management,

14:33.645 --> 14:36.465
and we also went over
web traffic protections.

14:36.465 --> 14:38.985
Let's do some example questions.

14:38.985 --> 14:42.030
Blank is when a certificate
is used to create

14:42.030 --> 14:45.730
new trust relationship
with another CA.

14:45.920 --> 14:50.460
Cross certification. Question 2.

14:50.460 --> 14:52.470
This type of
certificate allows for

14:52.470 --> 14:55.690
sub domains to be used
with a certificate.

14:55.820 --> 15:00.345
Wildcard certificate.
Question 3,

15:00.345 --> 15:02.460
this is a list of
all certificates

15:02.460 --> 15:03.900
that should not be accepted.

15:03.900 --> 15:06.435
It is maintained by the CA.

15:06.435 --> 15:10.395
Certificate revocation
list or CRL.

15:10.395 --> 15:12.345
Finally, Question 4.

15:12.345 --> 15:14.475
This is an alternative to a CRL.

15:14.475 --> 15:16.350
It provides current
information about

15:16.350 --> 15:20.110
specific certificates
requested by a client.

15:20.360 --> 15:24.495
Online certificate
status protocol or OCSP.

15:24.495 --> 15:25.860
I hope this lesson was helpful

15:25.860 --> 15:28.270
for you, and I'll see
you in the next one.