Your first homelab certificate

1. Prepare a small, private lab

Start with one Linux host for myOwnCA, one service host, and a client you control. They can be separate virtual machines. Choose a local name such as service.home.arpa and point local DNS or a hosts entry at the service.

Use software signing for the first walkthrough. No HSM, TrueRNG, or cloud account is required. Free non-commercial use allows 10 active certificate identities; a genuine renewal retains its existing identity slot.

python3 -m venv .venv
. .venv/bin/activate
pip install .
myownca

The first launch prints a setup address and one-time token. By default the wizard is at http://127.0.0.1:8765/setup. Keep this listener private. For a remote host, forward it through SSH:

ssh -L 8765:127.0.0.1:8765 your-user@your-ca-host

Open the loopback setup URL in your local browser and enter the token from the host’s console. The application’s supplied Compose stack is another option for evaluation access holders; it must be built from that checkout and requires proxy TLS material first. Use standalone deployment for local PKCS#11 hardware.

2. Create the Test/Lab hierarchy

1. Select Test/Lab, SQLite, and the software signing backend.
2. Set the service URLs to the addresses your lab clients can reach. Review CRL, AIA, and OCSP publication settings before issuing certificates.
3. In the issuing CA step, choose Test/Lab — create local CA and confirm with CREATE LAB CA.
4. Create the initial administrator account and save its temporary credentials. Review role-based TOTP settings.
5. Finish setup, sign in, and establish the Certificate Operator accounts needed for your issuance policy. Administrators manage templates; operators approve requests.

Test/Lab creates a throwaway local root and issuer for evaluation. A long-lived production deployment uses the offline-root ceremony; do not promote a lab root into production trust.

3. Issue a certificate for your service

1. Create or select a holder and a TLS server template. Allow the desired DNS SAN and server-authentication purpose.
2. Generate a service key and CSR on the service host, following the Nginx or Apache guide.
3. Submit the CSR and check the requested subject, SAN, and template. Obtain distinct operator approvals: first issuance defaults to two, configurable per template.
4. Export the issued certificate and issuing chain. The service private key stays on the service host.

4. Install trust on your clients

Export the public root certificate as PEM. Verify its SHA-256 fingerprint against the CA through a trusted channel, then install it only on lab clients you control. Never distribute the root private key.

openssl x509 -in root.crt -noout -subject -fingerprint -sha256

On a Debian/Ubuntu client, add the PEM root to the system trust store:

sudo install -m 0644 root.crt /usr/local/share/ca-certificates/myownca-lab.crt
sudo update-ca-certificates

For a single command, use curl --cacert root.crt instead of changing system trust. Browsers and other applications can maintain their own stores; import the verified root in their certificate-authority settings if they do not use the system store. myOwnCA does not automatically distribute root trust.

5. Keep the lab working

• Enable expiry reminders and confirm delivery. Renew through the existing certificate identity, then install the replacement on the service and reload it.
• Practice revocation with a disposable client identity. Refresh the service’s CRLs and verify that new connections are rejected.
• Back up application state and secrets; test restoration before depending on the installation.
• When retiring the lab, remove its root from every trust store where you installed it.

Next, explore hardware-protected signing and TrueRNG, or review the complete feature reference.