Introduction to Public Key Infrastructure Concepts

Today we will see Public Key Infrastructure concepts and how the entire system works. We will be dealing with a lot of new words for those who are not aware of PKI is and how it can be used in an organization for security reasons.

In the simplest terms, PKI is the framework for encryption that associates a public key with a verified person/system.

We will be covering topics as seen below so that we have better and deeper understanding of the Public Key Infrastructure.

Public Key Infrastructure Overview:

• It is a two key asymmetric encryption system for communication.
• It is the framework (set of guidelines) not a specific technology.
• It is universal infrastructure that can work across multiple systems and vendors.
• Provides authentication and confidentiality.
  1. Authenticity: Uses keys to confirm the owner through Digital certificates.
  2. Confidentiality: Encrypts data transmission.

The Public and Private Key Pair:

Public Key: The part of the key that is available is distributed to the public.
Private Key: The part of the key that is secret and used only by the key owner.

Now let us see an example that shows how to use this set of keys to ensure confidentiality.

• In the first step, you will request for Alice’s public key.
• In return Alice sends her public key to you.
• Using Alice’s public key, you will encrypt the message.
• Then you send that encrypted message across to Alice.
• Now Alice can decrypt that message using her private key which is available only to her.

Digital Certificates:

Digital Certificate are used to verify whom the Public Key belongs to. They help with authentication. They are issued by a Certificate Authority.

Digital certificates have various formats, you can see the x.509 below:

It has information like the Version of the certificate, the Algorithm that is used for encryption, who is the Issuer of the certificate, validity of the certificate and various other things.

Certificate Authorities:

• Responsible for issuing, revoking and distributing certificates.
• Often a trusted third-party organization like Digicert, Verisign etc.
• Companies can also have an in-house certificate Authority.
• Stores the public key in the directory that is available to anyone that wants to verify your certificate.

Now let us look at the Microsoft’s implementation of the Certificate Authority and the various types that are available to us while deploying an in-house CA.

Microsoft enterprise CAs use a person’s user account credentials as proof of identity. In other words, if you are logged on to a domain and request a certificate from an enterprise CA, the CA can authenticate your identity based on your account in Active Directory Domain Services (AD DS).

Every CA also has a certificate to confirm its own identity, issued by another trusted CA or, in the case of root CAs, issued by itself.

Root and subordinate CAs

A root CA is meant to be the most trusted type of CA in an organization’s PKI. If the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization becomes vulnerable.

While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.

A subordinate CA is a CA that has been issued a certificate by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other CAs that are more subordinate.

Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.

Enterprise and stand-alone CAs

At the most basic level, the basic different between a standalone CA and an Enterprise CA is that an Enterprise CA needs to be a member of the domain while a standalone CA does not.

The characteristics of the Enterprise CA are as follows:

• Requires Domain Services. It needs to be online.
• It is most often used for internal purposes.
• It is capable of providing automatic services.
• Domain members trust the CA.
• Uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain.

A stand-alone CA has the following characteristics:

• Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS).
• When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need.
• By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request.

Certificate Revocation Lists:

The CA publishes a list of certificates that can no longer be used.
Reasons that a cert might be on the CRL:

• • Certificate Expiration.
  • Certificate Revocation(Permanent)

— Compromised Private Key
— Human Resources error
— Company changes name, physical address, DNS
— Any reason prior to expiration.

• • Certificate suspended

— Will say “Certificate Hold” as the reason for revocation.

• Certificate Owner/Administrator can request the cert to be revoked.

Now we will be building the a two step PKI hierarchy wherein we will be setting up a root CA which will be offline and in the next step we will installing a subordinate CA which will distribute the certificates.