# DLG_FLAGS_SEC_CERT_CN_INVALID: certificate name error in IE

> DLG_FLAGS_SEC_CERT_CN_INVALID is the IE and legacy Edge code for a certificate issued to a different hostname. Where it still appears and how to fix it.

Source: https://ssl.sh/errors/dlg-flags-sec-cert-cn-invalid/
Last updated: 2026-11-10

**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](https://ssl.sh/tools/ssl-checker/):

```bash
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:

```bash
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](https://ssl.sh/errors/net-err-cert-common-name-invalid/) |
| Firefox | [SSL_ERROR_BAD_CERT_DOMAIN](https://ssl.sh/errors/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:

```bash
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:

```powershell
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](https://ssl.sh/errors/windows-schannel-errors/) and re-test with `curl ssl.sh/example.com`.