In this lesson,
we will learn about Certificate Authority (CA) functions.
Certificate Authority functions
include issuing, managing, revoking,
and validating digital certificates
to ensure trust in communications.
Applying Certificate Authority function concepts
requires a good understanding of Certificate Authorities
and Registration Authorities.
Certificate Authorities or CAs
are trusted entities responsible for generating
and signing digital certificates,
thereby establishing the identity of certificate holders
within the Public Key Infrastructure or PKI framework.
Next, Registration Authorities or RAs
act as intermediaries between the end users
and the certificate authorities.
Let's learn more about Certificate Authorities
and Registration Authorities,
and then do a quick demonstration.
First, we have Certificate Authorities.
A Certificate Authority or CA
is the entity responsible for issuing
and verifying digital certificates
within a Public Key Infrastructure.
A Certificate Authority acts as a trusted third party
that guarantees the identities of subjects
by issuing digitally signed certificates
that bind public keys to entities.
This process enables authentication between two parties.
For example, if you trust a Certificate Authority
and I trust a Certificate Authority,
then we can trust each other
because the Certificate Authority that we both trust
has validated both of our identities
and signed our public keys.
This is similar to the transitive property in mathematics
where trust in a third party
enables trust between two entities.
For example, if A is equal to B,
and B is equal to C, then A must also be equal to C.
Certificate Authorities can be either public or private.
Large organizations often establish
private Certificate Authorities of their own
to manage internal communications,
and they do that by creating public
and private key pairs for employees
to securely send and receive signed and encrypted emails.
The main challenge with a private Certificate Authority
is ensuring that all users recognize
and trust that private Certificate Authority,
which is typically managed within an organization
through group policies.
For broader automatic trust across devices and browsers,
public Certificate Authorities such as Verisign,
Let's Encrypt, IdenTrust, DigiCert,
Comodo and GlobalSign are widely recognized
and trusted by default.
Purchasing a certificate
from a public Certificate Authority
ensures that your identity is verified
and trusted by others.
Certificate Authorities perform five key functions
to maintain security and trust
within the Public Key Infrastructure.
First, they provide certificate services
to users by issuing and managing certificates.
Second, Certificate Authorities validate certificates
and verify the identities of applicants requesting them.
Third, they establish and maintain trust
with users, regulatory bodies and enterprises.
Fourth, Certificate Authorities manage the servers
and repositories that store and administer certificates.
Fifth, and last, Certificate Authorities oversee
the entire certificate lifecycle
from issuance to revocation,
ensuring certificates remain secure and up to date.
To handle the significant responsibilities
of running a Certificate Authority,
especially in large scale environments,
organizations often create subordinate
or intermediate Certificate Authorities
underneath the main Certificate Authority.
The main Certificate Authority,
also known as the Root Certificate Authority,
sits at the top of a hierarchical structure
and is the foundation of trust for the entire system.
The Root Certificate Authority
issues certificates to intermediate Certificate Authorities,
which then issue certificates to end entities,
also called Leaf certificates.
For example, a Root Certificate Authority for the military,
might have intermediate Certificate Authorities
for the Air Force, army, Marines, and Navy,
each responsible for issuing certificates
to their respective members.
In this setup, if an Air Force member wants
to communicate securely with a Navy member,
the trust is established
because both of their certificates can be traced back
through their respective intermediate
Certificate Authorities,
to the Common Root Certificate Authority.
This hierarchal structure,
known as Certificate Chaining,
or the Chain of Trust,
ensures that each certificate's validity
is traced back to the trusted Root Certificate Authority
through intermediate Certificate Authorities.
This trust between different branches of the military
helps manage the workload of the Root Certificate Authority
and enhances security across
the entire Public Key Infrastructure system.
Second, we have Registration Authorities.
A Registration Authority or RA
is responsible for accepting requests
for digital certificates,
and performing additional steps
to validate the requester's authorization
to make that request.
For instance, if you try to request a digital certificate
for a domain you do not own, like diontraining.com,
the Registration Authority would deny your request
because you cannot prove ownership of that domain.
In this way, the Registration Authority acts
as the entry point for all certificate requests
in a Public Key Infrastructure.
So, to request a new certificate,
you would generate a Certificate Signing Request or a CSR.
A CSR is a Base64-encoded ASCII file
that you send to the Certificate Authority
to get a certificate,
and it contains the details needed
by the Certificate Authority
to create the certificate and sign your public key.
For example, when requesting a certificate
for a web server, you will include three main groups
of data in the Certificate Signing Request,
your organization's information,
the public key to be signed,
and details about the key type and length.
The organizational information includes fields
like the Common Name or CN,
which is the fully qualified domain name of your server,
such as www.diontraining.com.
Another field is the Subject Alternative Name or SAN,
which allows you to include additional domain names
that the certificate can cover, such as diontraining.net
or diontraining.org.
Certificates that use SAN or Subject Alternative Names
are often called multi-domain certificates
because they can support multiple domain names.
The Organization or O field,
contains the legal name of your organization
such as Dion Training Solutions LLC.
The Organizational Unit or OU field,
can specify a division or department
within your organization.
For example, if I were creating a certificate
for email use, I might list instructors
as the department within Dion Training.
Next, the city or Locality or L field
describes the location of your organization
while the State region or S field
provides the state or region your organization is from.
Finally, the Country or C field lists the country
of operation, such as the United States.
The second group of data in a Certificate Signing Request
is the requester's public key,
which will be included in the final certificate.
The Certificate Authority uses the public key
provided in the request,
and endorses it as part of the validation process.
The third group includes information
about the key length and type.
For example, the Dion Training Solutions LLC
web servers public key, uses RSA encryption
with a 2048 bit key, which is common
for most modern websites.
Now, let's do a demo
and create a Certificate Signing Request.
For this demonstration,
we will use Open SSL on a Cali Linux machine
to show how Dion Training Solutions LLC
requests a web server certificate
from a Certificate Authority called
Totally Trusted CA.
At the start, Dion Training Solutions
does not initially have a public and private key pair,
while Totally Trusted CA already
has its own CA certificate and private key.
During the demonstration, our perspective will start
as that of Dion Training Solutions LLC,
to create and submit the CSR,
or Certificate Signing Request,
and then to process the certificate,
our perspective will shift to that of Totally Trusted CA.
Okay, step one in our process is
to generate a private key
for Dion Training Solutions LLC.
This key will be used in the CSR
or Certificate Signing Request, and should be kept secure.
We'll create this key with this Open SSL command.
This creates a 2048 bit private key
named diontraining_private.key.
Step two, is to generate the Certificate Signing Request
using the diontraining_private.key.
The Certificate Signing Request will include details
about our organization and our public key.
We'll do that with this Open SSL command.
When we run this command, we're prompted to enter
in information about Dion Training Solutions LLC.
In this case, we'll enter our two letter country code as US,
our state or province name as Florida,
our locality name as Orlando,
our organization name as Dion Training
Solutions, LLC,
our organizational unit name as Instructors,
our common name as www.diontraining.com,
our email address as administrator@diontraining.com.
Optional fields like the challenge password
and optional company name,
will be left blank by pressing Enter.
So we've created our Certificate Signing Request.
Step three is verifying the content
of the Certificate Signing Request
that we've just created.
We'll do this by using the following Open SSL command.
This command displays the content
of the Certificate Signing Request
in a human readable format,
showing the details we entered
along with our Public Key Information.
Step four is sending our Certificate Signing Request
to the Certificate Authority.
This is typically done through a web interface,
email, or another secure method.
For demonstration purposes,
we'll simulate that this step is already complete.
Now, in our demonstration,
we're going to assume the identity
of the Certificate Authority
who's just received a Certificate Signing Request
from a company called Dion Training Solutions LLC.
Step one in our Certificate Authority process
is to validate the Certificate Signing Request information.
This will involve verifying
that Dion Training Solutions LLC
owns the domain www.diontraining.com,
and that the organization's details align
with official records.
The depth and thoroughness of these validation checks
will depend on the type of certificate
that has been requested.
Let's assume that all that has been done.
Now having validated the request,
we're going to move on to our
Certificate Authority step two,
creating the Dion Training Solutions LLC digital certificate
and signing it with our Certificate Authority private key.
We'll do this with one long command, right here.
This has created the diontraining.crt or certificate file
that is valid for 365 days.
Step three, is now issuing this certificate,
diontraining.crt to Dion Training Solutions LLC.
Then publishing that certificate
and updating the online certificate status protocol
with the new certificate status.
With the certificate issued,
Dion Training Solutions LLC can now install
this certificate, diontraining.crt on their web server
to enable secure communication with clients.
This is the end of our demonstration.
So remember, Certificate Authorities
are trusted entities responsible
for issuing, managing, revoking
and validating digital certificates
within the Public Key Infrastructure.
They ensure the security of digital communications
by verifying the identities of certificate holders,
and signing their public keys.
Registration Authorities act as intermediaries,
accepting certificate requests
and validating the authorization of the requesters
before the certificates are issued
by the Certificate Authority.
Together these entities manage the entire lifecycle
of digital certificates, ensuring that the process
is secure and trusted.
Understanding these roles is key
to maintaining the integrity
and reliability of secure communications
in a Public Key Infrastructure system.