BLOG POSTS

MangoHost Blog / How to Set Up and Configure a Certificate Authority (CA) on Ubuntu 24

How to Set Up and Configure a Certificate Authority (CA) on Ubuntu 24

Setting up a Certificate Authority (CA) on Ubuntu 24 lets you issue and manage your own digital certificates for internal networks, development environments, or private infrastructure. This guide walks through building a complete CA infrastructure from scratch, covering everything from initial OpenSSL configuration to certificate management and common troubleshooting scenarios you’ll encounter in production environments.

Understanding Certificate Authority Fundamentals

A Certificate Authority operates as a trusted entity that issues digital certificates to verify the identity of websites, servers, and users. When you create your own CA, you’re essentially becoming the root of trust for your organization’s certificate infrastructure.

The CA hierarchy typically consists of three main components:

Root CA – The top-level authority that signs intermediate certificates
Intermediate CA – Secondary CAs that issue end-user certificates
End-entity certificates – Server, client, or user certificates for actual services

Ubuntu 24 comes with OpenSSL 3.0, which includes several improvements over previous versions including better algorithm support and enhanced security features. The process involves creating a root certificate, establishing proper directory structures, and implementing certificate signing workflows.

Initial System Setup and Prerequisites

Before diving into CA creation, ensure your Ubuntu 24 system is properly configured. Start by updating the package repository and installing necessary tools:

sudo apt update && sudo apt upgrade -y
sudo apt install openssl ca-certificates tree -y

Create a dedicated directory structure for your CA operations. This organization prevents confusion and maintains security boundaries:

sudo mkdir -p /opt/ca/{root-ca,intermediate-ca,newcerts,certs,crl,private}
sudo chmod 700 /opt/ca/private
sudo chown -R $USER:$USER /opt/ca

Set up the serial number and index files that OpenSSL requires for certificate tracking:

cd /opt/ca
echo 1000 > serial
touch index.txt
echo 1000 > crlnumber

Root CA Configuration and Creation

The root CA configuration file defines how certificates are issued and what extensions they contain. Create a comprehensive configuration file:

cat > /opt/ca/openssl-root.cnf << 'EOF'
[ ca ]
default_ca = CA_default

[ CA_default ]
dir               = /opt/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

default_md        = sha256
name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

