New Contributor



As of this post, I am running Microsoft Edge DEV Version (Official build) dev (64-bit) on Windows 7, configured as my default browser.


I have a server running running McAfee ePolicy Orchestrator that is currently configured to use a self-signed certificate that has a CA name like Orion_CA_<hostname> and a website certificate issued by this CA to <hostname>.


Note <hostname> is not a FQDN, just a short host name.


The ePO website is accessed with a URL like: https://<hostname>:8443/


I have my local machine certificate store configured with the McAfee CA so IE11 trusts the CA and associated ePO certificate and connects to the website without any certificate errors or warnings.


However, using Edge DEV I get the Your connection isn't private warning with the error shown as:




I am aware of and Google Chrome's deprecation of the use of a Common Name field in an SSL certificate. This self-signed ePO certificate does not have a SAN configured.


I found a Symantec reference for Google Chrome that discusses adding EnableCommonNameFallbackForLocalAnchors to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome however, there is no corresponding HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge key on my machine. 


I realize I can fix this by generating a more conformant certificate but should Chromium Edge also support this registry work-around?


Creating a key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge and adding the DWORD EnableCommonNameFallbackForLocalAnchors with a value set to 1 did not change the behavior in my Edge DEV installation.


I can get to the ePO website with Edge DEV by clicking the Advanced button on the warning page which does indeed tell me the problem is a missing SAN:


This server couldn't prove that it's <hostname>; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.


Clicking the link: Continue to <hostname> (unsafe) does allow me to get to the website but it shows the Not Secure warning and the lined-through https protocol string in the URL.



11 Replies
The policy EnableCommonNameFallbackForLocalAnchors was removed in Chrome 66 and thus never supported in Microsoft Edge Insider. You'll need to update the certificate generator such that it generates certificates containing SubjectAltNames.

@ericlaw The Edge DEV browser version 82.0.439.1 (Official build) dev (64-bit) is now frequently throwing this error on standard public sites like:,, and


It's seems more likely that the browser is not handling these sites correctly rather than all of these sites are suddenly having issues with their SSL certs.


<Todd />

Howdy, Todd. The most likely explanation here is that you're behind a buggy network appliance, perhaps a ZScaler. Please see for more information, including a workaround.

@ericlaw I'm actually at home accessing the Internet via a Century Link C2100Z appliance. While Century Link may have a ZScaler somewhere up the line, I won't have any access to it.


That said, if I switch to my other laptop (which is still using the native Windows 10 Edge browser) and browse these sites from the same network, I have no issues. So again, it seems that something is fishy with the browser (or at least the Windows 10 laptop that the Edge Dev browser is running on).


<Todd />

I should mention, I did try the workaround. But running the following command does not fix the issue:
msedge.exe --disable-features=PostQuantumCECPQ2

<Todd />
Hi, Todd-- The other explanation is that you're behind some sort of misconfigured device or there's malware causing the issue.

Sharing the full certificate info of an incorrect certificate (see ) or a Network Log ( would allow me to tell you what specifically is happening.

@ericlaw Hi! The same problem is happening to me, and only in a specific situation: when accessing Twitter from an email I got on my Gmail saying I have a new Direct Message. If I click on the link from there, this happens. If I access Twitter from any other means, it works fine.


The certificate information and the network log are in attachment, in the same ZIP file.



@RobertoSAG The immediate problem is that the certificate (thumbprint d4b95942dea3f885dc782634cbcc0c8cabe82b4c) being presented for "" does not contain "", only "". The live certificate I see for Twitter when navigating to it from Texas, USA includes both. When navigating to Twitter from Brazil, I get the certificate lacking the "www." I reached out to Twitter Engineering.


It appears that either Twitter mis-issued this certificate (it should have included the "www." prefix), or misconfigured their servers such that a server which was supposed to use a "www." certificate instead chose the certificate that omitted the "www." entry.



@ericlaw Thank you! I'm not a web developer, but is there anything I can do to report this?

The Twitter team reports that they're working on it; see the "reached out to" link above. (I'm presuming that you're located somewhere near Brazil; if not, it might be helpful for you to share a bit more info so I can make sure that they fix this everywhere that is impacted).

@ericlaw Yeah, I'm in Brazil, and that makes sense. Thank you for the assistance!