The site opens in normal Edge but shows DLG_FLAGS_INVALID_CA in IE mode. Why?

Current Edge uses its own certificate verifier and built-in root store, plus roots installed locally, while IE mode relies on Windows' own chain building through the IE11 engine. A server that omits its intermediate certificate, or a root that only one path knows about, can therefore pass in one mode and fail in the other. Serve the full chain and install private roots in the Windows store.

Is it safe to click "Continue to this website (not recommended)"?

Only for an internal system you control, reached by the exact name you expect, and only after confirming the certificate's fingerprint with the administrator. Otherwise an untrusted issuer means you cannot tell whether you are talking to the real server.

I installed our company root certificate but the error persists. What did I miss?

Check where it went. It must be in Trusted Root Certification Authorities of the Local Computer store for all users and services; importing into Current User or into the Personal store does not make it a trust anchor for every application. Also make sure the server sends the intermediate certificate.

Do I see this code in 360 or QQ Browser?

Dual-engine browsers show IE-engine error pages when a site opens in their compatibility (IE) mode, because that mode uses the same Windows components. In their Chromium-based mode you see Chrome-style codes such as NET::ERR_CERT_AUTHORITY_INVALID instead.

DLG_FLAGS_INVALID_CA: untrusted certificate in Edge IE mode

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

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.

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.

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:

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

certutil -verify -urlfetch server.cer finishes without chain errors.
Reopen the site in IE mode; no certificate warning appears.
Test the public side with the SSL checker and the chain order with the chain builder.