Setup your own CA and SSL cert for internal networking and load balancer

Prashant Vats
4 min readApr 17, 2024

We often need to ensure encrypted communication for internal network and configure SSL. Establishing your own Certificate Authority (CA) empowers you to issue and manage digital certificates for internal DNS, enhancing the security and integrity of your network. This guide will walk you through the process of creating your CA and distributing server certificates for secure communication.

Generate CA

Step 1: Generate a Private Key for Your CA

The first step in setting up your CA is to generate a private key. This key will be used to sign certificates issued by your CA. Execute the following command

openssl genrsa -out rootCAKey.pem 2048

This command generates a private key named rootCAKey.pem with a key length of 2048 bits.

Step 2: Generate a Self-Signed Certificate for Your CA

With the private key in place, the next step is to create a self-signed certificate for your CA.

ca.cnf

[req]
prompt = no
distinguished_name = dn
x509_extensions = v3_ca

[dn]
C = XX
ST = XX
L = XX
O = 2024 XX
OU = IT
CN = XX

[v3_ca]
basicConstraints=critical,CA:TRUE
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier=hash
# generate Self Signed Cert
openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem -config ca.cnf

This command generates a CA certificate (rootCACert.pem) along with the corresponding private key (rootCAKey.pem) using the configuration file ca.cnf (above). The certificate is valid for 10 years (3650 days). Do analyse the v3_ca where we have define the basicConstraints, keyUsage and subjectKeyIdentifier.

basicConstraints extension is used to specify whether a certificate is a Certificate Authority (CA) certificate or not, and if it is, whether it can sign other certificates. This extension plays a crucial role in defining the role and capabilities of the certificate. When CA:true is set in the basicConstraints extension of a certificate, it indicates that the certificate is a Certificate Authority (CA) certificate. This means that the certificate holder has the authority to issue and sign other certificates.

keyUsage defined the permitted usage of certificate, like in this case it beung used for keyCertSign and cRLSign.

Step 3: Verify the CA Certificate

To ensure the correctness of the generated CA certificate, verify it by executing

openssl x509 -in rootCACert.pem -text -noout

This command displays the details of the CA certificate for verification purposes.

Distributing Server Certificates from the CA

Now that your CA is set up, you can proceed to issue server certificates for secure communication.

Step 1: Generate a Private Key for Your Server

Start by generating a private key for your server using the following command

openssl genrsa -out server.key 2048

This command creates a private key (server.key) for your server with a key length of 2048 bits.

Step 2: Create a Certificate Signing Request (CSR)

Generate a Certificate Signing Request (CSR) for your server with the command

csr.cnf

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = subject
req_extensions = v3_req

[subject]
countryName = xx
stateOrProvinceName = xx
localityName = xx
organizationName = xx
OU = xx
commonName = abc.internal
emailAddress = xx
subjectAltName = xx

[v3_req]
basicConstraints = CA:false
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = abc.internal
DNS.2 = *.abc.internal
# generate CSR
openssl req -config csr.cnf -new -key server.key -out server.csr

This command creates a CSR (server.csr) for your server using the configuration file csr.cnf.

Optionally, you can verify the CSR using the command:shellCopy code

openssl req -in server.csr -text -noout -verify

Step 3: Sign the CSR with Your CA

Sign the CSR with your CA to generate the server certificate. Execute the following command:

openssl x509 -req -sha256 -in server.csr -CA rootCACert.pem -CAkey rootCAKey.pem -CAcreateserial -out server.crt \
-extfile csr.cnf -days 365 -extensions v3_req

This command signs the CSR using the CA certificate and private key, producing the server certificate (server.crt). It is valid for 1 year (365 days) and includes the specified extensions from the csr.cnf file.

Verify the generated certificate using the CA file with the commands:

openssl verify -CAfile rootCACert.pem server.crt
openssl x509 -in server.crt -text -noout

Combining CA and Server Certificates

For the completeness of the certificate chain, combine the CA and server certificates using the following command

cat server.crt rootCACert.pem > tls.crt

This command concatenates the server certificate and the CA certificate into a single file (tls.crt), ensuring the certificate chain is intact.

Using the Secret in Kubernetes for Ingress Controller

In Kubernetes, you can utilize the generated certificate by creating a secret for the Ingress Controller. Execute the following command:shellCopy code

kubectl create secret tls default-internal-crt --cert=tls.crt --key=server.key

This command creates a TLS secret named default-internal-crt using the combined certificate (tls.crt) and the private key (server.key).

Adding CA Certificate to Your macOS

To ensure trust in the CA certificate on your macOS system, execute the following command

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" rootCACert.pem

This command adds the CA certificate (rootCACert.pem) to the list of trusted certificates in the macOS system keychain, establishing trust for certificates signed by your CA.

--

--