New issue
Advanced search Search tips

Issue 720010 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Change to SAN Breaking Several Internal Websites

Reported by jdshe...@gmail.com, May 9 2017

Issue description

<b>Chrome Version       : <Copy from: 'about:version'></b>
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari: 
    Firefox: OK v53
         IE: OK v11.015063.0

What steps will reproduce the problem?
(1) Navigating to https site with no SAN field filled out but proper certificate issued
(2)
(3)

What is the expected result?
Should present site without errors

What happens instead?
SAN missing error

Please provide any additional information below. Attach a screenshot if
possible.
Google references RFC-2818 as a reason to remove this probably because of the line "Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."

You can't use one line of an RFC that says "encouraged" and ignore the line right before it says "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."

I would assume in an RFC a MUST is a stronger mandate than encourage since encourage isn't even using the keyword SHOULD.
 
Mergedinto: 700595
Status: Duplicate (was: Unconfirmed)

Sign in to add a comment