Browser errors
DLG_FLAGS_SEC_CERT_CN_INVALID: certificate name error in IE
DLG_FLAGS_SEC_CERT_CN_INVALIDDLG_FLAGS_SEC_CERT_CN_INVALID means the certificate was issued for a different hostname than the one you opened. It is the Internet Explorer and legacy Edge wording of the same problem Chrome calls NET::ERR_CERT_COMMON_NAME_INVALID. You see it today mainly in Edge's IE mode, in older Windows applications, and in the compatibility mode of some dual-engine browsers.
Is it the site or your device?
It is almost always the site: the certificate does not list the name you opened. Check the hostname coverage with the SSL checker:
curl ssl.sh/example.com
If the hostname is missing from the certificate, the site must fix it. If the certificate covers it, check what you typed: IE-mode applications often open internal short names (http://intranet) or IP addresses that no certificate lists. Proxies and captive portals answering for other sites can also cause it.
Causes
1. Hostname not in the SAN list
The certificate covers www.example.com but the page or app opens example.com, or an internal alias. Inspect the names:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -ext subjectAltName
2. Short names and IP addresses in legacy apps
Line-of-business apps configured years ago often call https://appserver or https://203.0.113.10. Either add those names (internal CA only; public CAs do not issue for internal names) or reconfigure the app to use the full hostname.
3. Wrong certificate bound in IIS
The HTTPS binding for the site uses another certificate, or SNI is not enabled and the server presents the default binding's certificate. Check IIS Manager > Site > Bindings.
4. Interception or captive portal
A device answering on behalf of the real site presents its own certificate. Switch networks to compare.
What it looks like in each browser
| Browser | What you see |
|---|---|
| Internet Explorer / Edge IE mode | "There is a problem with this website's security certificate" and that it "was issued for a different website's address"; the code itself appears in logs and in some app dialogs |
| Legacy Edge (EdgeHTML) | "This site is not secure" with the same code |
| Chrome / current Edge | NET::ERR_CERT_COMMON_NAME_INVALID |
| Firefox | SSL_ERROR_BAD_CERT_DOMAIN |
How site owners fix it
A certificate that lists every hostname users type, bound correctly in IIS, fixes it.
1. Include every hostname users and apps use:
sudo certbot certonly --nginx -d example.com -d www.example.com
2. On IIS, bind the correct certificate to each host name and tick "Require Server Name Indication" when several HTTPS sites share an IP:
New-WebBinding -Name "Example" -Protocol https -Port 443 -HostHeader "example.com" -SslFlags 1
Then assign the certificate to that binding in IIS Manager.
3. Retire IE-mode dependencies where possible; WinINet-based clients are stricter about old configurations and harder to diagnose. Check the rest of the TLS setup with Schannel errors and re-test with curl ssl.sh/example.com.
FAQ
Internet Explorer is retired. Why do I still see this code?
Microsoft Edge's IE mode, business applications that embed the Internet Explorer engine, and compatibility modes in some dual-engine browsers still use Windows' WinINet stack, which reports certificate problems with DLG_FLAGS codes.
What do DLG_FLAGS_INVALID_CA and DLG_FLAGS_SEC_CERT_DATE_INVALID mean?
DLG_FLAGS_INVALID_CA means Windows does not trust the issuer (self-signed, private CA, missing intermediate). DLG_FLAGS_SEC_CERT_DATE_INVALID means the certificate expired or the PC clock is wrong. They map to Chrome's NET::ERR_CERT_AUTHORITY_INVALID and NET::ERR_CERT_DATE_INVALID.
Should I click "Continue to this website (not recommended)"?
Only for an internal system you know and control, accessed by a name you are sure of. For anything else, a certificate for a different hostname means you may not be talking to the server you intended.
Does Edge IE mode use a different certificate store from Chrome?
IE mode relies on the Windows certificate store and the Schannel TLS stack, while current Chrome and Edge each use a built-in certificate verifier of their own. A site can therefore pass in normal Edge and fail in IE mode, or the reverse, especially with private CAs or old TLS settings. Test both modes after any certificate change.