Configuring Certificate Authority with OpenSSL

A Certificate Authority (CA) is the trust anchor in a PKI hierarchy, responsible for issuing, signing, and revoking

What Is This

Configuring a Certificate Authority (CA) with OpenSSL is a foundational task in deploying a Public Key Infrastructure (PKI). A CA serves as the trust anchor within a PKI hierarchy, responsible for issuing, signing, and revoking digital certificates that underpin secure communications, authentication, and data integrity across networks and applications. This skill focuses on building a robust two-tier CA hierarchy using OpenSSL, comprising a Root CA and an Intermediate CA. Additionally, it covers essential aspects such as Certificate Revocation List (CRL) distribution, Online Certificate Status Protocol (OCSP) responder configuration, and certificate policy management. The approach leverages both OpenSSL command-line utilities and the Python cryptography library for automation and scripting.

Why Use It

Implementing a CA hierarchy with OpenSSL provides several security and operational benefits:

  • Establishes Trust: A CA validates identities and serves as a central trust anchor, ensuring that issued certificates are credible and verifiable.
  • Separation of Duties: Using a two-tier architecture (Root and Intermediate CA) isolates the highly sensitive Root CA, minimizing risk exposure and enabling operational flexibility.
  • Compliance: Many regulatory frameworks (such as NIST or ISO 27001) require organizations to implement PKI with sound certificate management practices.
  • Certificate Lifecycle Management: CAs provide mechanisms for issuing, renewing, and revoking certificates, which is essential for maintaining secure operations.
  • Interoperability: X.509 certificates issued by OpenSSL CAs are widely supported across software, systems, and cloud platforms.

How to Use It

The following steps outline how to configure a two-tier CA hierarchy with OpenSSL. The process includes establishing the directory structure, generating keys and certificates, and configuring CRL and OCSP services.

1. Prepare the CA Directory

Structure

Organize the filesystem to separate the Root CA and Intermediate CA. For example:

mkdir -p ~/ca/rootCA/{certs,crl,newcerts,private}
mkdir -p ~/ca/intermediateCA/{certs,crl,csr,newcerts,private}
chmod 700 ~/ca/rootCA/private ~/ca/intermediateCA/private

Create the necessary database files:

touch ~/ca/rootCA/index.txt
echo 1000 > ~/ca/rootCA/serial
touch ~/ca/rootCA/crlnumber

Repeat for the intermediate CA.

2. Generate the Root CA Private Key and Self-Signed

Certificate

openssl genrsa -aes256 -out ~/ca/rootCA/private/ca.key.pem 4096
chmod 400 ~/ca/rootCA/private/ca.key.pem

openssl req -config openssl_root.cnf \
    -key ~/ca/rootCA/private/ca.key.pem \
    -new -x509 -days 7300 -sha256 -extensions v3_ca \
    -out ~/ca/rootCA/certs/ca.cert.pem

The openssl_root.cnf should be tailored with appropriate policies and extensions.

3. Generate the Intermediate CA Private Key and

CSR

openssl genrsa -aes256 -out ~/ca/intermediateCA/private/intermediate.key.pem 4096
chmod 400 ~/ca/intermediateCA/private/intermediate.key.pem

openssl req -config openssl_intermediate.cnf \
    -new -sha256 \
    -key ~/ca/intermediateCA/private/intermediate.key.pem \
    -out ~/ca/intermediateCA/csr/intermediate.csr.pem

4. Sign the Intermediate CA Certificate with the Root

CA

openssl ca -config openssl_root.cnf \
    -extensions v3_intermediate_ca \
    -days 3650 -notext -md sha256 \
    -in ~/ca/intermediateCA/csr/intermediate.csr.pem \
    -out ~/ca/intermediateCA/certs/intermediate.cert.pem

Verify the certificate chain:

openssl verify -CAfile ~/ca/rootCA/certs/ca.cert.pem \
    ~/ca/intermediateCA/certs/intermediate.cert.pem

5. Issue End-Entity

Certificates

Use the Intermediate CA to sign leaf certificates for servers or users:

openssl genrsa -out user.key.pem 2048
openssl req -new -key user.key.pem -out user.csr.pem

openssl ca -config openssl_intermediate.cnf \
    -extensions usr_cert \
    -days 375 -notext -md sha256 \
    -in user.csr.pem -out user.cert.pem

6. Configure CRL and

OCSP

CRL Generation:

openssl ca -config openssl_intermediate.cnf -gencrl -out crl/intermediate.crl.pem

OCSP Responder (example with OpenSSL):

openssl ocsp -port 2560 -text -sha256 \
    -index ~/ca/intermediateCA/index.txt \
    -CA ~/ca/intermediateCA/certs/intermediate.cert.pem \
    -rsigner ~/ca/intermediateCA/private/intermediate.key.pem \
    -rkey ~/ca/intermediateCA/private/intermediate.key.pem

7. Automate with

Python (Optional)

For scripting or integration, the cryptography Python library can be used:

from cryptography import x509
from cryptography.x509.oid import NameOID
from cryptography.hazmat.primitives import serialization, hashes
from cryptography.hazmat.primitives.asymmetric import rsa

key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
subject = x509.Name([
    x509.NameAttribute(NameOID.COUNTRY_NAME, u"US"),
    x509.NameAttribute(NameOID.ORGANIZATION_NAME, u"Example Org"),
    x509.NameAttribute(NameOID.COMMON_NAME, u"example.com"),
])
## Build and sign certificates as needed

When to Use It

  • Establishing a new PKI for internal or external services
  • Implementing compliance-driven security controls requiring certificate-based authentication and encryption
  • Building or improving security architecture that depends on trusted digital identities
  • Conducting security assessments or penetration testing that require a controlled certificate authority

Important Notes

  • Security of Private Keys: The Root CA's private key must remain offline and highly protected. Intermediate CA keys should also be secured with strong access controls.
  • Configuration Files: Always tailor openssl.cnf files to your organization's policy requirements, including subject constraints, key usages, and certificate lifetimes.
  • Revocation Management: Regularly update and distribute CRLs and maintain an available OCSP responder to support certificate revocation checking.
  • Testing: Always perform operations in a controlled lab environment before deploying changes to production systems.
  • Compliance: Align CA operations with regulatory and industry best practices, referencing NIST CSF controls PR.DS-01, PR.DS-02, and PR.DS-10.

By mastering the configuration of a CA hierarchy with OpenSSL, practitioners gain the ability to enforce robust certificate management, foundational to modern cybersecurity and trusted communications.