[ policy_strict ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha256
x509_extensions     = v3_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
EOF

Generate the root CA private key with strong encryption. This key should be heavily protected as it's the foundation of your entire certificate infrastructure:

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

Create the root certificate using the private key and configuration file:

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

During this process, you'll be prompted to enter certificate details. Use consistent information across your organization:

Country Name: US
State: California
City: San Francisco
Organization: YourCompany Internal CA
Organizational Unit: IT Department
Common Name: YourCompany Root CA
Email: admin@yourcompany.com

Certificate Signing and Management Workflows

With your root CA established, you can now sign certificates for servers and services. The process involves creating a Certificate Signing Request (CSR) and then signing it with your CA.

For server certificates, first generate a private key and CSR:

# Generate server private key
openssl genrsa -out /opt/ca/private/server.key.pem 2048

# Create certificate signing request
openssl req -config /opt/ca/openssl-root.cnf \
    -key /opt/ca/private/server.key.pem \
    -new -sha256 -out /opt/ca/server.csr.pem

Sign the CSR to create the server certificate:

openssl ca -config /opt/ca/openssl-root.cnf \
    -extensions server_cert -days 365 -notext -md sha256 \
    -in /opt/ca/server.csr.pem \
    -out /opt/ca/certs/server.cert.pem

Verify the certificate was created correctly and contains the expected information:

openssl x509 -noout -text -in /opt/ca/certs/server.cert.pem

Real-World Use Cases and Applications

Internal CAs prove invaluable in several scenarios. Development teams often use them to create SSL certificates for local development environments, eliminating browser security warnings. Container orchestration platforms like Kubernetes leverage internal CAs for securing cluster communication between nodes and pods.

For VPS environments, an internal CA simplifies certificate management across multiple virtual machines without relying on external certificate authorities for internal services. Similarly, dedicated server deployments benefit from internal CAs when managing certificates for internal APIs, databases, and monitoring systems.

Consider this practical example for a microservices architecture:

# Generate certificates for multiple services
services=("api-gateway" "user-service" "payment-service" "notification-service")

for service in "${services[@]}"; do
    # Generate private key
    openssl genrsa -out /opt/ca/private/${service}.key.pem 2048
    
    # Create CSR
    openssl req -config /opt/ca/openssl-root.cnf \
        -key /opt/ca/private/${service}.key.pem \
        -new -sha256 -out /opt/ca/${service}.csr.pem \
        -subj "/C=US/ST=California/L=San Francisco/O=YourCompany/OU=Services/CN=${service}.internal"
    
    # Sign certificate
    openssl ca -config /opt/ca/openssl-root.cnf \
        -extensions server_cert -days 365 -notext -md sha256 \
        -in /opt/ca/${service}.csr.pem \
        -out /opt/ca/certs/${service}.cert.pem -batch
done

CA Alternatives and Comparison

Several alternatives exist for certificate management, each with distinct advantages and limitations:

Solution	Setup Complexity	Cost	Automation	Best For
Self-Signed OpenSSL CA	Medium	Free	Script-based	Internal networks, development
Let's Encrypt	Low	Free	Excellent	Public-facing websites
HashiCorp Vault	High	Free/Paid	Excellent	Enterprise environments
AWS Certificate Manager	Low	Paid	Good	AWS-hosted applications
Commercial CAs	Low	Expensive	Limited	Public websites, compliance

For organizations requiring advanced features like automatic certificate rotation, HashiCorp Vault provides a comprehensive solution. However, the learning curve is significantly steeper compared to a basic OpenSSL CA setup.

Security Best Practices and Common Pitfalls

Securing your CA infrastructure requires attention to several critical areas. The root CA private key represents your highest-value asset and should be stored offline when possible. Consider using hardware security modules (HSMs) for production environments handling sensitive data.

Implement proper file permissions across your CA directory structure:

# Secure all private keys
find /opt/ca/private -type f -exec chmod 400 {} \;
find /opt/ca/private -type d -exec chmod 700 {} \;

# Set appropriate permissions for certificates and public files
find /opt/ca/certs -type f -exec chmod 444 {} \;
find /opt/ca -name "*.cnf" -exec chmod 644 {} \;

Common pitfalls include using weak key sizes, inadequate backup procedures, and failing to implement certificate revocation lists (CRLs). Generate a CRL even if you don't immediately revoke certificates:

openssl ca -config /opt/ca/openssl-root.cnf -gencrl -out /opt/ca/crl/ca.crl.pem

Monitor certificate expiration dates to prevent service disruptions. Create a simple monitoring script:

#!/bin/bash
# Certificate expiration checker
find /opt/ca/certs -name "*.pem" -type f | while read cert; do
    expiry=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
    expiry_epoch=$(date -d "$expiry" +%s)
    current_epoch=$(date +%s)
    days_until_expiry=$(( (expiry_epoch - current_epoch) / 86400 ))
    
    if [ $days_until_expiry -lt 30 ]; then
        echo "WARNING: $cert expires in $days_until_expiry days"
    fi
done

Troubleshooting Common Issues

Certificate management inevitably presents challenges. When certificates fail validation, start by verifying the certificate chain and checking for common configuration errors.

If certificate signing fails with "unknown certificate extensions" errors, ensure your OpenSSL configuration file includes all necessary extension sections. The server_cert extension section must be properly defined in your configuration.

Browser certificate warnings often indicate missing Subject Alternative Names (SANs). Modern browsers require SANs even for single-domain certificates. Add SAN extensions to your configuration:

[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = api.example.com
IP.1 = 192.168.1.100

When encountering "unable to load certificate" errors, verify file paths and permissions. OpenSSL provides detailed error messages when run with verbose flags:

openssl x509 -in /opt/ca/certs/server.cert.pem -text -noout -verify

For debugging certificate chain issues, use the verify command with your CA certificate:

openssl verify -CAfile /opt/ca/certs/ca.cert.pem /opt/ca/certs/server.cert.pem

Database corruption in the CA index file occasionally occurs during concurrent operations. Back up your index.txt file regularly and rebuild it if necessary:

# Backup current index
cp /opt/ca/index.txt /opt/ca/index.txt.backup

# Rebuild index from certificate directory
rm /opt/ca/index.txt
touch /opt/ca/index.txt
find /opt/ca/newcerts -name "*.pem" -exec openssl x509 -in {} -noout -serial -subject \; >> /opt/ca/index.txt

Setting up a Certificate Authority on Ubuntu 24 provides tremendous flexibility for managing internal certificates while maintaining security and compliance requirements. The OpenSSL toolkit offers robust functionality for enterprise-grade certificate management, and with proper configuration and security practices, your internal CA can serve as a reliable foundation for your organization's PKI infrastructure. Regular maintenance, monitoring, and backup procedures ensure long-term success and minimize service disruptions from certificate-related issues.

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.