How to Build a Private CA and Manage Certificates with OpenSSL

CA and PKI Overview CA (Certificate Authority) is the entity that issues, revokes, and renews digital certificates. PKI (Public Key Infrastructure) is the broader framework that includes the CA and the Registration Authority (RA), which validates identity requests before the CA acts. Setting Up a Private CA 1. Install OpenSSL Most Linux distributions include OpenSSL; otherwise install via package manager or source. Official site: https://www.openssl.net.cn/. 2. Create Directory Structure Organize CA files under /etc/pki/CA : <code>mkdir /etc/pki/CA mkdir /etc/pki/CA/{certs,crl,newcerts,private} # Ensure index file is empty touch /etc/pki/CA/index.txt # Initialise serial number echo 01 > /etc/pki/CA/serial </code> certs : stores issued certificates. crl : holds the Certificate Revocation List. newcerts : temporary storage for newly created certificates. private : contains the CA private key. 3. Edit OpenSSL Configuration Backup the original openssl.cnf and create a new one at /etc/ssl/openssl.cnf . Key sections include: <code># CA defaults [ ca ] default_ca = CA_default [ CA_default ] dir = /etc/pki/CA certs = $dir/certs new_certs_dir = $dir/newcerts database = $dir/index.txt certificate = $dir/certs/cacert.pem private_key = $dir/private/cakey.key serial = $dir/serial default_days = 3650 default_md = sha256 preserve = no # Request defaults [ req ] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn [ dn ] C = CN ST = BeiJin L = BeiJin O = My Company OU = My Organizational Unit emailAddress = [email protected] CN = mycompany.com </code> 4. Generate a Self‑Signed Root Certificate First create the CA private key: <code>openssl genpkey -algorithm RSA -out /etc/pki/CA/private/cakey.key </code> Then create the root certificate: <code>openssl req -key /etc/pki/CA/private/cakey.key -new -x509 -days 7300 -out /etc/pki/CA/certs/cacert.pem </code> At this point the private CA is operational. Certificate Issuance by the CA 1. Generate a CSR (Certificate Signing Request) On the client side, generate a private key and CSR in one step: <code>mkdir tom cd tom sudo openssl req -new -keyout tom.key -out tom_req.csr -nodes </code> 2. Transfer CSR to the CA Create a directory on the CA to receive CSRs: <code>mkdir /etc/pki/CA/csr </code> 3. CA Validates Identity Verification is typically manual (e.g., phone call, email). 4. CA Signs the Certificate <code>sudo openssl ca -batch -in /etc/pki/CA/csr/tom_req.csr -out /etc/pki/CA/certs/tom.pem </code> Use -batch to auto‑confirm. Ensure index.txt is empty before signing. Special CA Files serial : stores the next certificate serial number; increments after each issuance. index.txt : database of all issued certificates (status, expiry, serial, DN). index.txt.attr : attributes such as unique_subject = yes controlling duplicate subject handling. index.txt.old and serial.old : backups of previous database state. Revoking Certificates 1. Revoke <code>openssl ca -revoke /path/to/certificate.pem </code> 2. Generate a New CRL <code>openssl ca -gencrl -out /etc/pki/CA/crl/crl.pem </code> The CRL lists all revoked certificates and is signed by the CA. Common File Extensions .key – private key .pem – PEM‑encoded certificate or key (Base64 with BEGIN/END markers) .csr – certificate signing request .crl – certificate revocation list .crt / .cer – alternative certificate extensions Viewing Certificate Details <code>openssl x509 -in /path/file_name -noout -text </code> This displays subject, issuer, validity period, and extensions. Certificate Issuance Process Client creates a CSR containing its public key and subject information. CA hashes the CSR and signs the hash with its private key, producing a digital signature. The signed hash, public key, and subject data are combined into an X.509 certificate. Certificate Verification Process Client receives the server’s certificate. Client extracts the signature and verifies it using the CA’s public key, obtaining the original hash. Client hashes the received certificate data independently. Client compares both hashes; a match confirms integrity and authenticity. Data Communication Example (HTTPS) During an HTTPS handshake, the server presents its certificate, the client validates it via the steps above, then establishes a symmetric session key encrypted with the server’s public key for secure data exchange.