WEBVTT

00:00.029 --> 00:03.950
>> Common certificate
implementation issues.

00:03.950 --> 00:06.310
The learning objective
for this lesson

00:06.310 --> 00:07.420
is to differentiate

00:07.420 --> 00:10.030
the most common certificate
implementation issues.

00:10.030 --> 00:11.710
Let's get started.

00:11.710 --> 00:13.510
When you're ready to implement

00:13.510 --> 00:15.430
certificates in your
own organization,

00:15.430 --> 00:17.335
because there are so
many variables to it,

00:17.335 --> 00:18.860
oftentimes we have errors.

00:18.860 --> 00:20.400
This lesson and is a short

00:20.400 --> 00:21.805
lesson but we're
going to go over

00:21.805 --> 00:24.070
the most common areas where
you might have problems

00:24.070 --> 00:25.360
when you're implementing
certificates

00:25.360 --> 00:26.800
in your own organization.

00:26.800 --> 00:28.795
The first is the validity date.

00:28.795 --> 00:30.460
Every certificate
is issued to be

00:30.460 --> 00:32.095
valid until a certain time.

00:32.095 --> 00:35.470
If you don't renew that
certificate until that time,

00:35.470 --> 00:37.395
then it will be an
invalid certificate.

00:37.395 --> 00:38.590
You might have seen
this when you were

00:38.590 --> 00:40.005
serving to websites,

00:40.005 --> 00:42.630
and then the site did not
renew their certificate,

00:42.630 --> 00:44.270
and your browser will
let you know that

00:44.270 --> 00:46.270
this certificate
has now expired.

00:46.270 --> 00:48.240
Wrong certificate type.

00:48.240 --> 00:51.040
We can generate certificates
for specific purposes,

00:51.040 --> 00:52.850
and when we generate
it for one purpose

00:52.850 --> 00:55.070
but we use that certificate
for something else,

00:55.070 --> 00:57.365
it's going to give us problems.

00:57.365 --> 00:59.479
Revoked certificates.

00:59.479 --> 01:01.610
If your certificate appears on

01:01.610 --> 01:04.220
a certificate revocation
list it's not going to work.

01:04.220 --> 01:05.600
Now, it doesn't

01:05.600 --> 01:07.120
always mean that
something bad happened,

01:07.120 --> 01:08.330
it could have been
that certificate

01:08.330 --> 01:09.800
was revoked by accident.

01:09.800 --> 01:11.690
Someone was cleaning
house and revoke

01:11.690 --> 01:14.055
the wrong certificate,
this does happen.

01:14.055 --> 01:16.355
If you're having problems
with yours and you're getting

01:16.355 --> 01:18.965
errors that indicate a
revoked certificate,

01:18.965 --> 01:22.220
check your CRL to find out
and then take it from there.

01:22.220 --> 01:25.040
We could also use
incorrect names.

01:25.040 --> 01:26.810
If we were to purchase
a certificate

01:26.810 --> 01:28.070
for a website, for example,

01:28.070 --> 01:30.320
and we choose it for abc.com,

01:30.320 --> 01:31.775
but we're actually using

01:31.775 --> 01:34.220
abcc.com, it's not
going to work.

01:34.220 --> 01:36.110
Another example of
this would be if

01:36.110 --> 01:38.630
we didn't purchase a
wildcard certificate,

01:38.630 --> 01:40.520
we just purchased a certificate

01:40.520 --> 01:42.740
for specifically abc.com,

01:42.740 --> 01:45.365
but then we try to use
that certificate for

01:45.365 --> 01:48.990
mail.abc.com it's
not going to work.

01:50.660 --> 01:53.190
We could have chain issues.

01:53.190 --> 01:55.790
The certificate chain
has to be valid all the

01:55.790 --> 01:58.100
way through from the
root to the subordinate,

01:58.100 --> 01:59.524
and then the leaf certificates.

01:59.524 --> 02:01.730
If any part of that
chain is not valid,

