Jul 05 2019 08:38 AM
Jul 05 2019 08:38 AM
As of this post, I am running Microsoft Edge DEV Version 188.8.131.52 (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 https://tools.ietf.org/html/rfc6125#section-184.108.40.206 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.
Jul 05 2019 10:37 AM
Mar 06 2020 03:29 PM
@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: youtube.com, facebook.com, and wellsfargo.com.
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.
Mar 06 2020 03:31 PM
Mar 06 2020 04:02 PM
@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).
Mar 06 2020 04:04 PM
Mar 09 2020 01:23 PM
Mar 09 2020 08:57 PM
@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.
Mar 10 2020 09:18 AM - edited Mar 10 2020 09:45 AM
@RobertoSAG The immediate problem is that the certificate (thumbprint d4b95942dea3f885dc782634cbcc0c8cabe82b4c) being presented for "www.twitter.com" does not contain "www.twitter.com", only "twitter.com". 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.
Mar 10 2020 01:49 PM - edited Mar 10 2020 01:50 PM
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).