Browser errors

DLG_FLAGS_SEC_CERT_CN_INVALID: certificate name error in IE

By · Last verified

Error messageDLG_FLAGS_SEC_CERT_CN_INVALID

DLG_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.

Sources

  1. RFC 9525: Service Identity in TLS
  2. Microsoft Learn: TLS/SSL (Schannel SSP) overview
  3. RFC 5280 section 4.2.1.6: Subject Alternative Name