Self-signed PKI for the homelab

I'd like to build my homelab in a way that would be capable operate as a production system. So do some firewalling, VLANs and the services should communicate through an encrypted channel with TLS. So basically I could build my PKI for the homelab by hand with the help of OpenSSL like below.

PKI by hand with OpenSSL

In advance, I'm not too paranoid, so I allowed myself some simplifications, like the use of -nodes argument that is skips encrypting the private key (no passphrase) and I did not use CSRs (Certificate Signing Requests) rather I produced the keypair in one step.

1. Generate the root CA public and private key with one command as a self-signed certificate.

openssl req -x509 \
    -newkey rsa:4096 \
    -keyout root_ca.key \
    -out root_ca.crt \
    -days 3650 \
    -nodes

1. Generate the intermediate CA public and private key with one command and sign with the previously generated root CA certificate.

openssl req \
    -newkey rsa:4096 \
    -nodes \
    -keyout intermediate_ca.key \
    -x509 \
    -days 3650 \
    -CA root_ca.crt \
    -CAkey root_ca.key \
    -subj '/C=BE/ST=Belgium/L=Bruxelles/O=MyOrg/CN=IntermediateCA/emailAddress=[e-mail]' \
    -out intermediate_ca.crt

1. Generate the server certificates, as many as you need.

openssl req \
    -nodes \
    -CA intermediate_ca.crt \
    -CAkey intermediate_ca.key \
    -keyout server.key \
    -x509 -days 365 \
    -subj '/C=BE/ST=Belgium/L=Bruxelles/O=MyOrg/CN=server.home.lab/emailAddress=[e-mail]' \
    -addext 'subjectAltName = DNS:server, DNS:server.home.lab, IP:192.168.0.10' \
    -out server.crt

With the command above I generated a TLS keypair for the server application signed by the intermediate CA. I added a couple of SAN (Subject Alternative Name), so the certificate will valid if I don't want to use the FQDN or I use the IP address.

SAN (Subject Alternative Name) is an extension in X.509 certificates that allows multiple identities (such as domain names, IP addresses, or email addresses) to be associated with a single certificate. It is commonly used in SSL/TLS certificates to secure multiple domains or subdomains.

Unlike the Common Name (CN), which only allows one hostname, SAN allows multiple names in a single certificate. On top of that modern browsers and applications rely on SAN rather than CN for domain validation. If SAN is missing, many browsers will flag the certificate as invalid and required for IP-based Certificates as you had seen above.