02:01.730 --> 02:03.965
then the certificate
is not going to work.

02:03.965 --> 02:05.600
You could also have issues

02:05.600 --> 02:07.425
with a self-signed certificate.

02:07.425 --> 02:09.790
This is where it is not created

02:09.790 --> 02:12.190
and endorsed by a
trusted third party,

02:12.190 --> 02:14.530
it is something you created
and signed yourself.

02:14.530 --> 02:15.940
The study guide will
tell you this is

02:15.940 --> 02:17.385
similar to a fake ID.

02:17.385 --> 02:18.520
For most purposes I don't

02:18.520 --> 02:19.630
agree with this
because there are

02:19.630 --> 02:21.130
many legitimate reasons we would

02:21.130 --> 02:23.230
want to use self-signed
certificates,

02:23.230 --> 02:24.910
but for the purposes of

02:24.910 --> 02:27.265
authenticating yourself
to another party,

02:27.265 --> 02:29.945
then yes, this would be
similar to a fake ID.

02:29.945 --> 02:32.015
Weak signing certificates.

02:32.015 --> 02:33.550
These are weak or deprecated

02:33.550 --> 02:34.840
hashing algorithms that were

02:34.840 --> 02:36.620
used in the creation
of the certificate.

02:36.620 --> 02:38.380
Similarly we can also have

02:38.380 --> 02:40.570
weak cipher suites
where we're using

02:40.570 --> 02:42.415
week or deprecated cipher suites

02:42.415 --> 02:44.995
that have been used when that
certificate was created.

02:44.995 --> 02:47.320
We also have incorrect
permissions.

02:47.320 --> 02:49.390
If we put the files
that are necessary for

02:49.390 --> 02:51.600
the certificate on a web
server, for example,

02:51.600 --> 02:53.450
and then we don't place
the proper permissions

02:53.450 --> 02:54.590
on the files and

02:54.590 --> 02:56.060
the web server is not able to

02:56.060 --> 02:59.310
access those files, we're
going to have errors.

03:01.120 --> 03:03.680
Mismatch keys is when we use

03:03.680 --> 03:07.070
the wrong key pair
to decrypt data.

03:07.070 --> 03:09.200
One key pair was
used to encrypt it

03:09.200 --> 03:11.540
but we're trying to use
another to decrypt it.

03:11.540 --> 03:14.030
Improper key handling
is when we're not

03:14.030 --> 03:16.745
securing the private
or our symmetric keys.

03:16.745 --> 03:18.980
This can lead to a
breach or it could

03:18.980 --> 03:21.380
be that just calling
into question of

03:21.380 --> 03:24.560
whether or not our data is
now secure because we don't

03:24.560 --> 03:25.970
know if those keys were handled

03:25.970 --> 03:28.265
improperly outside
of our control.

03:28.265 --> 03:29.405
If we didn't secure them,

03:29.405 --> 03:32.005
then we can't be sure that
they haven't been used.

03:32.005 --> 03:34.730
Embedded keys are those
that are etched into

03:34.730 --> 03:36.920
a specialized crypto
storage chips

03:36.920 --> 03:38.495
and these are read-only.

03:38.495 --> 03:39.920
If you're using something that

03:39.920 --> 03:42.515
needs access that's
more than read only,

03:42.515 --> 03:44.455
you need to keep this in mind.

03:44.455 --> 03:47.480
Rekeying, the session keys are

03:47.480 --> 03:50.480
renegotiated during a
communication session.

03:50.480 --> 03:53.660
This is done often so that
we can make sure that

03:53.660 --> 03:55.310
one key is not used to encrypt

03:55.310 --> 03:57.380
all the data that's
going through.

03:57.380 --> 03:58.850
Now, often this is triggered

03:58.850 --> 04:00.500
because the data volume reaches

04:00.500 --> 04:02.150
a certain threshold rather

04:02.150 --> 04:04.860
than an amount of
time has passed.

04:06.110 --> 04:09.020
Crypto shredding,
this is when we

