# DLG_FLAGS_INVALID_CA: untrusted certificate in Edge IE mode

> DLG_FLAGS_INVALID_CA means Windows does not trust the certificate's issuer: self-signed, internal CA, missing intermediate or outdated root store.

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

**DLG_FLAGS_INVALID_CA means Windows does not trust the authority that issued the site's certificate.** Internet Explorer, legacy Edge and Edge's IE mode use this code for what Chrome calls [NET::ERR_CERT_AUTHORITY_INVALID](https://ssl.sh/errors/net-err-cert-authority-invalid/). The certificate is self-signed, from a private CA the PC does not know, missing its intermediate, or chained to a root the PC lacks.

## Where you still see it

Today the code appears mainly in Edge IE mode, in line-of-business apps and in dual-engine browsers. Internet Explorer 11 support ended on June 15, 2022 for most Windows versions, and legacy Edge support ended on March 9, 2021. The code survives because:

- **Edge IE mode** loads legacy sites with the IE11 Trident (MSHTML) engine, and Microsoft supports IE mode through at least 2029.
- **Line-of-business applications** embed the IE engine or use WinINet for HTTPS.
- **Dual-engine browsers** popular in some markets switch to the IE engine for banking, government and office systems.

WinINet's documented equivalent is `ERROR_INTERNET_INVALID_CA` (12045): "The function is unfamiliar with the Certificate Authority that generated the server's certificate." Its siblings are [DLG_FLAGS_SEC_CERT_CN_INVALID](https://ssl.sh/errors/dlg-flags-sec-cert-cn-invalid/) for a name mismatch and `DLG_FLAGS_SEC_CERT_DATE_INVALID` for date problems.

## Common causes, most frequent first

### 1. Internal site with a self-signed or private-CA certificate

Intranet portals, ERP systems and appliances in IE mode often use a certificate issued by an internal CA, or a self-signed one. PCs that are not domain-joined, or were set up before the root was distributed, do not trust it. Export the certificate from the warning page and check the issuer, or run:

```bash
openssl s_client -connect intranet.example.com:443 -servername intranet.example.com -showcerts </dev/null
```

If the last certificate's issuer is your company CA, the PC needs that root.

### 2. Missing intermediate certificate

The server sends only its own certificate. Windows can try to download a missing issuer from the certificate's AIA address (the same retrieval `certutil -urlfetch` performs), but not on networks that block outbound access, so internal PCs fail while home PCs work. Count the certificates in the output above; see [missing intermediate certificate](https://ssl.sh/errors/missing-intermediate-certificate/).

### 3. Outdated root certificate list on the PC

Windows downloads trusted roots on demand through the Microsoft automatic root update mechanism. Administrators can disable it with the `DisableRootAutoUpdate` policy, and isolated networks never reach the update server, so newer public roots are unknown and certificates chained to them fail. Microsoft documents how to host the root lists internally for disconnected environments.

### 4. TLS inspection by a proxy or antivirus

A device that decrypts HTTPS re-signs every certificate with its own root. If that root is missing from the PC, every intercepted site fails. Check the issuer name on the warning page; see [corporate SSL inspection](https://ssl.sh/errors/corporate-ssl-inspection/).

## What visitors can do

If you are not the administrator, note the site address and the issuer name shown in the certificate details and send both to your IT team. Try the same address in normal Edge or Chrome: if those also warn, the certificate itself is untrusted; if only IE mode warns, the server is probably missing its intermediate. Do not install a root certificate only because a website or email asks you to.

## How to diagnose on Windows

Save the server certificate (for example from the warning page's certificate dialog) and let Windows build the chain, downloading what it can:

```bash
certutil -verify -urlfetch server.cer
```

The output names the certificate where the chain stops. `CERT_E_UNTRUSTEDROOT` (0x800B0109), "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider", means the root is missing from the trusted store. `CERT_E_CHAINING` (0x800B010A), "A certificate chain could not be built to a trusted root authority", usually means an intermediate could not be found or downloaded.

## How to fix it

Install the missing intermediate on the server, or deploy the internal root to every PC that opens the site.

**Server administrators (IIS):** import the intermediate into the Local Computer > Intermediate Certification Authorities store, or install the full chain PFX, then re-select the certificate in the site binding. See [IIS SSL certificate](https://ssl.sh/guides/iis-ssl-certificate/). On other servers, configure the full chain file.

**Internal CA roots:** deploy them with Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Import. For a single PC, import into the Local Computer store with `certlm.msc`, not into Current User.

**Disconnected networks:** follow Microsoft's procedure to host the trusted root lists on an internal server, or import the needed public roots manually.

**Long term:** move the site out of IE mode and give it a publicly trusted certificate if it is reachable by a public name.

## How to verify the fix

1. `certutil -verify -urlfetch server.cer` finishes without chain errors.
2. Reopen the site in IE mode; no certificate warning appears.
3. Test the public side with the [SSL checker](https://ssl.sh/tools/ssl-checker/) and the chain order with the [chain builder](https://ssl.sh/tools/chain-builder/).