HTTPS certificate not trusted during development
Complete Fix Guide
“NET::ERR_CERT_AUTHORITY_INVALID” — You're trying to test your app locally over HTTPS, but the browser blocks it. This guide provides permanent, secure solutions for trusting development certificates in ASP.NET Core, Angular, Node.js, and all major browsers.
📑 Table of Contents
1. Introduction
You spin up your development server over HTTPS, open your browser, and instead of your app, you see a warning: "Your connection is not private" or "NET::ERR_CERT_AUTHORITY_INVALID". The browser doesn't trust the certificate because it's self-signed — not issued by a trusted Certificate Authority (CA).
This is a common hurdle when developing modern web applications that require HTTPS (e.g., for service workers, secure cookies, or CORS with credentials). The good news is that there are simple, permanent fixes that work for all major development tools.
2. Why This Happens
When you use HTTPS in development, the server generates a self‑signed certificate. These certificates are cryptographically valid, but they aren’t signed by a trusted CA that browsers recognize. Browsers display a warning because they can’t verify the certificate’s origin, protecting users from potential man‑in‑the‑middle attacks.
This issue affects:
- ASP.NET Core (Kestrel) – default HTTPS dev certificate
- Angular dev server – uses a self‑signed certificate by default
- Vite / Webpack dev servers with SSL enabled
- Node.js HTTPS servers (e.g., Express with `https` module)
- Any local development server running over HTTPS
3. Fix for ASP.NET Core
ASP.NET Core provides a built‑in development certificate. You can trust it with a single command.
📌 Generate and Trust the ASP.NET Core Certificate
This command creates a new self‑signed certificate and adds it to your system’s trusted root store. After running it, restart your browser and API; the warning should disappear.
dotnet dev-certs https --clean then dotnet dev-certs https --trust.
📌 Verify the Certificate
This command checks if the certificate is present and trusted.
4. Fix for Angular
Angular’s development server (Angular CLI) can use HTTPS with a certificate. By default it generates a self‑signed certificate. Here’s how to use a trusted certificate.
📌 Option 1: Use a Trusted Certificate (mkcert)
Generate a certificate with mkcert (see next section) and configure Angular to use it.
📌 Option 2: Use Angular Dev Server with Proxy (Ignore SSL)
If you're only using Angular for the frontend and proxying to a backend that already has a trusted certificate, you can configure the proxy to ignore SSL errors.
5. Universal Fix with mkcert
mkcert is the gold‑standard tool for creating locally trusted certificates. It installs a local Certificate Authority (CA) on your machine and generates certificates for any domain (localhost, 127.0.0.1, custom domains, etc.) that are automatically trusted by your browser.
📌 Step 1: Install mkcert
📌 Step 2: Install the Local CA
This installs the local CA certificate into your system’s trust store.
📌 Step 3: Generate Certificates for Your Hostnames
This generates two files: myapp.test-key.pem and myapp.test.pem (or similar).
📌 Step 4: Use the Certificate in Your Server
Point your development server to the generated certificate and key files. For ASP.NET Core, you can
configure Kestrel to use them; for Angular, use the angular.json approach mentioned earlier.
For Node.js, use the https module with the cert and key options.
6. Browser-Specific Workarounds
If you can't install a certificate system‑wide, you can bypass the warning per browser. These are temporary solutions and not recommended for daily development.
📌 Chrome / Edge
- Type
thisisunsafe(anywhere) on the warning page – this bypasses the warning. - Alternatively, click "Advanced" → "Proceed to localhost (unsafe)".
- You can also run Chrome with the flag:
--ignore-certificate-errors(not secure).
📌 Firefox
- Click "Advanced" → "Accept the Risk and Continue".
- You can add a permanent exception via "Add Exception…" and confirm.
📌 Safari
- Click "Show Details" → "visit this website" (or similar).
- There's no permanent exception; you'll have to do it each time.
7. Proxy Ignore SSL Errors
In many full‑stack setups (Angular + ASP.NET Core), you use a proxy to forward API requests. If your backend uses HTTPS with an untrusted certificate, you can tell the proxy to ignore SSL errors.
For Vite, you can set secure: false in the proxy options as well. For Node.js servers
with http-proxy, you can set rejectUnauthorized: false.
8. Debugging Tips
- Check the certificate details: Click the padlock in the browser’s address bar to see the certificate issuer. It should show the local CA (if using mkcert) or your custom CA.
- Clear browser cache: Sometimes browsers cache certificate errors. Use incognito mode or clear the cache.
- Verify the certificate file: Use OpenSSL to inspect:
openssl x509 -in cert.pem -text -noout. - Check the system trust store: On Windows, run
certmgr.mscand look for your certificate in "Trusted Root Certification Authorities". - Check server logs: The server may have errors if the certificate file is missing or invalid.
10. Best Practices
- Use mkcert for all local development HTTPS needs – it's the most reliable and secure method.
- Always trust the certificate system‑wide rather than relying on browser bypasses.
- Keep your certificates in a project‑specific folder (e.g.,
.cert/) and add to.gitignore. - Document the certificate setup in your project’s README for other developers.
- Use environment variables to toggle HTTPS and certificate paths in different environments.
- Automate certificate generation with a script (e.g., using mkcert in a post‑install hook).
- For production, always use certificates from a trusted CA (e.g., Let's Encrypt, DigiCert).
0 Comments
thanks for your comments!