If you have a strong understanding of what an X509 certificate is, please raise your hand. Now that we acknowledge no one is raising their hands, let’s change that.
Certificates are a complex topic and often not well understood. This tutorial aims to change that by showing you X509 certificate examples, demonstrating PKI certificates, and a lot more.
In this article, you will get a good overview of X509 certificates. By the end, you’ll understand how they work at a high level. You will not become an expert in one article, but by the end of this article, you will at least be familiar with the proper terminology.
Related: Managing Certs with Windows Certificate Manager and PowerShell
Public and Private Keys: Protecting Assets
Any information explaining X509 certificates would be incomplete without first mentioning keys. You may have heard of the concept of keys when terms like private and public keys are thrown around. But what exactly is a key and how does it relate to certificates?
To make the connection easier, let’s explain the concept of keys in terms of a good ol’ fashioned door lock.
When you purchase a new door lock, that lock will come with a door key. That key is unique to that lock so that no one else will be able to unlock it.
Think of the lock itself as a public key. When installed, you, your family or passersby can see the lock on your door. Anyone is free to see and even attempt to unlock it but they won’t succeed. To unlock it, they would need to insert the unique door key that originally came with the lock. The unique key that came with the lock is the private key.
The private and public key together are referred to as a key pair.
Key Exchange
When the door key is inserted into the lock, you can think of that action as exchanging keys. The private key (door key) needs to be exchanged with the public key (lock) to unlock the door.
In the cryptography world, you will freely give out a public key and keep the private key to yourself. After all, you don’t care who sees the lock but you definitely care who can unlock it (exchange keys).
There are a couple of different ways keys are exchanged called key exchange algorithms. Key exchange algorithms focus on deriving and securely transmitting a unique shared secret.
Two popular key exchange algorithms you may have heard of are Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH).
Key Trust
If you need someone to enter through the door, you’d give them the key (or a copy of the original, unique key). You only give your key to those you trust. The person holding the private key (door key) has been trusted to unlock the door lock (public key).
Key Usage
The key usage defines the purpose of the X509 certificate, this aligns with the algorithms the certificate will use. The extended key usage (EKU) defines the intended purposes for the public key beyond the key usage.
X509 Certs: Public Key “Containers”
How do private and public keys relate to the concept of an X509 cert? Think of a certificate as simply a public key. A certificate is the “enclosure” that holds a public key along with some other information about the key like who the public key was issued to, who signed the key among others and so on. Certificates are stored in the form of files.
We’ll cover a couple of good X509 certificate examples later.
Have you ever seen a file with a PEM or CER certificate file extension? Those are certificates (public keys). You’ll learn more about these formats a little later.
The public key by itself is not necessarily a certificate by definition. It is the public key and the associated attribute data combined that defines a certificate.
A certificate provides a standardized and secure format to communicate with specific systems along with the attributes to help validate a key pair trust. How certificates are built are defined within the X.509 standards, as you will read about later.
Thumbprint: A Certificate’s Unique Identifier
Each X509 certificate is intended to provide identification of a single subject. The certificate should ensure each public key is uniquely identifiable.
A certificate thumbprint or fingerprint is a way to identify a certificate, that is shorter than the entire public key. Technically, a serial number is as well but you’ll learn about that when it comes to certification authorities (CAs). The thumbprint is a hash of a DER-encoded certificate in Windows.
The concept of identifying a larger data set by a smaller unique identifier is the general computing topic of fingerprinting. Morgan Simonson’s blog dives deeper into the thumbprint.
Subject: Defining Important X509 Cert Attributes
Every X509 cert needs to not only have a unique identifier but also answer questions like below. The certificate subject should do just do that.
- Who should be using this certificate?
- Which organization should be trusted?
- Which user should present this certificate?
The subject is arguably the most important part of a certificate. The subject is meant to have attributes, defined by X.500, that represent who or what the certificate is issued to. It is represented in a distinguished name (DN) format.
A certificate subject is a string value that has a corresponding attribute type. For example, the DN for State or Province is st. This attribute type contains the full name of the state or province the subject resides in (e.g. ST=California).
These attribute types and value formats are defined by the ITU-T X.520 recommendations. An additional reference is RFC 4519 for specific recommendations of attribute types and value formats.
Since X509 cert standards are not rules only strong suggestions, many people use their own judgment when defining a subject. The subject is supposed to specifically identify the end entity you trust. If the subject does not represent this, how are you able to trust anything using the presented public key?
Put another way, if you let multiple people use the same user name to access a system, you can’t hold any specific person accountable for their actions. This practice complicates the trust model certificates are meant to align with.
You can see an example of how Windows represents an X509 certificate and more specifically the certificate subject in the below screenshot.
Viewing the attributes of a certificate with the Cryptext.dll.
Subject Alternative Name (SAN)
A SAN is a certificate extension that allows you to use one certificate for multiple subjects that’s typically identified with a Subject Key Identifier (SKI). The example below shows some of the SANs Google uses. Adding more domains to a certificate essentially tells the certificate to trust each subject to use the same private key.
A SAN can also have several types other than DNS names called GeneralNames. GeneralNames require the client reading the certificate to support SANs using GeneralNames. Most clients such as web browsers only focus on the DNS name SAN.
You can see the SAN below in this X509 certificate example.
Some of the SAN attributes associated with Google’s certificate.
Understanding Encoding
We use many languages to communicate with each other, similarly computers have their own language. This language is binary and different encoding methods are how we make binary more usable for others, just as though we would translate English to other languages.
Encoding serves a specific purpose. Encoding allows the human-readable extension values to be stored in a way that computers can also use them. Encoding formats make it easier for computers to store and transfer X509 certs but also allow us to read their contents.
Computers are good at working with integers, encoding lets you convert numerical values to alphanumeric values or even binary blobs. This conversion is critical for working with computers, and certificates rely on encoding to properly convey the proper information with computers. Encoding formats define the standards for performing those conversions.
- ASN.1 – The Abstract Syntax Notation One standard is the serialization format for each of the fields within certificates.
- ASCII – The American Standard Code for Information Interchange (ASCII) defines a binary value for each of the computer control characters and printable characters used for most human readable communications.
- Base64 – Base64 defines a scheme to encode binary content within the ASCII character set. These are the certificates you can open in a text editor and see “BEGIN CERTIFICATE” or other reference text.
- DER – Distinguished Encoding Rules (DER) defines another encoding scheme specifically for ASN.1 data as sequential octets. The important consideration with DER is the encoded output is not viewable as ASCII.
You can see below as difference in encoding schemes. Notice that the certificate.crt file displayed first has a ——-BEGIN CERTIFICATE——-, followed by a bunch of random letters and numbers and ends with ——-END CERTIFICATE——-. All of the characters are human readable. The first certificate is Base64 encoded.
Now take a look at the second example of the certificate.cer file. This file’s content looks much different than the Base64 certificate. This X509 cert is DER-encoded.
Difference between Base64 and DER encoded files.
Understanding X509 Cert File Types
Remember that a certificate is nothing more than a public key with some metadata represented as a file. You will find many different types of files out in the wild representing many different types of certificates. Each type of file is differentiated by its file extension. When we refer to a KEY file, for example, we’re referring to its file extension.
Below you’ll find all of the common types of certificates defined by their file extension that you may work with and their purpose.
In the below list, you’ll notice various references to PKCS. PKCS or Public Key Cryptography Standards is a set of standards to define how various certificates are created. For more information, check out this informative Wikipedia article.
- PFX – These are most commonly found in a Windows environment, but is a standard format regardless of the operating system. PFX files contains a certificate, the public key and extensions, and a private key encrypted with a password. PFX is defined by the PKCS #12 standard.
- P12 – Like PFX, P12 is defined by the PKCS #12 standard. Formally, PKCS #12 is the successor to the PFX format, though both file types represent the same format in modern cryptographic implementations.
- P7B – A container of ASN.1 certificates, specifically public keys for all tiers of a certificate authority chain as you’ll learn about below. A PKCS #7 file provides a single file to distributed multiple public keys, often used to manually set up a trust with CAs in a private PKI.
- P7C – The P7C file type is functionally the same as P7B, but is simply another common extension used to represent a PKCS #7 file.
- DER – A DER file is a DER-encoded public key.
- CER – A public key either DER or Base64 encoded. A CER file is usually DER-encoded .
- CRT – A CRT is usually Base64 encoded, but there are no guarantees.
- KEY – A KEY file often is a Base64 encoded private key, whether encrypted or not.
- PEM – A reference to a Base64 encoded certificate, although multiple keys can be in a single PEM file, often there is an assumption of the PEM file having a private key. Most commonly used for a PEM Base64 encoded private key file – either encrypted or unencrypted.
- CSR – Used to submit a public key to a CA to be signed and issued additional fields such as a serial number and is defined by PKCS #10. In most cases, a CSR will contain the ASN.1 structure for the request in Base64 encoding.
- REQ – Used within Windows to specify the enrollment policy settings used when generating the CSR.
- CRL – A CRL is a specific file listing the certificates revoked by a CA, their revocation state, and the reason they were revoked.
Public Key Infrastructure (PKI): The X509 Cert Ecosystem
Recall earlier when someone held the door key to a door lock. In that instance, you just had a single door. But what happens when you suddenly find yourself as a landlord of dozens or hundreds of apartments? Managing all of those door keys is going to get ugly!
Also, tenants won’t stay in that apartment forever. There will be some people that keep the key or make unauthorized copies. You’re going to need to change the door locks to prevent access. You don’t trust the former tenants anymore.
If you’ve got to manage hundreds of apartments with tenants constantly moving in and out, how do you manage all of that? The answer is a Public Key Infrastructure (PKI).
PKI is an entire ecosystem of roles, policies, and procedures built around managing public keys. PKI represents an all-encompassing set of many different areas of focus to distribute, use, manage and remove X509 certificates. It’s essentially everything it takes to properly handle and manage certificates at scale.
In the coming sections, we’ll break apart many of the most common components of a PKI and explain the role each component plays.
Certificate Authorities (CAs): Your Parents
A PKI is primarily built around the concept of managing trust. But since it’s not economical to directly manage hundreds or thousands of trust relationships, you need a mediator.
You need a third-party that has already been vouched for by the original party. These third-party mediators are called certification authorities (CAs) identified by an Authority Key Identifiers (AKI) extension derived from the public key used to sign the given certificate.
Think of you as a child as an X509 certificate. You were likely taught not to trust strangers by your parents. But what if your parents (those you trust), introduce you to a stranger and tell you it’s OK to trust them? You’d probably go along with it and trust the stranger to you. After all, if your parents trust them so can you.
A CA plays the role of your parents. You trust your parents (a CA) and they introduce you to strangers. They do so by signing the stranger’s public key to let you know that you can trust them.
The primary role of a CA is to act as a trusted mediator.
Issuing X509 Certs: Establishing Trust
By being a known trusted entity, a CA enables trust between indirect parties. To enable trust between parties a CA “issues” certificates. When we talk about a CA issuing, we really mean the CA is validating the requested extensions and appending CA generated extensions to create a certificate.
When a CA issues an X509 certificate, it will use its own private key to digitally sign the certificate’s public key. Through the signing process, a CA is marking the certificate in a way to inform everyone that it trusts this public key. DocuSign provides a good overview of this specific concept with a good diagram.
Another example of a CA generated extension is the serial number for each certificate, and each serial number needs to be unique for that given CA according to the RFC design specifications.
An example of unintended trust in modern news is the malicious use of PKIs with malware. Where creators received valid certificates that are implicitly trusted by most systems, making it more difficult for your systems to identify the malware binaries as malicious.
Revoking X509 Certs: Removing Trust
The CA is also responsible for revoking X509 certs that should no longer be trusted. These revocations are published by the CA to a Certificate Revocation List (CRL). Revocation is a way for CAs to actively invalidate a certificate, rather than waiting for the validity duration to expire.
Trust is a critical component for certificates to function in the way they are designed. Distribution points assist with ensuring trust by providing a reference point where the certificate and revocation lists can be downloaded from the issuer, and used to compare with the certificate you are using.
A CRL Distribution Point (CDP) supplies the protocols and locations to obtain CRLs. Updating CRLs is a passive revocation validation method, with pulling updates at scheduled intervals. Online Certificate Status Protocol (OCSP) actively requests the revocation status of a specific certificate by maintaining caches of the CRLs.
Though revocation validation through CRLs or OCSP is available, it is implemented at the client needs to support and enforce, and that is not always the case.
Tiering
A PKI can be made up of multiple CAs or a single CA, these are commonly referred to as tiers.
X509 Certificate Chaining
As you learned above, trust is a major focal point when using certificates. Involved parties must be able to trust or validate a certificate that was issued by a trusted CA.
A great example of how this scales is the The United States Federal PKI public documents. These provide a great reference into maintaining an inter-organization trust relationship using CAs.
X509 Certificate Signing
You will often hear of a concept called certificate signing but what exactly does that mean? As you’ve already learned, certificates are all about trust. To establish trust, an X509 cert is signed by a CA. Signing a certificate assigns a unique, cryptographic hash to a certificate telling all parties that read it they can trust it. It was signed by a trusted CA.
In a PKI hierarchy, certificates are signed by CAs but where those certificates are used depends on what kind of CA signs them.
When there is a single CA in a PKI, that CA is the root. Since no other CA exists, that CA has to generate its own self-signed certificate. That CA then issues certificates signed by it’s own certificate.
If a PKI has more than one CA, all CAs are signed by a root CA or an intermediary CA that chains back to the root CA.
Typically, when a device uses the same private key that corresponds to the public key when generating an X509 cert, this is known as a self-signed certificate. However, you can also request a CA to use its own private key to sign your certificate.
Signature Algorithms
Signature algorithms focus on validating the authenticity of a message from a remote peer. A digital signature is a message digest from a hashing function encrypted with the senders private key. The recipient decrypts the digital signature using a copy of the sender’s public key. The recipient can then compare the digest of the received message against the one decrypted from the digital signature. When the digests match, the authenticity of the message is valid.
Asymmetric encryption is the ability to generate cipher text without the use of a previously known secret. The combination of a key exchange algorithm with a signature algorithm is the foundation of asymmetric encryption.
Below are the primary algorithms used for digital signatures.
- Rivest–Shamir–Adleman (RSA)
- Digital Signature Algorithm (DSA)
- Elliptic Curve DSA (ECDSA)
Certificate Signing Requests (CSRs)
Issuing CAs use Certificate Signing Requests (CSR) that allow clients to submit public keys to CAs for issuance. A CA accepts a CSR and will issue a signed X509 certs based on the configured issuance policies. Meaning, each CA you trust also implies trust for the public keys it signs.
Hashing
Hashing is a complex topic, and I will not even try to do it justice in this post. The Computerphile team has a good overview on their YouTube channel. Hashing focuses on taking an input object and creating a unique output hash for that unique input. The output hash is known as a digest. Meaning changing the input object in the slightest way, will create a different unique and unrelated digest.
Modern implementations will focus on Secure Hash Algorithm (SHA) 2 algorithms. As a note, SHA 256, SHA 384, and SHA 512 are known as SHA 2.
Below is a list of common hashing algorithms you will see.
- SHA 256
- SHA 384
- SHA 512
- Message Digest (MD) 5
Certificate Policies
The certificate policy (CP) extension supplies the reference to the organization maintaining the CA, documenting their actual policies for the given PKI and should be aligned as a Certification Practice Statement (CPS) providing the organization’s policy for maintaining the given PKI.
Distribution Points
Another type of distribution point identified within certificates are Authority Information Access (AIA). These AIAs supply the protocols and locations to obtain copies of the certificate issuers information, most commonly this means the public key of the issuing CA.
Summary
Hopefully now, when you are asked a question like at the start of this article, you feel more comfortable raising your hand, slowly. In all honesty though, hopefully, this article has helped you see the complexities with X509 certs, and in Windows’ implementation of these standards. While helping you understand some of the basic components that will help you in the future working with certificates.
At least now when someone asks for a public key of your certificate you can confirm that they want either DER or Base64 encoded, and they will not know so you will still send them both regardless.
