To stop Chrome 132 from displaying security warnings for self-signed certificates on localhost, you must configure the browser to trust your local development environment. This is achieved by creating a valid certificate authority (CA) and importing its root certificate into your operating system’s trusted store. Once the OS trusts the CA, Chrome will automatically accept certificates signed by it without blocking access or showing red warning screens.
Why Chrome Blocks Localhost Certificates
Modern browsers prioritize user security by enforcing strict TLS/SSL validation rules. When you run a local server using a self-signed certificate, Chrome cannot verify the identity of the site because the certificate was not issued by a publicly trusted Certificate Authority (CA). In previous versions, developers sometimes bypassed this by clicking "Advanced" and then "Proceed," but Chrome 132 has tightened these restrictions to prevent phishing and man-in-the-middle attacks. The browser now treats untrusted local certificates as high-risk connections, making the standard workaround ineffective or increasingly difficult to apply consistently across sessions.
The Secure Solution: Using mkcert
The most reliable way to resolve this issue is to generate a certificate that your operating system already trusts. We recommend using
mkcert, a simple tool that creates locally trusted development certificates. Unlike manually generated self-signed certs,
mkcert installs a local root CA on your machine. Any certificate signed by this local CA is automatically trusted by Chrome, Firefox, and other browsers without manual intervention. This approach ensures that your development environment mimics production security standards while eliminating nagging warnings.
First, install
mkcert on your system. You can download the binary from the official GitHub releases page or use a package manager like Homebrew on macOS or Chocolatey on Windows. After installation, initialize the local CA by running the command
mkcert -install. This command adds the local CA to your system’s trust store. On Windows, this may require administrative privileges, so ensure you run your terminal as an administrator. On macOS and Linux, the process is typically seamless.
Once the CA is installed, generate a certificate for localhost. Run the following command in your project directory:
mkcert localhost 127.0.0.1 ::1
This generates two files:
localhost.pem (the certificate) and
localhost-key.pem (the private key). These files are now trusted by your OS. Configure your local web server (such as Node.js, Python, or Apache) to use these files instead of your existing self-signed certificates. Restart your server and refresh Chrome. The lock icon should appear next to your URL, indicating a secure connection.
Configuring Your Development Server
After generating the certificates, you need to point your development tools to them. For example, if you are using Node.js with Express, update your HTTPS configuration object to include the paths to the
.pem and
-key.pem files. If you are using Vite, add the
server.https option in your
vite.config.js file. Ensure that the file paths are correct relative to your project root. Incorrect paths will cause the server to fail to start, leading to confusion about whether the certificate issue is resolved.
It is important to note that this method does not expose your local CA to the internet. The trust relationship is strictly local to your machine. This means that other devices on your network will still see security warnings if they try to access your local server unless you also export and import the CA certificate to those devices. For mobile testing, you can export the CA certificate using
mkcert -CAROOT and install it on your phone.
Troubleshooting Common Issues
If Chrome still shows warnings after implementing this solution, clear your browser’s SSL state. Go to Chrome settings, search for "Manage Certificates," and navigate to the "Trusted Root Certification Authorities" tab. Verify that the local CA created by
mkcert is listed there. If it is missing, re-run
mkcert -install with elevated privileges. Sometimes, cached DNS records or stale SSL sessions can cause persistent errors. Clearing your browsing data, specifically cookies and cached images/files, often resolves these residual issues.
For advanced users, ensure that your certificate includes both IPv4 (
127.0.0.1) and IPv6 (
::1) addresses in the Subject Alternative Name (SAN) field. Older browsers might reject certificates that only list
localhost without explicit IP addresses.
mkcert handles this automatically when you pass both parameters to the generation command.
Security Considerations
While this method improves developer experience, it introduces a slight security trade-off. By trusting a local CA, you allow any application on your machine to generate valid certificates for any domain. This is acceptable for development but should never be used in production environments. Never share your local CA certificate or keys with others. Additionally, keep your
mkcert version updated to avoid potential vulnerabilities in older certificate generation logic.
Slow Initial Connection (SSL Handshake) in Chrome Browser details how to optimize SSL performance once your certificates are correctly configured, ensuring that your local development workflow remains fast and efficient.
Frequently Asked Questions
Does this method work for other browsers?
Yes,
mkcert works with Firefox, Safari, and Edge because it installs the certificate into your operating system’s global trust store. Each browser relies on the OS to determine which CAs are trusted, so configuring the OS once is sufficient for all major browsers.
Can I use this for subdomains like app.localhost?
Absolutely. When generating the certificate, simply include the desired subdomain in the command, such as
mkcert app.localhost www.app.localhost. The resulting certificate will cover all specified names, allowing you to test multiple local services seamlessly.
Will my team members have the same warnings?
No, each developer must run
mkcert -install on their own machine. The local CA is unique to each computer’s trust store. Sharing the CA certificate allows teammates to trust your certificates, but they still need to install it locally to remove warnings.
Is it safe to keep the local CA installed permanently?
It is generally safe for development machines. However, if your computer is shared or used for sensitive transactions, consider removing the CA when not developing. You can uninstall it by running
mkcert -uninstall, though this will revert all local certificates to untrusted status.
What if I am using Docker containers?
You need to copy the CA certificate into your Docker container and trust it there as well. Mount the
mkcert CAROOT directory into your container and add the certificate to the container’s trust store. This ensures that internal services within the container also recognize the localhost certificate as valid.