mkcert
A command-line tool for creating locally trusted certificates for localhost, test domains and local IP addresses during development.
What mkcert does
mkcert creates a local certificate authority on a development device and uses it to issue certificates for names such as localhost, loopback addresses and explicitly scoped test domains. This avoids browser warnings during local HTTPS testing while keeping the trust decision inside the development environment.
Trust boundaries and server setup
The local root CA is a device trust anchor, not a public certificate service. The generated certificate and private key still need to be configured in the development server, proxy or framework, and the hostname must match the certificate. Browsers, Node.js, Java and other runtimes may read different trust stores.
Private-key handling
The root CA private key has authority to issue certificates trusted by that device. Keep it on the controlled development machine, exclude it from repositories and images, and create separate CAs for separate devices or teams. Remove the CA and issued files when the test environment is retired.
Maintenance note
This page reviews mkcert 1.4.4 for Windows x64, local CA installation, name-scoped certificates, server configuration and BSD-3-Clause licensing. Content review date: 2026-08-23.
Save to your cloud drive
Open the cloud drive to get the file directly, or save it for convenient access on another device.
Quark Cloud Drive
RecommendedSave mkcert to this cloud drive
Baidu Netdisk
Save mkcert to this cloud drive
mkcert 1.4.4 local CA and localhost HTTPS guide
Create a narrowly scoped local CA on a development device, issue a certificate for localhost, configure a test server and remove the trust anchor when the environment is no longer needed.
Before you start
- Use a development device under your control and list the exact localhost, loopback and test-domain names that need certificates.
- Keep the CA directory, certificate files and private keys outside source control, shared folders, container images and public backups.
- Record the server framework, certificate path, private-key path and runtime trust store before changing HTTPS settings.
Installation steps
- 01
Verify the executable
Place the Windows x64 executable in a controlled tools directory, check its version and keep the package separate from project output.
- 02
Install the local CA
Install the CA only after reviewing the trust change and record the CA directory. Use the required desktop permission when the operating system requests it.
- 03
Issue a scoped certificate
Generate a certificate for localhost, loopback or a clearly named test domain, and store the certificate and private key in a protected development directory.
Quick start
- 01
Configure the development server
Point the server or proxy to the generated certificate and private key, bind it to the intended local interface and restart the process.
- 02
Verify the hostname
Open the exact name covered by the certificate and inspect the browser trust result. A name mismatch calls for a new scoped certificate rather than a disabled warning.
- 03
Check other runtimes
Test Node.js, Java or command-line clients separately because each runtime may use a different root store from the browser.
Usage tips
- Treat the root CA private key as more sensitive than a normal site key; never share or commit it.
- Separate local CAs by device or team when trust boundaries differ, and remove unused issued certificates during cleanup.
- Certificate generation does not configure the server automatically; paths, names, ports and client trust need independent checks.
Troubleshooting and uninstall
Why does the browser still show a trust warning?
Restart the browser, check that the CA was installed into the store used by that browser and confirm that the accessed hostname is present in the certificate.
Why does a Node.js request fail while the browser works?
Configure the development process with the intended CA certificate and keep that setting scoped to the test process instead of disabling TLS verification globally.
- Remove the trust anchorConfirm that no test project still depends on the CA, remove it from the system or browser trust store and delete issued keys and certificates that do not need archival.
Frequently asked questions
Is a mkcert certificate suitable for a public production website?
It is intended for local development. Only devices that trust the local CA recognize the certificate, so a public site needs a certificate from a browser-trusted provider.
Why must rootCA-key.pem stay private?
It can issue certificates trusted by the device where the CA is installed. Keep it encrypted and local, and never place it in a repository, image or public share.
Does mkcert enable HTTPS in the server by itself?
No. It creates certificate material; the server, framework or proxy still needs the correct certificate path, private-key path, hostname and listener configuration.