New issue
Advanced search Search tips

Issue 700354 link

Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue 700595
Owner: ----
Closed: Mar 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Canary intranet HTTPS site issue

Reported by davide.b...@gmail.com, Mar 10 2017

Issue description

Chrome Version       : 59.0.3037.0
OS Version: OS X 10.12.3
URLs (if applicable) : intranet site
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
     IE 7/8/9: --

What steps will reproduce the problem?
1. connect to an intranet HTTPS site "secure-ext.mmfg.it" with a certificate with CN "secure-ext.mmfg.it" from an onpremises custom CA trusted in the keychain

What is the expected result?
On stable channel no issues

What happens instead of that?
Return the following error:

Attackers might be trying to steal your information from secure-ext.mmfg.it (for example, passwords, messages or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
Subject: secure-ext.mmfg.it
Issuer: MMFG WEB CA
Expires on: 01 Feb 2027
Current date: 10 Mar 2017

Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3037.0 Safari/537.36

 
Screen Shot 2017-03-08 at 14.53.38.png
116 KB View Download

Comment 1 by mmenke@chromium.org, Mar 10 2017

Components: Internals>Network>Certificate
Could you provide a about:net-internals log of this happening?  Instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
https://www.chromestatus.com/features/4981025180483584

Please update your on-premises CA to conform with RFC 2818, published 17 years ago. If you need time, you can use the enterprise policy "EnableCommonNameFallbackForLocalAnchors" 
Thanks, you are right!
Status: WontFix (was: Unconfirmed)

Comment 5 by eroman@chromium.org, Mar 11 2017

Labels: -OS-Mac
Mergedinto: 700595
Status: Duplicate (was: WontFix)

Comment 6 by goo...@rkeene.org, Mar 13 2017

From RFC 2818:

  If a subjectAltName extension of type dNSName is present, that MUST
  be used as the identity. Otherwise, the (most specific) Common Name
  field in the Subject field of the certificate MUST be used. Although
  the use of the Common Name is existing practice, it is deprecated and
  Certification Authorities are encouraged to use the dNSName instead.

Special note to where MUST is used with respect to the Common Name field being used to match the identity.

Deprecated carries no weight in this check per the RFC as the behavior is still defined as MUST be supported.
If you are running into this problem and using windows, there is a possibility that the way you are creating the cert is the problem.  Using IIS to create a cert does not have the text field: Subject Alt Name.  Here is the article I found that solves the problem: https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

Sign in to add a comment