Introduction to Public Key Infrastructure Concepts

2

Hello All,

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.

Introduction to Public Key Infrastructure Concepts

  • 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:

Introduction to Public Key Infrastructure Concepts

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.

Introduction to Public Key Infrastructure Concepts

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.

Introduction to Public Key Infrastructure Concepts

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.

You can see how to set up the root CA in this post here.

I hope this was informative and thank you foe reading!

Share.

About Author

I am Adil Arif, working as a Technical Support Engineer at VMware as well as an independent blogger and founder of Enterprise Daddy. In my current role, I am supporting infrastructure related to Windows and VMware datacenters.

2 Comments

  1. Hi Adil,

    Nice post, thank you!
    May i ask you a few questions abou pki about templates?

    1. I’ve created a generic ssl web template, published it.
    It’s already used by several servers.
    Now i’d like to modify the template, add admin approval to the template
    How should i do that?

    2. How long should i set the validity period for the key recovery agent template, what’s best practice?

    Thank you very much!

    Best regards,
    Marc Broers

    • Hi Marc,

      Thank you for your kind words!

      If I understand correct, you want to add Admin approval for your web templates. To do so, you will have to change the auto-renewal to false and mention that it requires Admin approval. You have settings for the same.
      https://technet.microsoft.com/en-in/library/cc771107.aspx

      Regarding your second question, the default value is two years! So I believe any value of the same type or below should be fine.

      Hope this helps.

      Regards,
      Adil Arif

Leave A Reply

LIKE WHAT YOU'VE READ?
If so, please join the community.  I’d love to send you exclusive content right to your email, and I’ll send you a free copy of my book, VMware vSphere 6.0 Lab on Workstation too!
Enter your name and email below, and I’ll see you on the inside!

SUBSCRIBE