Learn PKI - Advanced X.509 & Certificate Formats

#Introduction

In episode 16 you learned to manage a CA responsibly: root separation, rotation, and auditing. Now it is time to dive into the technical details you may have been skipping. When you look at a certificate file in the terminal, what are you actually looking at? What is the difference between .crt, .pem, .p12, and .jks files? Episode 17 answers all of that.

Beyond formats, we will explore the advanced features that often determine certificate security in the real world: Certificate Transparency keeping issuance open, Extended Key Usage restricting a certificate's use, name constraints controlling a CA's scope, and the structure governed by RFC 5280.

These formats and details are not empty theory. Choosing the wrong format causes applications unable to read a key, misplacing EKU makes a certificate rejected by servers, and without CT, certificates could be issued without a trace.

#Certificate Formats: PEM and DER

PEM is the most common text format. It consists of base64 blocks with boundaries such as BEGIN CERTIFICATE and END CERTIFICATE. Because it is text-based, PEM is easy to view, easy to copy, and can hold many objects at once in a single file. DER is its binary version, often used by Java, Windows, and embedded devices.

Most files with .crt, .cer, and .pem extensions store PEM content. DER usually appears with the .der extension or as raw cryptographic output. Conversion between the two is simple.

pem-der.sh

openssl x509 -in cert.pem -outform der -out cert.der
openssl x509 -inform der -in cert.der -out cert.pem

The first command converts PEM to DER, the second converts it back. openssl x509 with -outform der is the pair always used for this conversion.

#PKCS 12: One File for Everything

PKCS 12, with the .p12 or .pfx extension, is a binary container that wraps the certificate and private key into a single encrypted file. It is the standard format for export from browsers and import to Windows servers or load balancers. The advantage is clear: one file carries everything needed.

Its weakness also needs to be known: because its contents are sensitive, a PKCS 12 file must be protected by a strong passphrase, and when stored it must be treated like a private key, not an ordinary file. A certificate already in circulation without a key is fine, but a .p12 file carries both.

export-p12.sh

openssl pkcs12 -export \
  -inkey server.key -in server.crt \
  -certfile ca.crt \
  -out server.p12

openssl pkcs12 -export combines the private key, leaf certificate, and CA chain into a single .p12 file. Note the order: -inkey for the key, -in for the certificate, -certfile for additional CAs.

#JKS and Keytool

JKS, or Java KeyStore, is a binary format owned by the Java ecosystem. It stores keys and certificates with aliases, and is managed through a tool called keytool. Although the format is binary, its contents can be exported and imported into other formats.

import-p12.sh

keytool -importkeystore \
  -srckeystore server.p12 -srcstoretype PKCS12 \
  -destkeystore server.jks -deststoretype JKS

The command above imports the contents of a .p12 file into a JKS. keytool -importkeystore is the standard way to move key material between PKCS 12 and JKS without retyping certificates manually.

#Converting Between Formats

In your career, you will go back and forth between PEM, PKCS 12, and JKS. The three commands below summarize the most frequently used patterns.

openssl pkcs12 -in server.p12 -nodes \
  -out server.pem

openssl pkcs12 -in ... -nodes unpacks a .p12 file into readable PEM content, while keytool -exportcert -rfc exports a certificate from a JKS in PEM format. Finally, openssl x509 -text displays the entire certificate contents for manual inspection.

#Certificate Transparency and SCT

Certificate Transparency is a system that records every issued certificate into a public, unforgeable log. Its purpose is simple: if an unauthorized party issues a certificate in your domain's name, that certificate will be visible in the log, so it can be detected and revoked.

The proof that a certificate has been logged is called an SCT, short for Signed Certificate Timestamp. Modern certificates include the SCT inside them, and many browsers reject certificates without a valid SCT. CT transforms PKI from a system of blind trust into a system anyone can audit.

check-ct.sh

step certificate inspect https://example.com \
  --format json

step certificate inspect with a URL will pull the certificate from the server and show its contents. You can check the extensions section to see whether the SCT is present and which log it came from.

#Extended Key Usage (EKU)

Extended Key Usage determines the functions a certificate is allowed to perform. Without EKU, a certificate could be used for many things. With EKU, usage is restricted: a certificate can be dedicated to TLS server, dedicated to client auth, or dedicated to code signing.

Some EKU values that often appear: serverAuth, clientAuth, codeSigning, and emailProtection. If a certificate marks only clientAuth, then using it as a server certificate will be rejected by the peer checking the EKU. This is an important control that prevents certificate misuse.

An example from episode 10: a client certificate with the client auth usage ensures that certificate cannot be used to accept server connections. EKU works like a usage partition.

#Name Constraints

Name constraints is a feature in CA certificates that restricts which domains may be issued. An internal CA can be constrained to only internal.example.com, so that CA technically cannot issue certificates for other domains, even by an intruder who manages to take it over.

This is a frequently underestimated feature. Public CAs such as Let's Encrypt cannot apply constraints because they must serve any domain, but internal CAs actually benefit. With name constraints, a configuration error or intrusion on one CA does not immediately destroy the entire namespace.

#RFC 5280 and Structural Details

RFC 5280 is the specification that defines the X.509 certificate and CRL profile. It governs the field structure, validation rules, and allowed extensions. If you read the output of openssl x509 -text, almost every part that appears is governed by RFC 5280.

Some elements governed by RFC 5280: version, serial number, subject, issuer, validity period, public key, and various extensions such as subjectAltName, keyUsage, and basicConstraints. Chain validation is also defined here, including the rule that every certificate must be signed by its corresponding issuer up to a trust anchor.

Info

When facing a rejected certificate problem, start from the openssl x509 -text output and check the parts that most often go wrong: an empty subjectAltName, a mismatched EKU, or missing basicConstraints on a CA certificate. Most validation failures can be found in those three places.

#Closing

Episode 17 completes your technical knowledge of X.509. You recognized the difference between PEM and DER, understood PKCS 12 as a certificate and key container, used keytool for JKS, and mastered conversion between formats. You also learned Certificate Transparency, Extended Key Usage, name constraints, and the structure governed by RFC 5280.

Key takeaways:

PEM is a readable text format, while DER is the binary version often used by Java and Windows.
PKCS 12 wraps a key and certificate into one file that must be guarded like a private key.
keytool is the main tool for managing JKS in the Java ecosystem.
Certificate Transparency records issuance into a public log, and the SCT is the proof of its logging.
Extended Key Usage restricts a certificate's function and prevents misuse.
Name constraints restrict the namespace a CA may issue.

In episode 18 we raise the scale: high availability and multi-CA. You will learn separating intermediate CAs per environment, cross-signing for root migration, gradual root rotation, HA strategies for step-ca and cert-manager, and recovery scenarios. See you there!