Introduction
Zero Trust is no longer just a buzzword – it is a security principle that fundamentally changes how we design IT environments. Instead of relying on implicit trust inside networks, every user, service, and device must continuously prove its identity. At the core of this approach lies a Public Key Infrastructure (PKI).

PKIs in corporate environments are often large and complex. But the need for secure identity management is not limited to enterprises: homelabs, SMBs, and even production environments can benefit from a well-structured PKI. Lightweight but flexible tools like EasyRSA make it possible to implement professional standards without the overhead of a full enterprise PKI stack.
In this article, we’ll build a full PKI for our fictional company Example Cooperation (examplecorp.io
), including a Root-CA, Intermediate-CA, wildcard certificates, SAN certificates, and real-world integrations such as HAProxy, Proxmox, and Netbox.
The goal: a professional, future-proof PKI that works just as well in a homelab as it does in production.
Naming Conventions
Before diving into commands, let’s define clear naming conventions:
- Root-CA:
Example Cooperation Root-CA
- Intermediate-CA:
Example Cooperation Intermediate-CA
- Wildcard Certificates: e.g.,
*.examplecorp.io
- Service Certificates:
- Proxmox →
pve01.examplecorp.io
- Netbox →
netbox.examplecorp.io
- Proxmox →
This consistency helps avoid confusion, especially when scaling up or troubleshooting later.
Installing EasyRSA
First, prepare your system. The following example uses a Fedora/RHEL-like environment:
dnf update
dnf install easy-rsa
adduser pki
su - pki
Create the working directory and link EasyRSA:
mkdir ~/easy-rsa
ln -s /usr/share/easy-rsa/3/* ~/easy-rsa/
chmod 700 ~/easy-rsa
cd ~/easy-rsa
Root vs. Intermediate CA in Practice
In production, the Root-CA is kept offline to minimize the risk of compromise, while all day-to-day certificate operations are handled by the Intermediate-CA. This separation allows for safer rotation and renewal without touching the Root.
In a homelab, you have to decide whether this level of separation is really necessary – it can feel like using a cannon to kill a mosquito. For small, internal setups, you might choose to keep the Root-CA online for convenience, but following the offline Root principle is still a good habit if you want to practice professional PKI management.
Preparing the Root CA
Initialize the PKI:
EASYRSA_PKI=ca ./easyrsa init-pki
EASYRSA_PKI=ca ./easyrsa build-ca
When prompted, use the following values (adapt for your environment):
Country Name: DE
State: Rhineland-Palatinate
Locality: Mainz
Organization Name: Example Cooperation
Organizational Unit: examplecorp.io
Common Name: Example Cooperation Root-CA
Email Address: info@examplecorp.io
Building the Intermediate CA
Using an intermediate CA protects the Root-CA from day-to-day usage.
EASYRSA_PKI=intermediate ./easyrsa init-pki
EASYRSA_PKI=intermediate ./easyrsa build-ca subca
Import the request into the Root-CA and sign it:
EASYRSA_PKI=ca ./easyrsa import-req intermediate/reqs/ca.req intermediate
EASYRSA_PKI=ca ./easyrsa sign-req ca intermediate
cp ca/issued/intermediate.crt intermediate/ca.crt
Certificate Lifetimes – Best Practices vs. Homelab
In production, certificates should be short-lived (90 days to 1 year) to limit risk and enforce regular renewal. In a homelab without automation, this can be impractical. A reasonable compromise is 2–3 years for internal services, while keeping critical or external-facing systems on shorter lifetimes. This balances security with time saved.
Certificate Expiry Considerations
By default, EasyRSA sets certificate expiry to around 825 days. For long-lived lab setups, you might want to temporarily extend this:
set_var EASYRSA_CERT_EXPIRE 18200 # ~50 years
After issuing long-lived certificates (e.g., for your Intermediate-CA), return the value back to something more realistic:
set_var EASYRSA_CERT_EXPIRE 825
Generating Wildcard Certificates
Wildcard certificates simplify deployments when multiple subdomains are needed.
export EASYRSA_EXTRA_EXTS="subjectAltName=DNS:*.examplecorp.io"
EASYRSA_PKI=intermediate ./easyrsa --req-cn="*.examplecorp.io" gen-req wildcard.examplecorp.io nopass
EASYRSA_PKI=intermediate ./easyrsa sign-req server wildcard.examplecorp.io
Also generate Diffie-Hellman parameters:
EASYRSA_PKI=intermediate ./easyrsa gen-dh
Using Certificates in HAProxy
HAProxy requires certificate bundles that combine key, certificate, and CA chain.
Decrypt the key if needed:
openssl rsa -in crypted.key -out decrypted.key
Combine files:
cat server.crt server.key ca.crt > server.pem
Configure HAProxy:
frontend https_frontend
bind *:443 ssl crt /etc/ssl/examplecorp/server.pem
Reference: HAProxy SSL Termination
Service-Specific Certificates
Proxmox
EASYRSA_PKI=intermediate ./easyrsa --req-cn="pve03.examplecorp.io" gen-req pve03.examplecorp.io nopass
EASYRSA_PKI=intermediate ./easyrsa sign-req server pve03.examplecorp.io
Netbox (SAN Certificate)
EASYRSA_PKI=intermediate ./easyrsa --subject-alt-name="DNS:netbox.examplecorp.io,DNS:netbox01.examplecorp.io" gen-req netbox.examplecorp.io nopass
EASYRSA_PKI=intermediate ./easyrsa sign-req server netbox.examplecorp.io
Bundling Certificates
For many services, you’ll need a full chain bundle:
cat intermediate/issued/server.crt intermediate/ca.crt > server-bundle.crt
cat intermediate/issued/client.crt intermediate/ca.crt > client-bundle.crt
Distributing the Root and Intermediate CA
In a Zero Trust setup, both the Root-CA and the Intermediate-CA form the trust chain for all service certificates. While the Root-CA is usually kept offline, the Intermediate-CA handles daily signing. To ensure clients trust your services, both CAs must be imported into the client system.
Linux / RHEL & clones
# Copy CA certificates from the CA server to the client system
scp root@ca-server:/home/pki/easy-rsa/ca/ca.crt /tmp/root-ca.crt
scp root@ca-server:/home/pki/easy-rsa/intermediate/ca.crt /tmp/intermediate-ca.crt
# Install Root and Intermediate CA
sudo mkdir -p /etc/pki/ca-trust/source/anchors
sudo cp /tmp/root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo cp /tmp/intermediate-ca.crt /etc/pki/ca-trust/source/anchors/
sudo chmod 644 /etc/pki/ca-trust/source/anchors/*.crt
sudo update-ca-trust
Debian / Ubuntu
# Copy CA certificates from the CA server
scp root@ca-server:/home/pki/easy-rsa/ca/ca.crt /tmp/root-ca.crt
scp root@ca-server:/home/pki/easy-rsa/intermediate/ca.crt /tmp/intermediate-ca.crt
# Install Root and Intermediate CA
sudo mkdir -p /usr/local/share/ca-certificates/
sudo cp /tmp/root-ca.crt /usr/local/share/ca-certificates/root-ca.crt
sudo cp /tmp/intermediate-ca.crt /usr/local/share/ca-certificates/intermediate-ca.crt
sudo chmod 644 /usr/local/share/ca-certificates/*.crt
sudo update-ca-certificates
Windows
- Copy both
.crt
files to the client. - Double-click each certificate → Install Certificate.
- Place the Root-CA in Trusted Root Certification Authorities and the Intermediate-CA in Intermediate Certification Authorities.
Android
- Copy both
.crt
files to the device. - Go to Settings → Security → Install from storage.
- Select and install both certificates.
iOS
- Email or transfer both
.crt
files to the device. - Open each certificate → follow prompts to install.
- After installation, go to Settings → General → About → Certificate Trust Settings and enable full trust for the Root-CA.
This ensures that all certificates issued by your Intermediate-CA are trusted across desktop and mobile platforms in your homelab environment.
Conclusion
By creating a Root-CA, Intermediate-CA, and service-specific certificates, you have built a professional-grade PKI for your homelab. While this article uses Example Cooperation as a fictional environment, the same approach applies to production systems.
In a Zero Trust architecture, this PKI forms the backbone of identity and trust. Every service, host, and user must authenticate with cryptographic proof rather than assumptions. Even in a homelab, following these practices improves both security and realism, making your environment closer to enterprise standards.