Creating and Managing Certificate Chains

A root CA is a self-signed certificate that serves as the ultimate trust anchor. The root CA private key must be kept offline (on an air-gapped system or HSM) because its compromise undermines the entire PKI. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" generates a self-signed root certificate valid for 10 years.

Intermediate CAs are signed by the root CA and used for day-to-day certificate issuance. First, generate the intermediate key and CSR: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Then the root CA signs it: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

End-entity certificates (leaf certificates) are signed by the intermediate CA for specific servers or clients. Generate the server key and CSR with Subject Alternative Names (SANs), then sign with the intermediate: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

The root CA private key is kept offline and only used to sign a small number of intermediate CA certificates. Day-to-day certificate issuance is performed by online intermediate CAs. If an intermediate CA is compromised, it can be revoked and replaced without compromising the root. The root key remains safe because it was never exposed online.

The "openssl ca" command provides a more complete CA workflow than "openssl x509 -req". It maintains a certificate database (index.txt), assigns serial numbers from a serial file, and handles CRL generation. It requires a proper openssl.cnf configuration file with CA-specific sections defining the certificate policy and path length constraints.

A complete certificate chain file for a web server contains the end-entity certificate followed by intermediate CA certificates in order, ending just before the root. Root certificates are not included because browsers have pre-installed root stores. Concatenation order: "cat server_cert.pem intermediate_cert.pem > chain.pem". Wrong order causes TLS handshake failures.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verifies the full chain. The "-untrusted" flag provides intermediate certificates that are part of the chain but not yet trusted. If the verification succeeds, the output is "server_cert.pem: OK". Common errors indicate missing intermediates or expired certificates.

Frequent certificate chain problems include: missing intermediate certificates (server sends only leaf cert), wrong concatenation order (leaf must come first), expired intermediate (easily missed since leaf expiry is monitored), self-signed certificates not in trust store, and name mismatch (certificate SAN does not match hostname). All are diagnosable with "openssl s_client -showcerts".

PKCS#12 (.pfx or .p12) is a container format that bundles the private key, end-entity certificate, and intermediate certificates in a single encrypted file. Create: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Required by IIS, .NET, Java keystores, and many enterprise applications.

PEM is base64-encoded ASCII, human-readable, supports multiple objects in one file, used by Apache, nginx, OpenSSL tools. DER is binary, one object per file, used by Java (JKS imports), Android, and some enterprise tools. PKCS#12/PFX is an encrypted binary container for multiple objects, used by Windows and IIS. Know your target system's expected format before deploying.

Modern CAs are required to log all issued certificates to Certificate Transparency (CT) logs before delivery. When creating a private CA for internal use, CT logging is not required. However, public-facing certificates must have embedded Signed Certificate Timestamps (SCTs) to be trusted by Chrome. Private CAs can use their own policies without CT requirements.

When assembling a TLS certificate chain file for an nginx server, what is the correct concatenation order?

Root CAs are self-signed, kept offline, and sign only intermediates. Intermediates handle day-to-day issuance. Chain files contain leaf then intermediates (root omitted). Verify with "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". PKCS#12 bundles key + certs for Windows/Java. Wrong chain order is a common deployment failure mode diagnosable with s_client -showcerts.