Components of a PKI, Part 1: Digital Certificates

Preface: Components of a PKI

Public key infrastructure (PKI) is a core technology in the identity and security stack. This technology uses encryption to allow entities such as an individual or device to be uniquely identifiable and able to store or transmit information securely. All modern organizations use PKI in some form or another. The digital certificate on a website that protects customers’ privacy and data is an example of PKI in action.

Fortunately, the fundamentals haven’t changed significantly since PKI was formally introduced in the X.509 standard in 1988. In this five-part blog series, we cover a few of the most important PKI components:

1. Digital Certificates
2. Certificate Authorities and CA Hierarchies
3. Certificate Revocation
4. Active Directory Certificate Services
5. Hardware Security Modules

Part 1: Digital Certificates

Digital certificates (most commonly represented by the X.509 public key certificate standard) are signed data objects that associate a public key with an individual user, device, or entity. In this case, we’re specifically referring to digital certificates formatted using the X.509 standard.

How Do Certificates Protect Your Data?

From a cryptography perspective, a public/private key pair is generated during the digital certificate generation process. The relationship between the key pair is asymmetric; information encrypted with the private key can be decrypted with the public key, and information encrypted with the public key can be decrypted with the private key.

In Figure 1, Bob is sending a private message to Alice. In this example, the following steps occur:

1. Bob encrypts his message using Alice’s public key (published online).
2. Bob sends the encrypted message to Alice over an untrusted network.
3. An attacker intercepts the encrypted message. The attacker fails to read the message because it requires the private key to decipher.
4. Alice decrypts the message using the corresponding private key.

Since the certificate uses asymmetric encryption, if Alice wants to send a message privately to Bob, she needs Bob’s public key. With Bob’s public key in hand, Alice can repeat these steps and send a message to Bob.

Where Do You Get a Certificate?

There are two ways digital certificates are conceived:

1. Self-signed certificates
2. Signed by an issuer

As Figure 2 shows, self-signed certificates are their own issuer.

Figure 3 shows the anatomy of a certificate signed by an issuer.

Figures 4 and 5 show a Microsoft Intune Mobile Device Management (MDM) device certificate signed by an issuer.

Issuer is a generic term referring to the name of the parent certificate that signed the issued certificate. This is typically a Certificate Authority (CA—also known as a Certification Authority), which is an entity that issues certificates. CAs are useful for establishing trust with an issuer of many certificates. Without a CA, you would need to trust individual certificates like Bob or Alice. The trust path created with a CA is referred to as a certificate chain. You can have multiple issuers (or CAs) in the certificate chain. A CA hierarchy is the design/structure of the CAs in the certificate chain.

You may have also noticed that an initial self-signed certificate acts as an issuer for subordinate certificates. During PKI creation, the first self-signed issuer is referred to as the root CA.

We’ll explore CAs in much more depth in Part 2 of this blog series.

Where Are Certificates Stored on Your Computer?

All modern operating systems have storage for certificates. This article focuses on the Windows OS.

In Windows, certificate stores are implemented in the operating system using registry keys for storing certificate properties and the AppData folder for storing private keys. Certificates are installed into one of the two certificate stores:

1. Certificates – Current User
2. Certificates – Local Computer

For interacting with computer certificates using the GUI, search for “Manage Computer Certificates” in your Start menu, or type CERTLM.msc for the Microsoft Management Console (MMC) shortcut. For interacting with user certificates using the GUI, search for “Manage User Certificates” in your Start menu, or type CERTMGR.msc for the MMC shortcut.

Some certificates (e.g., CA certificates, code signing certificates, etc.) are deployed from the PKI container in Active Directory or through Group Policy. To view the certificates deployed via separate means, select View, then select the checkbox Physical certificate stores as Figure 6 shows.

Anatomy of a Digital Certificate

Digital certificates have known fields based on the X.509 public key certificate standard. There are substantial resources online about some of the more intimate details of the X.509 standard (e.g., RFC 5280 section 4.1, Sectigo’s “What Is an X.509 Certificate & How Does It Work?”)—but a good starting point is to familiarize yourself with how to find these fields on a certificate in Windows. By putting the information presented in this 5-part blog series to use, we’re hoping readers will be able to inspect any valid X.509v3 certificate and answer the following questions:

1. Is this certificate self-signed, or issued by a CA?
2. If it’s self-signed, is it a root CA?
3. Is the certificate still valid, or has it expired?
4. What is the signature (public key) algorithm?
5. What is the digest (hashing) algorithm?
6. What is the key size?
7. What is the intended purpose of the certificate?
8. Does the certificate have Uniform Resource Identifiers (URIs) for revocation checking (e.g., Certificate Revocation List—CRL, Online Certificate Status Protocol—OCSP)?
9. Does the certificate have URIs for verifying CA chain (e.g., Authority Information Access—AIA)?
10. Does the certificate have URIs for any issuer or policy statements (e.g., Certificate Policy—CP/Certification Practice Statement—CPS)?

Figure 7 shows an example of a self-signed X.509v3 digital certificate generated for Windows Hello for Business (WHFB) authentication.

It may seem unusual for Microsoft to implement WHFB using self-signed certificates, but it’s more practical and secure than issuing WHFB certificates from CAs that would need to be highly available, maintained, and safeguarded from compromise. During the WHFB enrollment process, the self-signed certificate generated on the local device is whitelisted in Entra ID (formerly Azure Active Directory).

Using the WHFB example, we can answer the previously posed questions as follows:

Figure 8 shows an example of the Transport Layer Security/Secure Sockets Layer (TLS/SSL) web server certificate for ravenswoodtechnology.com issued by DigiCert.

DigiCert is among a small number of companies that manage globally trusted CAs that are trusted on devices. As a result, this web server certificate was issued by a highly regulated CA. These public CAs have published policies for managing their CAs and routinely publish a list of issued certificates that are no longer trusted. (For more information about revocation checking, see Part 3 of this blog series.)

In the ravenswoodtechnology.com example, the answers to the previous questions are summarized in the following table.

Final Remarks

Although the concepts of PKI have existed for decades, many organizations are still struggling with the complexities of PKI and how it fits into their organization. It’s not uncommon for organizations to have built or inherited a PKI solution many years ago that slowly becomes a burden and a security risk to the business. It can be difficult to make an informed decision when planning a new PKI or adapting an existing PKI to meet evolving business needs. Ravenswood Technology can help! Contact our team to get started.

Read more in Part 2 of this blog series: Certificate Authorities and CA Hierarchies.