In this guide
What is an X.509 certificate?
An X.509 certificate is a structured digital document that binds a public key to an identity or set of identities. It is commonly issued and digitally signed by a Certificate Authority (CA). The signature allows a relying system to check that the certificate contents have not been altered since signing and that the signer’s key was used.
Certificates are used in HTTPS/TLS, client certificate authentication, 802.1X EAP-TLS, VPNs, code signing, email security and device identity. A certificate contains the public key; it does not contain the corresponding private key. The private key must be stored and protected separately, except where a container format packages a certificate together with a private key.
In a TLS connection, a server usually sends its leaf certificate and any required intermediate CA certificates. The client checks the certificate path, validity dates, identity, permitted usage and local trust policy. A certificate viewer can display fields, but it may not perform all of those validation steps.
The main certificate fields
An X.509 v3 certificate has a signed body called TBSCertificate (“to be signed certificate”), an outer signature algorithm identifier, and the signature value. The signed body contains the core fields below.
| Field | What it means | What to check |
|---|---|---|
| Version | Identifies the X.509 certificate version. Version 3 supports extensions and is standard for most modern TLS certificates. | Most web and enterprise certificates should be v3 when they use SAN, Key Usage or other extensions. |
| Serial Number | A number assigned by the issuing CA to identify a certificate within that issuer’s namespace. | Useful for inventory, CA logs and revocation records. It is not a secret and is not a unique global identifier by itself. |
| Signature Algorithm | The algorithm the issuer used to sign the certificate, such as SHA-256 with RSA or ECDSA with SHA-256. | Check compatibility and policy. Avoid obsolete algorithms such as MD5 or SHA-1 for new deployments. |
| Issuer | The distinguished name of the CA that issued and signed the certificate. | Compare it with the subject of the expected issuing CA certificate. A matching name alone does not prove a valid chain. |
| Validity: Not Before / Not After | The time window during which the certificate is intended to be valid. | Check current time, timezone, device clock and renewal lead time. Validity dates alone do not prove trust. |
| Subject | The distinguished name identifying the certificate subject. It can contain attributes such as CN, O, OU, C, ST and L. | For modern TLS hostname checks, do not rely on the Common Name (CN) alone; check Subject Alternative Name. |
| Subject Public Key Info (SPKI) | Contains the public-key algorithm and public key material. | Identify the key type and size/curve, and confirm it meets your security policy. The certificate does not disclose the private key. |
| Issuer / Subject unique identifiers | Optional identifiers from the X.509 specification. | Uncommon in typical modern TLS certificates; do not confuse them with the issuer and subject names. |
| Extensions | Additional v3 information, including SAN, Key Usage, EKU and Basic Constraints. | Extensions often determine whether a certificate is suitable for the intended purpose. |
| Signature Value | The issuer’s digital signature over the encoded certificate body. | Signature verification requires the issuer’s public key and correct algorithm processing; displaying the field is not the same as verifying it. |
Distinguished names and Common Name
A distinguished name (DN) is a sequence of attributes, often displayed as a comma-separated string. Common abbreviations include CN (Common Name), O (Organisation), OU (Organisational Unit), C (Country), ST (State or province) and L (Locality). These are identity metadata, not proof that the named organisation is legitimate.
Historically, the CN often held a server hostname. Current TLS identity checking uses the Subject Alternative Name (SAN) extension. A certificate can have a plausible CN but still be wrong for the requested hostname if the SAN does not match.
Serial number and fingerprint are different
The serial number is assigned by the issuer. A fingerprint is a digest calculated from the encoded certificate bytes, commonly SHA-256. Fingerprints are useful for comparing two certificate files or confirming that the exact expected certificate was received. The same certificate encoded in PEM and DER has the same underlying DER certificate bytes and therefore the same certificate fingerprint.
Important X.509 extensions
Extensions are identified by object identifiers (OIDs) and may be marked critical or non-critical. A critical extension must be understood and processed by a relying implementation; if it cannot process a critical extension, it should reject the certificate.
| Extension | Purpose | Operational significance |
|---|---|---|
| Subject Alternative Name (SAN) | Lists identities such as DNS names, IP addresses, email addresses or other name forms. | For TLS, verify the exact DNS name or IP address used by clients appears in the appropriate SAN type. A wildcard such as *.example.com only matches one label to the left under normal hostname matching rules; it does not cover the apex example.com or a.b.example.com. |
| Key Usage (KU) | Constrains cryptographic operations for which the key may be used, such as digital signature, key encipherment, key agreement or certificate signing. | Must be consistent with the key type, certificate role and protocol. A CA certificate normally needs keyCertSign to sign certificates. |
| Extended Key Usage (EKU) | Describes intended application purposes. | Common OIDs include server authentication, client authentication, code signing and email protection. A certificate may be rejected if its EKU does not permit the required role. |
| Basic Constraints | Indicates whether the subject is a CA and can include a path length constraint. | Intermediate and root CA certificates normally have CA:TRUE. A leaf server certificate should not be treated as a CA simply because its subject name resembles one. |
| Subject Key Identifier (SKI) | An identifier for the public key in the certificate. | Can help identify a certificate’s key and build certificate paths. |
| Authority Key Identifier (AKI) | Helps identify the key used to sign a certificate, often by referencing the issuer’s SKI. | Useful when a CA has multiple certificates or has renewed/re-keyed. It is a path-building hint, not a substitute for signature verification. |
| CRL Distribution Points | May provide locations for Certificate Revocation Lists (CRLs). | Shows where revocation information may be obtained. Whether a client checks it, and what happens if checking fails, depends on client policy. |
| Authority Information Access (AIA) | Can identify issuer-certificate locations and OCSP responder URLs. | Some clients use AIA to retrieve intermediates or obtain OCSP status. Do not assume every client will fetch missing intermediates automatically. |
| Certificate Policies | Can identify policies under which a certificate was issued. | Relevant in some regulated or managed PKI environments; policy OIDs require organisational interpretation. |
| Name Constraints | Can restrict the namespace in which a CA may issue certificates. | Important for constrained intermediate CAs. Support and enforcement can vary between implementations. |
| CT / SCT information | Signed Certificate Timestamp data relates to Certificate Transparency for publicly trusted TLS certificates. | Public browser trust requirements can depend on CT policy. The exact representation and enforcement depend on the certificate and client. |
Critical versus non-critical: criticality is not a severity rating. It tells a relying implementation how to handle an extension it does not understand. Do not manually change extensions or certificate contents: doing so invalidates the issuer’s signature.
Certificate formats and file extensions
The certificate’s data structure and the way it is encoded or packaged are separate concepts. X.509 defines the certificate structure; DER and PEM describe common encodings; PKCS#7 and PKCS#12 are containers. Extensions such as .cer and .crt are conventions and do not reliably identify the encoding.
| Format / extension | What it contains | Typical use |
|---|---|---|
DER (.der) | Binary ASN.1 encoding. A DER file often contains one X.509 certificate, though DER is a general encoding rule. | Some Windows, Java, network appliances and PKI workflows accept binary certificates. Not human-readable in a text editor. |
PEM (.pem) | Base64 text with BEGIN/END markers around DER-encoded data, for example -----BEGIN CERTIFICATE-----. | Common on Linux, web servers, load balancers, proxies, firewalls and command-line tools. A file can contain one certificate or a sequence of certificates. |
CER / CRT (.cer, .crt) | Filename extensions, not a guaranteed encoding. Files may be PEM or DER. | Commonly used for certificate files. Inspect the content or use a parser to determine the actual encoding rather than renaming the extension. |
PKCS#7 / P7B / P7C (.p7b, .p7c) | A signed-data/certificate container commonly used to carry certificates and chains. It normally does not contain a private key. | Often used to export a certificate and intermediate chain from Windows or enterprise CA tools. It can be PEM-armoured or binary DER encoded. |
PKCS#12 / PFX / P12 (.pfx, .p12) | A container that can bundle a certificate, private key and optionally additional certificates, usually protected by a password. | Common for Windows/IIS, certificate import/export and moving a certificate with its private key between systems. Treat it as sensitive secret material. |
CSR (.csr, sometimes .req) | A Certificate Signing Request containing a public key, requested subject information and a signature made with the corresponding private key. | Submitted to a CA to request issuance. It is not an issued certificate and normally does not contain the private key. |
Private key PEM (.key, .pem) | May contain private-key material, commonly labelled BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY or BEGIN ENCRYPTED PRIVATE KEY. | Required by the service or client proving possession of the key. Never paste it into a public certificate inspection tool or share it in support tickets. |
| PKCS#8 | A standard structure for private-key information, often represented as PEM text with PRIVATE KEY markers. | Private-key format, not a certificate format. It may be encrypted or unencrypted. |
JKS / Java keystore (.jks) | A Java-specific keystore container that can hold private-key entries and trusted certificate entries. Java also supports PKCS#12 keystores. | Application and Java server configuration. Use Java keytool or an appropriate keystore utility to inspect and convert entries. |
PEM is a wrapper, not a different certificate
A PEM certificate usually contains Base64-encoded DER data between a matching BEGIN and END label. Line breaks are for readability. Converting a certificate from PEM to DER removes the text wrapper and decodes the same certificate structure; it does not issue a new certificate, change its validity, or add trust.
-----BEGIN CERTIFICATE-----
(base64-encoded DER certificate data)
-----END CERTIFICATE-----PEM files can contain multiple blocks. A chain file might contain a leaf certificate followed by intermediate certificates. Other PEM labels represent different objects: CERTIFICATE, PRIVATE KEY, ENCRYPTED PRIVATE KEY, CERTIFICATE REQUEST and PKCS7 are not interchangeable.
Do not trust the filename
Changing certificate.cer to certificate.pem does not convert it. Renaming changes only the filename. A real conversion parses the input and writes the target encoding or container. Similarly, converting a certificate from PEM to DER cannot turn it into a PFX because PFX may need a private key and is a different container format.
Certificate chains and trust
A typical public TLS chain consists of a leaf certificate for a hostname, one or more intermediate CA certificates, and a root CA certificate trusted by the client. The leaf is signed by an issuing intermediate; that intermediate chains to another CA or to a root.
- Leaf / end-entity certificate: identifies a service, user or device. It is not normally permitted to issue other certificates.
- Intermediate CA: signs leaf certificates or subordinate CA certificates. It should have CA constraints and appropriate key usage.
- Root CA: a trust anchor installed or otherwise trusted by the relying system. A root is usually self-signed, but self-signing alone does not make it trusted.
Servers commonly send the leaf certificate followed by the necessary intermediate certificates. Clients generally obtain trust from their local trust store rather than trusting a root merely because the server sent it. Sending the root is often unnecessary and does not make an untrusted root trusted.
Chain validation is more than comparing issuer and subject names. A validator checks signatures, path constraints, validity, critical extensions, purpose and local policy. Depending on the application and policy, it may also check revocation and other requirements. Cross-signing and alternate paths can mean there is more than one possible chain.
Which file do I need?
| Task | Usually needed | Notes |
|---|---|---|
| Inspect a server certificate | PEM or DER certificate | Check SAN, validity, issuer, key type and extensions. |
| Configure a Linux web server or proxy | PEM certificate and private key | Often requires a full-chain certificate file and a separately protected private key. Exact filenames and ordering depend on the product. |
| Import a certificate chain into an appliance | PEM chain or PKCS#7/P7B | Check which encoding and chain order the appliance accepts. |
| Move a service identity to Windows/IIS | PKCS#12/PFX with certificate and private key | Protect the export password and file. Ensure private-key export is permitted by policy. |
| Request a new certificate from a CA | CSR | Create the private key on the system that will use it where possible; submit the CSR and keep the private key private. |
| Trust an internal CA on clients | Root CA certificate, and sometimes intermediate CA certificates | Distribute through a trusted, managed channel and validate the fingerprint/source before deployment. |
| Import a certificate into a Java application | Certificate file or keystore entry | Use the appropriate Java keytool workflow and distinguish trusted certificates from private-key entries. |
Inspecting and converting certificates
Use the Ingenix Certificate Converter & Inspector to parse supported PEM or DER X.509 certificates, inspect common fields, calculate a SHA-256 fingerprint and export PEM or DER. It runs in the browser and is intended for inspection and format conversion, not full PKI validation.
When inspecting any certificate, work through this order:
- Confirm the object and encoding. Is it a certificate, a CSR, a private key or a container? Is it PEM text or binary DER?
- Check identity. Confirm the SAN contains the actual DNS name or IP address used by the client.
- Check time. Compare Not Before and Not After with the current time, and check system clock accuracy.
- Check issuer and chain. Confirm the expected CA and that the relying system has the necessary intermediate and trust anchor.
- Check purpose and constraints. Review Basic Constraints, Key Usage and EKU.
- Compare fingerprints when needed. Use a trusted reference fingerprint to confirm you have the expected certificate.
- Check revocation and policy separately. Use the target platform’s validation tools and policy; a field viewer may not perform these checks.
For command-line inspection, OpenSSL is commonly used. Examples:
# Display a PEM certificate
openssl x509 -in certificate.pem -noout -text
# Display a DER certificate
openssl x509 -inform DER -in certificate.der -noout -text
# Convert PEM certificate to DER
openssl x509 -in certificate.pem -outform DER -out certificate.der
# Convert DER certificate to PEM
openssl x509 -inform DER -in certificate.der -outform PEM -out certificate.pem
# Calculate a SHA-256 fingerprint
openssl x509 -in certificate.pem -noout -fingerprint -sha256These commands assume the input is a single X.509 certificate in the stated format. PKCS#7, PKCS#12, CSRs and private keys use different commands and handling. Do not use certificate conversion commands as a substitute for verifying a chain or protecting key material.
Troubleshooting common certificate failures
Hostname mismatch
Check the exact hostname the client requested against the certificate SAN. Verify that the client is reaching the expected endpoint and that a load balancer, reverse proxy or TLS inspection device is not presenting a different certificate. A correct CN by itself may not be enough.
Expired or not yet valid
Check Not After and Not Before, but also check clocks and time synchronisation on both client and server. Renewal may have occurred on one node but not another, especially in clustered services or load-balanced deployments.
Untrusted issuer or incomplete chain
Confirm the leaf certificate is issued by the expected CA and that the required intermediate certificates are available. The client trust store may be missing an internal root, or a server may omit an intermediate. Do not fix an incomplete chain by blindly installing an unknown root as trusted.
Wrong certificate purpose
Review EKU and Key Usage. A client-authentication certificate is not automatically suitable for server authentication, and a CA certificate is not interchangeable with a leaf certificate. Application-specific rules may impose further requirements.
PEM parse error
Check that the BEGIN and END labels match, the Base64 content is complete, and the file does not contain an unsupported object or malformed bundle. A PEM file may contain several different block types; a tool designed for certificates may not accept private keys, CSRs or every PKCS#7 variant.
Certificate imports but service still fails
Importing a public certificate does not prove the service has the matching private key, has bound the certificate to the correct listener, or is serving the intended chain. Check the service binding, key association, permissions, SNI configuration, chain delivery and client trust independently.
Security and operational practice
- Protect private keys. Never publish private keys, upload them to untrusted services or include them in screenshots and support tickets. A certificate inspection tool should not need your private key.
- Manage renewal before expiry. Inventory certificate owner, purpose, SANs, issuer, renewal method and dependencies. Monitor expiry with enough time to test and deploy replacements.
- Use modern cryptography. Follow current platform and organisational policy for key types, key sizes, signature algorithms and certificate lifetimes.
- Validate the full context. Trust depends on the client trust store, chain building, purpose, identity and policy, not only on the certificate’s displayed fields.
- Handle CA certificates carefully. Installing a root CA as trusted grants significant authority. Verify its provenance and deploy it through controlled management channels.
- Plan revocation realistically. Understand whether clients use CRLs, OCSP, stapling or platform-specific mechanisms, and what the system does when status information is unavailable.
- Do not assume conversion repairs a certificate. PEM/DER conversion changes representation, not the signed contents, trust, identity, dates or permitted use.
Deployment checklist
- ☐ Confirm the file is the expected object: certificate, chain, CSR, private key or container.
- ☐ Confirm PEM/DER encoding and required container format.
- ☐ Verify SAN matches the actual DNS name or IP address.
- ☐ Check validity dates and system clock.
- ☐ Validate issuer signatures and the complete chain to an intended trust anchor.
- ☐ Check Basic Constraints, Key Usage and EKU for the required role.
- ☐ Check revocation and local policy where required.
- ☐ Confirm the service has the matching private key and correct certificate binding.
- ☐ Test from representative clients and monitor expiry after deployment.
- ☐ Keep private keys and PFX/P12 exports protected throughout the process.