This lesson explains the X.509 certificate format in practical terms for DevOps engineers. If you have ever opened a certificate in OpenSSL, Java keytool, or a browser and wondered what all the fields mean, this guide will help you understand the most important parts.
This article is part of the PKI for DevOps Engineers training series. In the previous lesson, we covered how TLS and PKI work. In this lesson, we will focus on the structure of the certificate itself.
If you want to inspect a real certificate while following along, see our guide on how to view a certificate with OpenSSL.
Table of contents
- What is an X.509 certificate?
- X.509 certificate diagram
- Common X.509 certificate fields
- X.509 certificate extensions
- SAN vs Common Name
- Why X.509 certificates matter for DevOps
- Frequently asked questions
What is an X.509 certificate?
An X.509 certificate is the standard format used for public key certificates in TLS and PKI systems. It contains identifying information about the subject, information about the issuer, the subject’s public key, validity dates, and certificate extensions that define how the certificate may be used.
When a browser, application, or API endpoint uses TLS, the certificate presented by the server is usually an X.509 certificate. The client validates the certificate fields, checks the certificate chain, and decides whether the certificate can be trusted.
In other words, X.509 is the format that makes modern certificate-based trust possible.
X.509 certificate diagram
The diagram below highlights the most important parts of an X.509 certificate that DevOps engineers usually need to understand.
Common X.509 certificate fields
When you inspect an X.509 certificate, there are a few fields that matter more than the others for everyday troubleshooting.
Subject
The Subject identifies the entity the certificate was issued to. In a TLS server certificate, this is usually the server or service identity.
Older certificates often relied heavily on the Common Name inside the Subject. Modern validation relies more on the Subject Alternative Name extension.
Issuer
The Issuer identifies the certificate authority that signed the certificate. If you are troubleshooting chain issues, this field tells you which CA or intermediate should have signed the certificate.
Validity period
The validity period contains the Not Before and Not After dates. A certificate outside this date range will fail validation.
This is one of the first places to check when a certificate appears valid structurally but still fails in production.
Public key
The certificate contains the subject’s public key. This is the key used in certificate-based trust and TLS key exchange workflows. The matching private key is kept separately and must remain protected.
Signature algorithm
The signature algorithm indicates how the certificate was signed by the issuer. This matters because older algorithms may be deprecated or blocked by clients and security policies.
You can inspect these fields with OpenSSL using the openssl x509 command.
X.509 certificate extensions
Extensions are one of the most important parts of an X.509 certificate because they define how the certificate may be used and what identities it covers.
Subject Alternative Name (SAN)
The Subject Alternative Name, or SAN, lists the hostnames or identities the certificate is valid for. In modern TLS, SAN is usually more important than the Common Name for hostname validation.
Key Usage
Key Usage defines what the key in the certificate may be used for, such as digital signatures or key encipherment.
Extended Key Usage
Extended Key Usage narrows usage further, such as serverAuth for server authentication or clientAuth for client certificates.
Basic Constraints
Basic Constraints indicates whether the certificate is a CA certificate. This matters when building and validating certificate chains.
If you are working with certificate chains, these fields become especially important. The next lesson covers that in more depth: Certificate Chains Explained.
SAN vs Common Name
One of the most common certificate misunderstandings is the difference between the Common Name and the Subject Alternative Name.
Historically, clients often checked the Common Name for hostname validation. Today, modern clients usually rely on SAN instead. If the correct hostname is not present in the SAN extension, the certificate may fail hostname validation even if the Common Name looks correct.
This is a common cause of TLS errors in production, especially when older certificate practices are mixed with newer validation rules.
Example
If a certificate contains a SAN entry for api.example.com but your client connects to www.example.com, the certificate may fail hostname validation even if both names appear related.
Why X.509 certificates matter for DevOps
DevOps engineers often work with TLS certificates without being the people who requested or issued them. That makes it even more important to understand what an X.509 certificate is telling you.
When troubleshooting a certificate problem, these are often the first things you need to check:
- who issued the certificate
- which names the certificate covers
- whether the certificate is expired
- whether the certificate is a CA or an end-entity certificate
- whether the key usage and extended key usage make sense for the deployment
This is why understanding certificate structure is so useful before moving on to chain validation and TLS debugging tools like openssl s_client and openssl verify.
Frequently asked questions
What is an X.509 certificate?
An X.509 certificate is the standard certificate format used in TLS and PKI systems. It contains identity information, a public key, validity dates, and certificate extensions.
What is the difference between SAN and Common Name?
The Common Name is an older subject field, while SAN lists the hostnames or identities the certificate is valid for. Modern clients usually rely on SAN for hostname validation.
What does the issuer field mean?
The issuer field identifies the certificate authority that signed the certificate. It helps clients determine how the certificate fits into a trust chain.
Why do certificate extensions matter?
Extensions control how a certificate may be used and what names or identities it covers. Important examples include SAN, key usage, extended key usage, and basic constraints.
How do I inspect an X.509 certificate with OpenSSL?
You can inspect a certificate with the openssl x509 command. See our guide on how to view a certificate with OpenSSL.
Next lesson
Now that you understand the most important certificate fields and extensions, the next lesson explains how certificates fit together in a trust path.
Lesson 3 – Certificate Chains Explained →