In previous videos we talked a lot
about what's inside of a certificate
but we haven't talked about when you would use these,
and in this video, we'll look at the many uses
for these digital certificates.
One of the most visible uses of these certificates,
is a certificate that allows you to encrypt communication
to a web server.
This is usually indicated by a lock
that's in the address bar of your browser.
We refer to these as domain validation certificates
or DV certificates.
And this means that the owner of this certificate who's
added it to this website server, has
some control over the domain that you're connecting to.
This provides the trust that when
you're connecting to a website, you really
are connecting to the legitimate form
of that particular website.
In the past, you may have also seen
websites with an EV or an extended validation
certificate, that ostensibly additional checks had been done
by the certificate authority, and they've
enabled additional features that would show
the name of the certificate owner in the browser bar
itself, and it's marked in green in the browser bar as well.
These also usually meant that you paid a little bit extra
for the extended validation certificate,
but it made it very clear what websites
you were connecting to.
These days, the use of SSL has become normal
if not expected on a website.
So it's not necessary to promote the fact that you're
running SSL on your server.
If you were to look at the attributes of a certificate,
you'll notice that one of those extensions
is called a subject alternative name or SAN.
This allows the owner of the certificate
to add many different DNS names into this certificate
configuration.
And that means a single certificate
could support connectivity for many, many different websites.
This is common to see on sites like cloudflare which
is providing a reverse proxy service.
So they'll use a single certificate
and that single certificate will support
many, many different sites that are using cloudflare
as a service.
One thing you may notice when looking through the subject
alternative name fields, is that these certificates
can support many different hosts by using a wild card.
The wild card is designated with an asterisk,
and you can see that the asterisk means
that there can be many host names associated
with this particular DNS.
For instance on this certificate,
there is a domain birdfeeder.live and there is
an asterisk.birdfeeder.live which means this certificate
could support .birdfeeder.live ftp.birdfeeder.live
ssl.birdfeeder.live or any other name that you would like
to use, thanks to the wild card associated with this name
in the certificate.
Another use of digital certificates,
is often used when we are distributing software.
A developer will create an executable or a piece
of software that needs to be distributed,
and then they will sign that software with a code signing
certificate.
This means that we can receive that software and install it
and during the installation process,
we can validate that the program that we're installing
is exactly the same executable as the one that was distributed
by the manufacturer.
This lets us know that this software has not
changed since the time it left the developer.
If we're installing the software and it fails this validation
check, that we have the option to decide
whether we'd like to continue with the software installation
or whether we'd like to stop the installation
and determine why this particular code signing
certificate, did not properly validate.
If you're building out a public key infrastructure,
you're starting with a certificate authority.
And that certificate authority needs
a starting point and that starting point
is a root certificate.
All of the signatures and additional certificate,
authority certificates, are starting
with this root certificate.
So if you're building out an intermediate CA,
and leaf CA is beyond that, you will
start with this root certificate and sign everything downstream
from there.
This is obviously an incredibly important certificate,
it is the foundation of your PKI and that
means that you want to be sure that, that certificate remains
safe.
If someone wants to gain access to this root certificate,
they could effectively create any type of certificate
for your organization, which is why
there is so much emphasis put on the security of this root
certificate.
We mentioned in an earlier video that you may not
need to go outside of your organization
to manage certificates, but instead build
your own internal certificate authority.
If you do that, you'll be providing your own signatures
to your internal certificates.
And we often refer to these as self sign certificates.
This designates that we've created
this certificate ourselves, we have signed it internally
and distribute it to our internal devices.
This also means that we didn't go outside of our organization
to have a third party validate this certificate.
This is very common to do, especially
if you have a large number of servers and devices
and you need to create many, many certificates.
You can build them all out and self sign those certificates.
But this also means that you have
to tell all of those devices to trust your internal certificate
authority.
If someone tries to use a device that
doesn't have that trust in place,
a message will appear that say that the certificate is not
trusted.
That's why it's very common to distribute your CA certificates
to all of your devices and that will
ensure that your root CA, intermediate CA, and all
of the other CA which you're using are trusted internally.
As a system administrator, you may
be deploying hundreds or thousands of devices
throughout your organization.
So it's important that if a device
is connecting to your network, that you're
able to tell if that device is a trusted device or not.
One way to do this, is to deploy machine or computer
certificates to all of the devices that need to be trusted
by your organization.
And if someone is connecting to the network and that device
contains one of these certificates,
that it must be trusted by your organization.
A good example of this might be if someone is connecting
through the VPN, and before it gains access
to the internal network.
It provides an additional set of authentication
to check for that certificate.
And if that device validates properly,
we know that, that machine is trusted
by the rest of the organization.
If you're sending or receiving email messages,
you may have the option to enable
encryption or digital signatures.
If that's the case, then you probably
have an email certificate on your system.
This email certificate uses public key cryptography
to be able to encrypt information
so that you can send it in a protected form
through the internet.
And it would also provide a way for you
to receive encrypted messages and decrypt them locally
in your email client.
These email certificates can also
be used for digital signatures.
We can sign any of these emails that we
happen to be sending with this email certificate
and the recipient of this email can
validate that everything in this email
is exactly the same as it was when it was sent
and that provides the integrity.
They can also validate that it was really
us that sent the message providing non repudiation.
Your organization may also distribute user certificates
to every single user.
These can often be integrated into Identification cards
and used as an additional form of authentication.
Their card readers that you can connect to a system via USB
or may be integrated into the device itself,
and that can be used as that additional authentication
factor.
This is often integrated into the smart cards
that we're using so this might be
both a physical identification that
might have your picture on it, and a digital access card
that you can use when logging into your system.