04:09.020 --> 04:12.235
destroy the key that was
used to encrypt data.

04:12.235 --> 04:15.065
This will destroy
access to the data

04:15.065 --> 04:17.520
because if we don't have a
key to decrypt it any longer,

04:17.520 --> 04:19.175
then that data is destroyed,

04:19.175 --> 04:20.420
no one can get to it.

04:20.420 --> 04:21.980
But it's very important we make

04:21.980 --> 04:23.780
sure that when we're
destroying these keys,

04:23.780 --> 04:26.095
that those keys themselves
cannot be recovered,

04:26.095 --> 04:27.560
and this is especially important

04:27.560 --> 04:29.455
for cloud implementations.

04:29.455 --> 04:32.210
Cryptographic obfuscation,
this is when we

04:32.210 --> 04:35.200
transform protected data
into an unreadable form,

04:35.200 --> 04:37.325
and this is usually
used for storage.

04:37.325 --> 04:41.330
A good example of this is
the Linux ETC shadow file.

04:41.330 --> 04:43.040
Key rotation is when we

04:43.040 --> 04:44.695
revoke a key and
issue a new one,

04:44.695 --> 04:46.825
and we do this through
a periodic basis.

04:46.825 --> 04:48.620
We do that because
we're trying to

04:48.620 --> 04:50.765
prevent brute force
attacks on the keys.

04:50.765 --> 04:52.100
If the key is changing,

04:52.100 --> 04:55.420
it makes it harder for
that key to be attacked.

04:55.420 --> 04:58.495
Compromise keys,
this is when we had

04:58.495 --> 05:00.730
unauthorized access
to our symmetric key

05:00.730 --> 05:01.930
or our private keys.

05:01.930 --> 05:03.670
Because of this,
you consider you've

05:03.670 --> 05:05.290
been breached and
it's time to revoke

05:05.290 --> 05:09.720
and reissue keys.
Let's summarize.

05:09.720 --> 05:12.340
We discuss common digital
certificate issues

05:12.340 --> 05:14.785
along with common
cryptographic key issues,

05:14.785 --> 05:18.935
so let's do some example
questions. True or false.

05:18.935 --> 05:21.595
Crypto shredding
turns protected data

05:21.595 --> 05:24.590
into an unreadable
format for storage.

05:25.130 --> 05:28.780
False, cryptographic
obfuscation does this.

05:28.780 --> 05:30.490
Crypto shredding is
the destruction of

05:30.490 --> 05:34.810
the decryption key that was
used to encrypt the data,

05:34.810 --> 05:38.060
and by doing that we've
made the data unusable.

05:38.510 --> 05:41.750
Question 2, blank is purposely

05:41.750 --> 05:45.410
changing keys to protect
against brute force attacks.

05:45.410 --> 05:49.800
Key rotation. Question 3.

05:49.800 --> 05:51.440
This type of issue occurs

05:51.440 --> 05:53.210
because an expired
certificate has

05:53.210 --> 05:57.450
been used. Validity dates.

05:57.950 --> 06:00.150
Finally Question 4,

06:00.150 --> 06:01.790
these keys are etched into

06:01.790 --> 06:04.340
specialized cryptographic
devices that are only

06:04.340 --> 06:09.045
available as read-only.
Embedded keys.

06:09.045 --> 06:10.370
Hope this lesson gave you

06:10.370 --> 06:12.470
some ideas on some areas
you could look for if

06:12.470 --> 06:13.595
you're having problems with

06:13.595 --> 06:15.815
certificates in
your organization,

06:15.815 --> 06:17.480
and keep these in
mind for the test

06:17.480 --> 06:19.760
because they're generally
going to ask you just

06:19.760 --> 06:22.790
those little these types

06:22.790 --> 06:24.350
of questions where
just to make sure

06:24.350 --> 06:26.600
you understand how you would
go about troubleshooting

06:26.600 --> 06:30.300
these problems. I'll see
you in the next lesson.