In this lesson,
we're going to discuss digital certificates.
Now, a digital certificate
is a digitally-signed electronic document
that binds a public key with a user's identity.
Now, when I talk about a user here,
the user can be a real live person like you and I,
or it can be a server, a workstation,
or other device that is assigned a digital certificate.
Now, these certificates are commonly going to use
the X.509 protocol standard
for digital certificates inside of PKI.
And these certificates contain the owner
or user's information, including things like their name,
their organization, and even their public key,
as well as containing all the information
about the certificate authority too.
Now, as we explore digital certificates,
you're going to learn about wildcard certificates,
single-sided and dual-sided certificates,
self-signed certificates, third-party certificates,
the root of trust, the certificate authority,
the registration authority, the certificate signing request,
the certificate revocation list, key escrow agents,
and key recovery agents.
Now, normally, when a certificate is purchased for a server,
it's going to be applied to only one server by default.
So if you paid to get a digital certificate
for diontraining.com,
it's not going to be able to be used for diontraining.com,
www.diontraining.com and courses.diontraining.com too.
But if I use a wildcard certificate,
I can use it for all of those websites.
So this brings us to our first key term,
a wildcard certificate.
Now, a wildcard certificate
is going to allow all the subdomains
to use the same public key certificate
and have it displayed as valid.
Wildcard certificates are easy to manage,
especially if all of your servers
are going to be subdomains off your main web domain.
Now, this is going to allow you to use one certificate.
It'll allow you to save a little bit of money
because you only have to buy one certificate,
and it can make your life a bit easier
because you only have one certificate to manage.
In fact, most of my websites are going to use
wildcard certificates
because of the ease of maintainability,
but with every advantage,
there are some disadvantages you have to consider
if you're going to be using a wildcard certificate.
Now, the biggest one is that if your server
is compromised and that certificate needs to be revoked,
it's actually going to affect all
of your other subdomain servers too.
Luckily, reissuing a new certificate
is a pretty quick process
and you only have to have
one single wildcard certificate to use.
This will allow you to get back online pretty quickly,
'cause you can reissue a new certificate
and push it to all of your servers.
But this is something you should be aware of
when you're deciding whether or not
to use a single-use certificate or a wildcard certificate.
Now, some organizations have multiple websites
that have different domain names too.
For example, I personally have diontraining.com
and jasondion.com.
Now, if I wanted to use one certificate to cover
both of those domains,
and since they don't have the same root domain
of diontraining.com, I would have to modify
what's known as the SAN field,
or the subject alternate name.
Now, if you adjust this subject alternate name field
inside of the digital certificate,
you can use this one certificate
to support both of those domains
instead of using a wildcard certificate.
Remember, if you're using two different domains,
you're going to have to use a subject alternate name field
instead of using a wildcard.
But if everything is on the same domain,
like www.diontraining.com and courses.diontraining.com,
then you can use a wildcard certificate.
Second, we need to cover single-sided
and dual-sided certificates.
Now, let's say for example,
you want to connect to my website
and create a secure session
that can be established between my server
who's going to identify itself to your web browser
using my server's digital certificate.
That would be considered a single-sided certificate.
Now, you aren't required
to have your own digital certificate
to authenticate back to me,
and so because of this,
we only have one side of authentication happening
and we call this a single-sided certificate.
Now, some organizations require both the server
and the user to validate each other using certificates.
When this occurs, we call this a dual-sided certificate.
Now, using dual-sided certificates
is going to be better for security,
but it does require twice the processing power
on the server, so it's only going to be used
in really high security environments.
Third, we have something known as a self-signed certificate.
Now, self-signed certificates are digital certificates
that are signed by the same entity
whose identity it's certifying,
rather than by a trusted certificate authority
or third party.
In essence, the entity is claiming
its own identity and vouches for itself.
Now, these certificates can provide encryption
just like other certificates,
but they don't offer the same level
of trust because there's no external verification
of the user's identity.
Now, there are commonly going to be used in things
like testing environments and closed systems
and non-production systems
where trust is already established.
But anytime you're accessing a site
using one of these self-signed certificates,
it will create a warning
inside of your web browser,
especially for you're using it on a publicly-facing website
because it lacks the endorsement
of that trusted third party.
Now, fourth, we have third-party certificates.
Third-party certificates,
often just called certificates,
are digital certificates issued and signed
by a trusted certificate authority,
which we call a CA.
Now, these certificate authorities
will have their root certificates
embedded into major web browsers
and operating systems,
which means that any certificate they issue
is inherently going to be trusted by that system or browser.
When a user or system encounters a third-party certificate,
they can actually trace its authenticity
back to a known and trusted CA or certificate authority,
and this level of external verification will ensure
a higher degree of trust and security
for online transactions or encrypted communications,
and this makes third party certificates a preferred choice
for any publicly-facing websites
or applications you may be hosting.
Fifth, we have the root of trust.
Now, with digital certificates,
each certificate is validated
using a concept known as the root of trust
or the chain of trust
that moves from the bottom, all the way to the top.
I like to think about this like a family tree.
Let's assume your grandfather is the patriarch
of your family and everybody trusts him.
He then had your father,
and so, since everybody trusted your grandfather
and your grandfather trusted your father,
they're now going to trust your father too.
Then your father had us,
and because nobody really knows
that they should trust us or not,
they look up and say, hmm, well, I trusted your father
and I trusted your father's father who's your grandfather,
and because we can go back up that chain,
we're going to assume that you can be trusted here as well,
and that's the idea.
Your grandfather, in this example,
is the root certificate authority
because he is the highest level
in this particular little family tree.
The family tree is going to be known
as our certification path
in the world of digital certificates.
Now, if I end up having a child,
that child would have to go back up our family tree again
and have our grandfather vouch for junior's trustworthiness
and so on as we go down the family tree.
The rooted trust for most certificates
is going to be a trusted third-party provider
like Verisign, Amazon,
Google, CloudFlare, or some other large service provider.
Sixth, we have the certificate authority.
The certificate authority is the trusted third-party
who's going to issue these digital certificates,
and therefore, the certificate is also going to contain
their name, their digital signature, the serial number
for that certificate, the issue and expiration date,
and the version of that certificate.
To get a digital certificate for your web server,
you do have to purchase that certificate
from a certificate authority
or registration authority,
which brings us to our seventh term,
the registration authority.
For digital certificates to be issued,
the user first has to request a digital certificate
from a registration authority, which is known as an RA.
The registration authority then will request
the identifying information from the user
and forward that certificate request
up to the certificate authority
who will create the digital certificate for the user.
Now, there are many root certificate authorities out there,
including companies like Verisign, Digisign,
and numerous others who can act as trusted third parties
to validate their certificates
are being issued to the correct people.
The certificate authority also maintains
a publicly-accessible copy of that user's public key,
and this allows them to have that for use
by other users who wish to send them
confidential information.
So when you want to go to our web server
for diontrain.com, your web browser is actually going
to our trusted third-party and pulling our public key,
and then using that to encrypt a long random series
of numbers that we can then use as a shared secret key.
But since you encrypted it using
the diontraining.com server's public key,
only that server will be able to decrypt your message,
read that random long series of numbers your system chose,
and then use that to create a bulk encryption tunnel
using symmetric encryption algorithms
like AES with that newly-chosen shared secret key.
Eighth, we have the certificate signing request.
A certificate signing request,
known as a CSR, is a vital component in the process
of obtaining your digital certificate
for your server or other devices.
Essentially, a certificate signing request is a block
of encoded text that contains information
about the entity that's requesting the certificate,
including the organization's name,
domain name, locality, and country.
When an entity desires a digital certificate
from a certificate authority,
it first generates a certificate signing request,
which includes the entity's public key.
The certificate authority will then use the details
in that certificate signing request
to create the final digital certificate
that will be issued back to you.
It's important to note the private key associated
with the request remain securely with the requester
and is never sent out to the certificate authority
because this ensures the confidentiality
of that given key pair.
Once the certificate authority validates
the entity's credentials and processes
the certificate signing request,
the resulting certificate will be returned to the entity
and can be installed on all of its servers
to facilitate secure communications.
Ninth, we have the certificate revocation list,
known as the CRL.
Now, each certificate authority is going
to maintain its own certificate revocation list,
known as the CRL.
This CRL will serve as an online list
of digital certificates that the certificate authority
has already revoked.
Usually this is because those certificates
have become compromised by some kind of data breach.
The certificate revocation list is the full list
of every certificate that has ever, ever been revoked
by that particular certificate authority.
Whenever your computer tries to connect to a new web server,
it's first going to request the current public key
for that digital certificate from the certificate authority.
Now, the certificate authority will first check
the certificate revocation list
before they send you that public key
or digital certificate to ensure
it hasn't already been revoked.
10th, we have key escrow agents.
Now, key escrow is going to occur when a secure copy
of a user's private key is being held
just in case the user accidentally loses their key.
If your organization simply can't accept any data loss,
then you need to ensure that key escrow has been set up,
and you're going to do this by using a key escrow agent.
Remember, whenever you use key escrow,
you have to protect that key store from anybody who's trying
to steal those keys,
and it's recommended that you have at least
two different administrators present
anytime a key is being taken out of escrow.
This is going to help you implement the concept
of separation of duties as well.
This brings us to the 11th thing we have,
which is key recovery agents.
Now, a key recovery agent is a specialized type of software
that allows the restoration of a lost
or corrupted key to be performed.
Think of this as a backup of all
of the certificate authority's keys,
just in case a major incident or a disaster occurs.
So remember, there is a lot going on in the world
of digital certificates and everything in the world
of digital certificates comes down to trust.
If a root certificate authority is compromised
by an attacker, for example, then every certificate
that has ever been issued by that certificate authority
is now considered to be compromised
and they have to be revoked and reissued.
Luckily, this is not a frequent occurrence,
especially with commercially-trusted
third-party certificate authorities,
but if you're running your own certificate authority
within your organization and it gets compromised,
this is something you will need to be aware of,
so you can revoke all of your digital certificates
and then recreate new secure digital certificates
for all of your servers, workstations, and users.