What are the key mkcert best practices?

Why mkcert should stay in the development trust boundary

mkcert is designed to make local HTTPS easier, not to replace a production PKI. Treat the local certificate authority as disposable developer tooling: useful for browsers, test clients, and loopback services, but inappropriate for real trust chains, externally reachable systems, or anything that crosses environment boundaries. The main discipline is to keep trust local and temporary.

That boundary matters because a locally trusted root changes how every certificate on that endpoint is evaluated. If the same CA is reused too broadly, or if issued certificates leak into shared images, test data, or production-like endpoints, the trust problem stops being local and becomes hard to contain.

Keep the local CA private and limit who can install or export it. If you need a broader explanation of how certificate lifecycles, private CAs, and endpoint trust anchors fit together, the Machine Identity, PKI and Certificate Lifecycle Guide is the right companion reference.

How to use mkcert without creating certificate sprawl

Only generate the certificates you actually need for the current development task. Over-issuing local certificates creates unnecessary private key copies, more places for developers to make mistakes, and more cleanup work when an environment changes. A small, deliberate set of certificates is easier to audit and revoke from local trust stores.

Keep private keys out of shared folders, build artifacts, and chat-driven handoffs. The danger is not only leakage after compromise, but accidental reuse, where a key issued for one test app gets copied into another service or environment because it “worked yesterday.”

For teams that issue application or service keys as part of local testing, API Key Management Guide offers the same practical discipline around scoping, storage, and revocation that you should apply to any sensitive credential material.

What to clean up before a developer laptop or test box leaves the lab

Before an endpoint moves from lab use to broader use, remove the local CA trust anchor and any test certificates that were installed to support development. That includes browser trust stores, OS trust stores, CI runners, and any VM or container base image that may have absorbed the test root. If you leave the anchor behind, later certificates can inherit trust they should never have outside the lab.

Also review where the local CA has been installed across the team. The practical question is not “did we create it once?” but “where does it still exist, and who can still trust it?” That inventory determines whether a local convenience has become a persistent trust artifact.

When developers need to understand how trust anchors and endpoint scope interact, the broader policy framing in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for thinking about access control, configuration management, and control inheritance.

Practitioner Guidance

What to verify: Confirm that mkcert is installed only on developer and lab systems, and that no test CA or issued private key has been copied into shared images, long-lived endpoints, or production-like environments. The cleanup check should include browser stores, OS trust stores, and CI assets.

Common mistake: Teams often treat the local CA as harmless because it “only helps in dev,” then forget that any trusted root can outlive the test it was created for. The error is not using mkcert, but failing to bound its trust lifecycle and distribution.

Practitioner takeaway: mkcert is safe when its trust is deliberately narrow, temporary, and easy to remove, but it becomes a governance problem as soon as developers stop tracking where the local CA and its certificates still exist.

Related resources from NHI Mgmt Group

• What are the key Cyber Range Training best practices?
• What are the key Cloud Asset Inventory best practices?
• What are the key bcrypt best practices?
• What are the key Safetensors best practices?