TL;DR: A tiny internal certificate authority for a homelab can be built using a YubiKey, ACME, and optional TRNG support so TLS certificates can be issued and renewed locally with stronger key protection and less manual handling, according to Smallstep. The useful lesson is that certificate lifecycle automation is now practical even in small environments, and trust boundaries should be treated as governed infrastructure, not ad hoc setup.
At a glance
What this is: This is a homelab guide for building a small internal certificate authority that uses a YubiKey, ACME, and automated renewal to issue and manage TLS certificates locally.
Why it matters: It matters because certificate issuance, renewal, and key custody are identity controls, not just plumbing, and the same lifecycle discipline applies to machine identities in larger environments.
By the numbers:
- The tiny CA setup described in the article has a total cost of around US$100.
- step-ca issues certificates with a 24-hour lifetime by default.
- The tutorial uses a Raspberry Pi 4 Model B 2GB with at least 16GB of microSD storage.
Context
A tiny certificate authority is a controlled way to issue, trust, and renew TLS certificates inside a private environment. The governance problem it solves is familiar to identity teams: once certificates become operational dependencies, they need lifecycle ownership, not one-off manual handling.
This article treats internal PKI as an identity control plane for the homelab. That framing matters because the same patterns, root trust, intermediate issuance, renewal, and offline key custody, are the building blocks of machine identity governance as well.
Key questions
Q: How should teams govern certificate expiry across large service estates?
A: Treat certificate expiry as an identity lifecycle control, not a calendar reminder. Maintain a central inventory, assign an owner to every certificate, and monitor renewal failures as actively as expiry dates. That approach reduces the chance that a valid certificate is quietly headed toward a hard outage.
Q: Why do hardware security keys matter for private certificate authorities?
A: Hardware security keys reduce the chance that CA private keys are copied, backed up poorly, or left sitting on a general-purpose disk. They do not remove the need for recovery planning, but they do narrow the exposure of the signing key and make physical custody part of the control model.
Q: When should organisations use ACME for internal certificate renewal?
A: Use ACME when you want renewal to be routine, repeatable, and policy-driven rather than a manual operator task. It is especially useful when short-lived certificates are part of the design, because the protocol gives endpoints a reliable way to obtain new certificates before the old ones expire.
Q: What should teams do if their root certificate is lost or the CA hardware fails?
A: They should restore from an offline backup and verify the recovery path before the CA is relied on in production. A certificate authority is only as resilient as its ability to recover trust material, re-establish issuance, and avoid forcing a full rebootstrap of every dependent service.
Technical breakdown
Why internal ACME changes certificate operations
ACME is an automated protocol for requesting and renewing certificates without manually reissuing files each time a service changes. In a private environment, it moves certificate management from an ad hoc operator task to a repeatable issuance workflow. That matters because certificate expiry is operational failure, not just a cryptographic detail. When the CA is reachable on the local network, endpoints can request short-lived certificates on demand and renew them before they lapse. This shifts the control point from human memory to policy and automation. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Treat ACME as the lifecycle mechanism that replaces manual certificate handling with governed renewal.
Why YubiKey-backed signing changes the trust model
The design uses a YubiKey to hold CA private keys and perform signing operations through the PIV application. That means the signing authority is no longer just a file sitting on disk. The operational benefit is not that the key becomes invulnerable, but that the highest-value private material is harder to copy, easier to isolate, and tied to a physical device presence. In PKI terms, the root and intermediate chain still exists, but the signing trust anchor is physically constrained instead of living entirely in the filesystem. See the Hardware Security Keys Guide.
Practical implication: Move CA signing keys off general-purpose storage and treat hardware custody as part of the trust boundary.
How offline root and online intermediate CAs separate risk
The article uses a root CA and an intermediate CA, which is the standard way to reduce exposure of the root key. The root signs the intermediate certificate, while the intermediate signs issued leaf certificates. Operationally, the root can stay offline most of the time, while the intermediate remains online for routine issuance. That separation matters because compromise of the online issuing tier should not automatically mean compromise of the root trust anchor. It is the practical structure behind resilient private PKI.
Practical implication: Keep the root offline whenever possible and limit daily issuance to the intermediate tier.
Threat narrative
Attacker objective: The attacker would aim to issue trusted certificates or steal CA signing material so they can impersonate internal services or intercept trusted traffic.
- Entry begins with certificate and key material being created and handled during setup, which becomes the sensitive trust boundary for the CA environment.
- Credential exposure would occur if private keys, passwords, or trust material were copied off the intended storage path or left accessible on the host.
- Escalation would come from misuse of the CA signing capability, because anyone with administrative access to the CA could mint trusted certificates for internal services.
- Impact would be unauthorized trust establishment inside the homelab, allowing a forged service identity to impersonate legitimate endpoints.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate lifecycle is the real control, not certificate creation: The article is useful because it shows that a CA is only manageable when issuance, renewal, custody, and trust bootstrapping are treated as one lifecycle. A certificate that exists but is not renewed, trusted, or scoped correctly is operationally incomplete. The practitioner lesson is to govern certificates as identity artifacts with ownership, not as static files.
Hardware-backed signing turns key custody into an access decision: Putting CA keys on a YubiKey changes the protection model from filesystem security to device-mediated signing. That does not eliminate governance risk, but it narrows where the highest-value key material can be used. For teams managing service identities, that distinction matters because the custody model determines how far a compromise can spread.
Short-lived certificates reduce standing trust debt: The 24-hour certificate lifetime in the tutorial is not just a convenience choice, it is a boundary on how long a credential remains valid if something goes wrong. Short lifetimes force renewal automation and make unmanaged trust paths harder to sustain. The named concept here is trust debt: the operational burden created when certificate validity outlives the system that issued or controls it. The practitioner implication is to make certificate duration an explicit governance decision.
Internal PKI is a machine identity programme in miniature: The same patterns here appear in larger estates with service accounts, workload identities, and mTLS. Root trust, intermediate issuance, device-bound custody, and renewal automation all map directly to machine identity governance. The difference is scale, not principle, so homelab PKI is a useful proving ground for identity controls that later need enterprise enforcement.
Offline backup of the root material is a resilience decision, not a convenience: The tutorial’s emphasis on a second copy of the CA material shows that recovery planning belongs in identity operations from the start. If the CA is the issuer of trust, losing the ability to recover it becomes an availability and governance failure at once. Practitioners should treat CA recovery as part of identity continuity, not disaster cleanup.
Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Short-lived certificate programmes change the governance burden: when certificates live for 24 hours, renewal stops being an occasional task and becomes a control surface. That pushes teams toward automation, observability, and clear ownership for certificate issuance, especially where services depend on TLS for both encryption and authentication.
The deeper implication is that internal PKI should be managed like a machine identity platform, not a side project. Root trust, intermediate delegation, hardware custody, and bootstrap procedures all need to be documented before the first outage or hardware failure proves why they matter.
For practitioners
- Define certificate ownership before issuance Assign a clear owner for the root, intermediate, renewal schedule, and trust bootstrap process so the CA does not become an orphaned utility.
- Use hardware-backed signing for CA keys Keep signing keys on dedicated hardware where possible and avoid leaving root material on general-purpose storage that is broadly reachable. See the Hardware Security Keys Guide.
- Automate renewal for short-lived certificates Set renewal windows before expiry and make client-side renewal part of the operational design, not a manual exception process.
- Separate root trust from online issuance Keep the root CA offline for recovery and delegation purposes while limiting routine certificate issuance to the intermediate CA.
- Test trust bootstrap on every new device Verify that devices actually trust the installed root certificate and can complete certificate-based authentication before they are placed into service.
Key takeaways
- Internal certificate authorities become governance problems as soon as they are used for service trust, not just encryption.
- The article's design uses short-lived certificates, hardware-backed key custody, and ACME automation to reduce manual trust handling.
- A resilient private PKI needs recovery planning, renewal automation, and clear ownership of root and intermediate trust material.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · NHI Authentication Guide · Guide to SPIFFE and SPIRE
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CA private keys and passwords are the sensitive material this tutorial is trying to keep off disk. |
| NHI-07 — Long-Lived Secrets | The tutorial uses short-lived certificates to reduce the risk of long-lived trust artifacts. | |
| NHI-01 — Improper Offboarding | A CA needs a defined recovery and decommission path when hardware, keys, or trust anchors change. | |
| Recommendation — Protect CA keys and passwords from repository, disk, and backup exposure. Replace long-lived certificate habits with short-lived issuance and renewal automation. Document offboarding and recovery steps for CA hardware and trust material. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance and renewal are authenticator lifecycle controls for machine identities. |
| Recommendation — Apply authenticator management controls to certificate issuance, rotation, and revocation. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The core abuse path would be theft of CA signing material and misuse of trusted certificates. |
| Recommendation — Map CA key theft and certificate misuse to credential access and exfiltration hunting. | ||
Key terms
- Certificate Authority: A Certificate Authority is a trusted organisation that issues and signs digital certificates binding identities to public keys. Defenders rely on it to establish trust for TLS and other certificate-based systems, while attackers target weak issuance processes, stolen signing keys, or mis-issuance to impersonate services and users.
- ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
- Intermediate Certificate Authority: An intermediate certificate authority is a delegated signing layer that issues certificates on behalf of a higher-level root CA. In device trust programmes, it helps scale issuance while preserving separation of duties, but it also becomes a critical governance point because its policies shape device identity integrity.
- Hardware security key: A hardware security key is a physical authenticator that stores cryptographic material and proves possession during login. Because the private key is not copied into the browser or app, it is much harder for attackers to steal, replay, or phish than a shared secret.
Deepen your knowledge
NHI governance, machine identity security, and workload identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org