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 with both serverAuth and clientAuth EKUs (since June 15, 2026) - Edge inherits Chrome Root Program Policy v1.8 through its Chromium base. Public TLS certificates that include both Extended Key Usages are rejected. The rollout timing in Edge can lag Chrome by one to two stable-channel releases, so the error may surface on Edge slightly after it appears in Chrome and Brave.
For the dual-EKU case, check your certificate with:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -ext extendedKeyUsage
If both TLS Web Server Authentication and TLS Web Client Authentication appear, ask your CA to reissue with serverAuth only. The deep dive on the two causes of NET::ERR_CERT_AUTHORITY_INVALID after June 15, 2026 covers the diagnostic commands and exact reissuance wording for your CA.
For the other 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) that expiry-only monitoring misses. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.