Home

ERR_CERT_COMMON_NAME_INVALID

%3CLINGO-SUB%20id%3D%22lingo-sub-739957%22%20slang%3D%22en-US%22%3EERR_CERT_COMMON_NAME_INVALID%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-739957%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F317619%22%20target%3D%22_blank%22%3E%40ericlaw%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAs%20of%20this%20post%2C%20I%20am%20running%20Microsoft%20Edge%20DEV%20Version%2077.0.197.1%20(Official%20build)%20dev%20(64-bit)%20on%20Windows%207%2C%20configured%20as%20my%20default%20browser.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20a%20server%20running%20running%20McAfee%20ePolicy%20Orchestrator%20that%20is%20currently%20configured%20to%20use%20a%20self-signed%20certificate%20that%20has%20a%20CA%20name%20like%26nbsp%3BOrion_CA_%3CHOSTNAME%3E%20and%20a%20website%20certificate%20issued%20by%20this%20CA%20to%20%3CHOSTNAME%3E.%3C%2FHOSTNAME%3E%3C%2FHOSTNAME%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENote%20%3CHOSTNAME%3E%20is%20not%20a%20FQDN%2C%20just%20a%20short%20host%20name.%3C%2FHOSTNAME%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20ePO%20website%20is%20accessed%20with%20a%20URL%20like%3A%20https%3A%2F%2F%3CHOSTNAME%3E%3A8443%2F%3C%2FHOSTNAME%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20my%20local%20machine%20certificate%20store%20configured%20with%20the%20McAfee%20CA%20so%20IE11%20trusts%20the%20CA%20and%20associated%20ePO%20certificate%20and%20connects%20to%20the%20website%20without%20any%20certificate%20errors%20or%20warnings.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20using%20Edge%20DEV%20I%20get%20the%26nbsp%3B%3CSTRONG%3EYour%20connection%20isn't%20private%3C%2FSTRONG%3E%20warning%20with%20the%20error%20shown%20as%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENET%3A%3AERR_CERT_COMMON_NAME_INVALID%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20aware%20of%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6125%23section-5.7.3.1%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6125%23section-5.7.3.1%3C%2FA%3E%26nbsp%3Band%20Google%20Chrome's%20deprecation%20of%20the%20use%20of%20a%20Common%20Name%20field%20in%20an%20SSL%20certificate.%20This%20self-signed%20ePO%20certificate%20does%20not%20have%20a%20SAN%20configured.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20found%20a%20Symantec%20reference%20for%20Google%20Chrome%20that%20discusses%20adding%26nbsp%3BEnableCommonNameFallbackForLocalAnchors%20to%26nbsp%3BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CPolicies%5CGoogle%5CChrome%20however%2C%20there%20is%20no%20corresponding%26nbsp%3BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CPolicies%5CMicrosoft%5CEdge%20key%20on%20my%20machine.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fsupport.symantec.com%2Fus%2Fen%2Farticle.TECH240507.html%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsupport.symantec.com%2Fus%2Fen%2Farticle.TECH240507.html%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20realize%20I%20can%20fix%20this%20by%20generating%20a%20more%20conformant%20certificate%20but%20should%20Chromium%20Edge%20also%20support%20this%20registry%20work-around%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECreating%20a%20key%26nbsp%3BHKEY_LOCAL_MACHINE%5CSOFTWARE%5CPolicies%5CMicrosoft%5C%3CSTRONG%3EEdge%3C%2FSTRONG%3E%26nbsp%3Band%20adding%20the%20DWORD%26nbsp%3B%3CSTRONG%3EEnableCommonNameFallbackForLocalAnchors%3C%2FSTRONG%3E%26nbsp%3Bwith%20a%20value%20set%20to%201%20did%20not%20change%20the%20behavior%20in%20my%20Edge%20DEV%20installation.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20can%20get%20to%20the%20ePO%20website%20with%20Edge%20DEV%20by%20clicking%20the%20Advanced%20button%20on%20the%20warning%20page%20which%20does%20indeed%20tell%20me%20the%20problem%20is%20a%20missing%20SAN%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20server%20couldn't%20prove%20that%20it's%20%3CHOSTNAME%3E%3B%20its%20security%20certificate%20does%20not%20specify%20Subject%20Alternative%20Names.%20This%20may%20be%20caused%20by%20a%20misconfiguration%20or%20an%20attacker%20intercepting%20your%20connection.%3C%2FHOSTNAME%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EClicking%20the%20link%3A%26nbsp%3B%3CEM%3EContinue%20to%20%3CHOSTNAME%3E%20(unsafe)%3C%2FHOSTNAME%3E%3C%2FEM%3E%20does%20allow%20me%20to%20get%20to%20the%20website%20but%20it%20shows%20the%20%3CSTRONG%3ENot%20Secure%3C%2FSTRONG%3E%20warning%20and%20the%20lined-through%20https%20protocol%20string%20in%20the%20URL.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E-Eric%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-740185%22%20slang%3D%22en-US%22%3ERe%3A%20ERR_CERT_COMMON_NAME_INVALID%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-740185%22%20slang%3D%22en-US%22%3EThe%20policy%20EnableCommonNameFallbackForLocalAnchors%20was%20removed%20in%20Chrome%2066%20and%20thus%20never%20supported%20in%20Microsoft%20Edge%20Insider.%20You'll%20need%20to%20update%20the%20certificate%20generator%20such%20that%20it%20generates%20certificates%20containing%20SubjectAltNames.%3CBR%20%2F%3E%3CBR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Fcs.chromium.org%2Fchromium%2Fsrc%2Fchrome%2Ftest%2Fdata%2Fpolicy%2Fpolicy_test_cases.json%3Fl%3D871%26amp%3Brcl%3D8fc422f8b81ebe66b35918c426c2b46cfba96e24%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fcs.chromium.org%2Fchromium%2Fsrc%2Fchrome%2Ftest%2Fdata%2Fpolicy%2Fpolicy_test_cases.json%3Fl%3D871%26amp%3Brcl%3D8fc422f8b81ebe66b35918c426c2b46cfba96e24%3C%2FA%3E%3C%2FLINGO-BODY%3E
enwinn
New Contributor

@ericlaw 

 

As of this post, I am running Microsoft Edge DEV Version 77.0.197.1 (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:

 

NET::ERR_CERT_COMMON_NAME_INVALID

 

I am aware of https://tools.ietf.org/html/rfc6125#section-5.7.3.1 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.

 

https://support.symantec.com/us/en/article.TECH240507.html 

 

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.

 

-Eric

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

https://cs.chromium.org/chromium/src/chrome/test/data/policy/policy_test_cases.json?l=871&rcl=8fc422...