Fix Browser Security Warnings in Microsoft Edge
Microsoft Edge is built on Chromium, so its 'Your connection isn't private' warnings share Chrome's NET::ERR_CERT_* codes and validation logic - but Edge uses the Windows certificate trust store, which adds Microsoft-specific wrinkles. Root updates ship with Windows Updates, so a machine behind on patches can have a stale trust store, and Group Policy can modify trust on managed devices. Edge follows the Chrome Root Store, occasionally lagging Chrome by a release or two.
Microsoft Edge shows "Your connection isn't private" (or older "This site is not secure") when it can't establish a trusted HTTPS connection. Edge is built on Chromium, so the underlying validation logic and most error codes are identical to Chrome's - but Edge uses the Windows certificate trust store, which has some Microsoft-specific implications worth knowing.
What Edge is checking
Edge verifies the SSL certificate the server presents using the same three checks as other browsers:
- Validity dates - the certificate's
notBeforeandnotAfterbracket the current time. - Hostname match - the requested domain appears on the certificate's Subject Alternative Names.
- Trust chain - the certificate chains up to a CA in the Windows certificate trust store.
The Windows trust store is shared between Edge, Internet Explorer (legacy), Outlook, Office, Windows services, and any other Windows application that uses the platform's TLS APIs. Group Policy can modify this store on managed corporate devices.
The error codes you'll see
Edge (Chromium-based) shares Chrome's error code vocabulary:
NET::ERR_CERT_DATE_INVALID- expired or not-yet-valid.NET::ERR_CERT_COMMON_NAME_INVALID- hostname doesn't match.NET::ERR_CERT_AUTHORITY_INVALID- issuer not trusted.NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH- TLS version or cipher rejected.NET::ERR_CERT_REVOKED- certificate has been revoked.
On legacy (pre-Chromium) Edge or Internet Explorer, you may see different wording like "There is a problem with this website's security certificate" instead.
If you're a visitor seeing this warning
Default action: leave the site. The warning is real - entering passwords or payment information isn't safe.
Reasonable exceptions:
- The site is yours - use the fixes below.
- You're on a managed Windows device and the site is internal. Your IT team may have distributed an internal CA via Group Policy that's missing on your machine.
- Your system clock is wrong - Windows trusts the system clock for certificate validity. A wrong clock makes valid certificates look expired.
If you own the site and need to fix it
For NET::ERR_CERT_DATE_INVALID (expired)
Issue a new certificate. The fastest path is a free Let's Encrypt certificate via Beacon:
Need a working certificate right now?
Beacon issues free 90-day Let's Encrypt certificates with a guided DNS-validation flow. No account, no command-line tools, no ACME client to install - just a domain you control. Most people get a working certificate in under 10 minutes.
Get a free certificate from BeaconFor NET::ERR_CERT_COMMON_NAME_INVALID (hostname mismatch)
Your certificate doesn't include the affected hostname on its SAN list. Either issue a new certificate that covers it, or check your server's SNI configuration to ensure the right certificate maps to the right hostname.
For NET::ERR_CERT_AUTHORITY_INVALID (untrusted issuer)
Edge uses the Windows trust store, which includes a broad set of CAs but is occasionally narrower than other browsers' stores. Common causes:
- Self-signed certificate - not trusted by any public store.
- Internal CA not distributed via Group Policy - your enterprise CA may be missing on this specific Windows machine.
- CA removed from Windows trust store - Microsoft occasionally removes distrusted CAs in Windows updates. Rare but possible.
- Certificate chains to a legacy root Chrome/Edge no longer trusts - the most common live cause in 2026. Edge follows the Chrome Root Store on its Chromium base, with rollout occasionally lagging Chrome by a stable-channel release or two.
Check which root your certificate chains to:
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null \
| grep -E "(s:|i:)"If the issuer is a legacy root your CA has migrated away from, ask for reissuance from their current hierarchy. The deep dive on the real causes of NET::ERR_CERT_AUTHORITY_INVALID in 2026 covers the specific distrusted roots and current replacements per CA.
A separate risk worth knowing about: Chrome will eventually reject certificates mixing serverAuth and clientAuth EKUs, but not until March 15, 2027. The nearer-term risk is a CA revoking a certificate on short notice over its own internal compliance deadline, independent of Chrome's actual timeline - it happened to tens of thousands of certificates in July 2026. Read about the incident.
For self-signed or internal-CA cases, switch to a publicly-trusted CA (Let's Encrypt, DigiCert, Sectigo, etc.).
For NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Your server is too restrictive on TLS version or cipher suites. Modern Edge requires TLS 1.2 minimum (TLS 1.3 preferred) and rejects deprecated ciphers. Mozilla's SSL Configuration Generator produces ready-to-paste configurations.
Windows trust store specifics
Two Windows-specific things worth knowing:
- Root certificate updates ship with Windows Updates. If a machine is far behind on Windows Updates, its trust store may be missing recent CA changes. Updating Windows refreshes the trust store.
- Group Policy can override the trust store on managed devices. Enterprise IT can add private CAs or remove public ones. If a site works on personal devices but fails on work devices (or vice versa), the trust store difference is usually the cause.
Prevent this from happening again
Stop this from happening again
TLS Radar continuously monitors every certificate across your domains and alerts you weeks before anything expires, and also catches the silent failure modes - chain breaks, weak ciphers, hostname mismatches, risky EKUs, and distrust events - that keep a site from opening in every browser. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Frequently asked questions
- Why does Microsoft Edge show 'Your connection isn't private'?
- Because Edge is built on Chromium and could not trust the site's certificate. It checks the certificate's dates, hostname coverage, and whether it chains to a CA in the Windows trust store. The NET::ERR_CERT_* code identifies which check failed, and the fixes are largely the same as Chrome's.
- How is Edge's certificate trust different from Chrome's?
- Edge uses the Windows certificate trust store rather than Chrome's own store, and follows the Chrome Root Store with rollout sometimes lagging by a release or two. Root updates arrive through Windows Updates, and Group Policy can add or remove CAs on managed corporate devices - so a site can behave differently on a work machine than a personal one.
- A site works on other computers but not this Windows machine - why?
- Often the machine is behind on Windows Updates, so its trust store is missing recent CA changes; updating Windows refreshes it. On managed devices, Group Policy may have removed a public CA or the machine may be missing an internal CA that IT distributed. The trust-store difference is usually the cause.
- How do I fix NET::ERR_CERT_AUTHORITY_INVALID in Edge?
- Run 'openssl s_client -showcerts -connect example.com:443' and check which root the chain terminates at. If it is a legacy root your CA has migrated away from, request reissuance from their current hierarchy. For self-signed or internal certificates, switch to a publicly-trusted CA, or have IT distribute the internal CA via Group Policy.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.