Certificates For Beginners

February 25th, 2026

Certificate management and the X509 certificate standard is closely related to Public Key Infrastructure (PKI) and for the purposes of this chapter, the difference is trivial. As such we will discuss everything in terms of PKI before addressing X509.

No assumption is made about the reader's knowledge level and this is designed to be a sort of primer rather than detailed course and reference manual.

This article contains the following:

• What Are Certificate For?

• Practical Use Cases

• Anatomy of PKI

• Terminology
• Certificates
• Certificate Properties

• Verification
• The Chain of Trust

What Are Certificates For?

There are four primary uses for certificates of which all others uses are merely derivatives of. And these are logically grouped into two pairs:

Trust

• Signing
  Signing data in a way that is unique to the sender and not forgeable.
• Verification
  Verifying the authenticity of data received by a sender in a way that confirms that the data is both untampered and the identity of the sender is verified.

Privacy

• Encryption
  Encrypting data so that only the intended recipient can decipher the contents.
• Decryption
  Deciphering data to make it usable.

Practical Use Cases

The above is somewhat abstract but there are common use cases where PKI is more apparent.

Use Case	Signing & Verification	Encryption & Decryption
TLS1 (such as HTTPS	Yes	Yes
SSO2	Yes	No
Verified email	Yes	No
Encrypted email3	No	Yes
Encrypted hard drive	No	Yes
VPN	Yes	Yes

Custom implementations may enforce both feature sets.

Actual use cases for PKI are vast and can cover any scenario in which assuring the identity of data sender, the integrity of the data itself, or securing data with encryption is deemed important.

Anatomy of PKI

PKI is made up of a number of core components which are individually simple, but all interrelated with specific purposes.

Terminology

As mentioned, there are a number of components to PKI which have redundant terminology which can make PKI seem more complex that it is. In reality there are a small number of components and once the various names they are referred to are known, discussions around PKI become a lot simpler to understand. For example, when someone talks about a "signing key" and someone else talks about a "private key" they are actually referring to exactly the same thing.

In AC X509 Authority and this documentation, the convention is followed that keys are all private, and certificates are all public.

When is a Signing Key not a Decryption Key? The X509 standard allows for restricting usage of a key-pair to specific use cases and embedding that restriction in the public certificate. While there are constraints on certificates managed by AC X509 Authority, it is basically transparent to the administrator and the four core functions of signing, verification, encryption, and decryption are enabled for every key-pair.

Certificates

"Certificates" is often used as a sort of general term to encompass both private keys and certificates. Between a private key and public certificate, the four main uses (signing, verification, encryptions, and decryption) are handled as follows:

	Private Key	Public Certificate
Trust	Signing	Verification
Privacy	Decryption	Encryption

For these operations to happen, a sender must share their public certificate with the receiver. The private key must always be kept private and never be exposed outside of owning organization. If communication is bi-directional, they may mutually exchange public certificates.

Consider a scenario where two parties are exchanging messages where they both want full encryption and verification in both directions. The initial message sent and the response for parties, Foo and Bar, would use PKI as shown below:

The Message

1. Foo signs the message with Foo's own private key.
2. Foo then uses Bar's public certificate to encrypt the message. The data is now effectively for Bar's eyes only.
3. Bar uses Bar's private key to decrypt the encrypted message.
4. Bar then uses Foo's public certificate to verify the signature of the data which proves that it was both untampered and really send by Foo.

The Reply

1. Bar signs the message with Bar's own private key.
2. Bar then uses Foo's public certificate to encrypt the message. The data is now effectively for Foo's eyes only.
3. Foo uses Foo's private key to decrypt the encrypted message.
4. Foo then uses Bar's public certificate to verify the signature of the data which proves that it was both untampered and really send by Bar.

Certificate Properties

Private keys and public certificates have different properties which are often used in discussions around PKI. The table below describes which property belongs to a certificate versus a key.

	Private Key	Public Certificate
Length	X
Key Type	X
Subject		X
Issuer		X
Valid From		X
Valid To		X
Serial Number		X
Constraints		X
SANs		X
CRL Path		X

As you can see, the properties are mutually exclusive and the majority of properties are part of the certificate.

Verification

Out of the four main functions of PKI, verification warrants additional discussion. Verification assures the receiver that the sender is who they claim to be. Unlike the other functions which are single cryptographic operations, verification runs several tests in order to consider the sender and their data as valid. To be verified, the receiver performs the following tests against the senders public certificate.

• Does a certificate with a matching DN exist in the truststore?
• Is the date the message was sent after the Valid From date?
• Is the date the message was sent before the Valid To date?
• Does the sender's hostname match the CN field of the DN?
• Does the sender's hostname match one of the SANs?
• Is the serial number marked as revoked in the CRL?
• Is the Issuer DN a certificate in the truststore?
• Is the certificate use allowed by the constraints?

Only after verification of the certificate itself has been performed will any verification of the data signature happen.

When an application fails a test, it will generally take some action to either warn the user or block access to the data entirely. For example, if a test fails for a certificate in a web browser, the user sees some message indicating that "this site is not secure.

The tests performed are application specific. Some applications may test for all of the above while others only test for a subset or even just the presence of the senders parent Issuer certificate in the receiver's truststore.

The Chain of Trust

The chain of trust is literally that chain of Subject and Issuer fields from a certificate back to the Root CA.

The DN for the Issuer of a certificate will be the DN in the Subject field for the parent CA. A chain may be very short and have one end-entity certificate issued directly by a Root CA. In which case the chain would have just two certificates. More common though, is a longer chain with multiple Intermediate CA certificates between the Root CA and end-entity certificate.

Chain of trust example

End-entity Certificate

Subject	CN=movieblog.com, OU=Devops, O=Movie Publicaitons Inc.
Issuer	CN=CertificateControl, OU=Devops, O=Movie Publicaitons Inc.

Intermediate Certificate

Subject	CN=CertificateControl, OU=Devops, O=Movie Publicaitons Inc.
Issuer	CN=CertificateControl, O=Movie Publicaitons Inc.

Root Certificate

Subject	CN=CertificateControl, O=Movie Publicaitons Inc.
Issuer	CN=CertificateControl, O=Movie Publicaitons Inc.

As you can see, the Issuer is always the Subject of the parent CA. This would be true no matter how long the chain was. Everything between an end-entity certificate and the Root CA certificate will always be an Intermediate CA certificate and there may be none or many of these.

The Root CA is always apparent because it is self-signed (Subject and Issuer fields are the same).

An application will generally expect the parent CA public certificates to all be in the truststore. if any are missing, this is referred to as a "broken chain of trust". The result of which is that verification will usually fail.