Creating a Certificate Authority (CA) for an internal network allows you to issue trusted SSL/TLS certificates to your servers and devices without relying on public certificate authorities. By setting up a local CA using OpenSSL on a Linux server, you can secure internal communications, enable mutual TLS authentication, and maintain full control over your PKI infrastructure while ensuring that internal clients trust your self-signed identities.
Why You Need an Internal CA
Public certificate authorities are designed for external-facing services where users must trust well-known roots like Let's Encrypt or DigiCert. However, internal systems often require encryption that public CAs cannot easily provide due to cost, privacy concerns, or the need for frequent certificate rotation. An internal CA solves this by acting as a private root of trust. When you install the CA's root certificate into the trust stores of your internal machines, all certificates signed by it become automatically trusted. This is essential for securing intranets, internal APIs, and database connections. Without this setup, applications would throw security warnings because they cannot verify the identity of internal services. For more information on handling TLS connections with unknown CAs, you might find
Make cURL establish TLS connection with CA unknown useful.
Setting Up the OpenSSL Environment
The first step is preparing the Linux server where the CA will reside. Ensure OpenSSL is installed by running
openssl version. Create a dedicated directory structure to keep keys and certificates organized. A common convention involves creating a
ca directory with subdirectories for
private,
crl,
newcerts, and
certs. You must also create files like
index.txt and
serial which OpenSSL uses to track issued certificates. The
index.txt file acts as a database of all certificates issued by this CA, while
serial contains the next serial number to be used. Protecting the private key is critical; set permissions to
600 so only the owner can read it.
Configuring OpenSSL
Before generating any keys, you need a configuration file, typically named
openssl.cnf. This file defines the behavior of the CA. Key sections include
[ca] which points to your directories, and
[req] which defines default values for new certificates. You should specify the
default_md to SHA-256 for stronger security. In the
[v3_ca] section, define the subject alternative names and basic constraints. The basic constraint must be set to
critical, CA:TRUE to indicate this certificate is a CA. If you plan to issue certificates for specific internal domains, add them to the
subjectAltName field in the server certificate templates. This configuration ensures that every certificate you issue inherits the correct properties.
Generating the CA Private Key and Certificate
Now generate the CA's private key using the command
openssl genrsa -out ca/private/ca.key 4096. This creates a 4096-bit RSA key, which is currently considered secure for long-term use. Next, create the self-signed CA certificate with
openssl req -new -x509 -days 3650 -key ca/private/ca.key -out ca/certs/ca.cert.pem. During this process, you will be prompted for details like Country Name, Organization, and Common Name. The Common Name should ideally be something distinct like "Internal Root CA". This certificate will have a long validity period, often 10 years, since changing the root CA requires updating every device in your network. Distribute this
ca.cert.pem file to all clients that need to trust your internal services.
Issuing Server Certificates
To issue a certificate for an internal server, first generate its private key and a certificate signing request (CSR). Use
openssl genrsa -out server.key 2048 followed by
openssl req -new -key server.key -out server.csr. The CSR contains the public key and the server's identity details. Then, sign the CSR with your CA using
openssl ca -in server.csr -out server.cert.pem -config openssl.cnf. This command reads the
index.txt and updates the serial number. The resulting
server.cert.pem is now signed by your internal CA. Configure your web server or application to use both the server certificate and the CA certificate to establish a chain of trust. Clients receiving this certificate will validate it against the installed internal CA root.
Maintaining and Revoking Certificates
Security is not a one-time task. Regularly rotate your CA keys if possible, though this is complex. More commonly, you must manage revocation. If a server is compromised, revoke its certificate using
openssl ca -revoke server.cert.pem. This adds an entry to the
index.txt file marking it as revoked. You should also generate a Certificate Revocation List (CRL) periodically using
openssl ca -gencrl -out ca/crl/ca.crl.pem. Distribute this CRL to your clients so they can check if a presented certificate has been invalidated. For scenarios where you need to expose internal services securely, consider reading about how to
Expose Local Server on VPS Preserving Real Client IPs (OS Level) while maintaining proper TLS hygiene.
Frequently Asked Questions
How do I install the CA certificate on Windows?
Double-click the
ca.cert.pem file and select "Install Certificate". Choose "Local Machine" and place it in the "Trusted Root Certification Authorities" store. This ensures all users on that machine trust certificates signed by your internal CA.
Can I use ECDSA instead of RSA for my CA?
Yes, ECDSA offers smaller key sizes and faster operations. Use
openssl ecparam -genkey -name prime256v1 to generate the key. However, ensure your client software supports ECDSA, as some older systems may still prefer RSA.
What happens if I lose my CA private key?
If you lose the CA private key, you cannot issue new certificates or revoke existing ones. All certificates issued by that CA remain valid until they expire, but you cannot invalidate compromised ones. Always back up the CA key securely offline.
Do internal clients need the full chain or just the root?
Clients generally only need the root CA certificate in their trust store. The server should send its own certificate along with any intermediate certificates if you use a hierarchy. For a simple single-level CA, sending just the server cert is sufficient.
How often should I rotate my CA certificate?
The CA root certificate itself does not need frequent rotation because changing it requires updating every client. Set its validity to 10-25 years. Rotate the server certificates more frequently, such as annually, to limit exposure if a server key is compromised.