What is mkcert used for in practice?

What mkcert is used for in day-to-day development

In practice, mkcert is a developer convenience tool for local HTTPS. It creates certificates that your workstation trusts, so you can test secure browser flows, local APIs, and callback endpoints without fighting warning banners. That makes it useful for realistic development, but only when the trust anchor stays confined to non-production environments and disposable test setups.

The value is not that it “secures” the application by itself. The value is that it lets developers exercise HTTPS-dependent behaviour, such as cookie flags, mixed-content checks, OAuth redirects, and browser security features, against a certificate chain that behaves like a real one without involving a public certificate authority.

Why local trust matters for testing HTTPS

Many web features behave differently once HTTPS is present, especially in browsers. A locally trusted certificate lets you validate the full path from client trust to server presentation, which is important when you are testing anything that depends on TLS being enabled rather than merely simulated. That includes secure local proxies, internal dashboards, and services that need to look and act like production without exposing themselves to the public internet.

This is especially helpful in internal development environments where multiple engineers need repeatable local setups. Instead of asking everyone to click through certificate exceptions, you can standardise a local root of trust for development machines and get predictable results across browsers and tools.

It is also why mkcert is commonly associated with machine-identity and certificate lifecycle work. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide covers the broader certificate management issues that local development certificates can resemble, even though mkcert itself is usually a lightweight developer tool rather than a production PKI platform.

Where mkcert stops being appropriate

The main boundary is trust scope. A locally trusted development root should remain on developer machines and within controlled test environments. If it escapes into shared endpoints, production hosts, or long-lived team infrastructure, you have turned a convenience tool into a trust-management problem. At that point, the certificate may no longer be merely a local testing aid, because anything that trusts the root can be impersonated by certificates it signs.

That is why mkcert should be treated as a development utility, not a production certificate strategy. Production systems need managed issuance, revocation, visibility, expiry handling, and clear ownership. Local testing certificates are disposable and narrow by design, which is exactly what makes them useful.

Risk and Threat Considerations

Local certificate tooling can create real exposure if the trusted root or generated private keys spread beyond the intended developer workstation. The risk is not the certificate warning itself, but the possibility that a development trust anchor becomes broadly trusted and then usable for spoofing local services or intercepting traffic in environments that were never meant to accept it.

Failure mechanism: A locally installed root CA or its private key is reused, copied, or left on a shared system, allowing unintended trust relationships and possible impersonation of internal HTTPS services.

Impact: Browser trust can be abused beyond the lab, certificates can outlive their intended use, and the organisation can lose the clear boundary between disposable development trust and controlled production trust.

Practitioner Guidance

What to verify: Confirm that mkcert-generated certificates are only installed on developer machines or isolated test hosts, and that the local root CA is not present on production endpoints, golden images, or shared jump boxes.

Common mistake: Treating the local root CA as harmless because it is “only for development.” Once a trusted root is copied widely, the blast radius is no longer local, even if the certificate was created for a benign purpose.

Decision rule: Use mkcert when the goal is realistic HTTPS testing on a workstation or internal dev stack; use a managed production certificate process when the service is reachable by real users, production automation, or shared infrastructure.

Practitioner takeaway: mkcert is best understood as a narrow trust-enablement tool for development realism, not as a substitute for production certificate management or broader PKI governance.

Related resources from NHI Mgmt Group

• What are Jump Lists used for in practice?
• What is secp256k1 used for in practice?
• What is detect-secrets used for in practice?
• What is Brakeman used for in practice?