Setup your own CA and SSL cert for internal networking and load balancer
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.