Issue metadata
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.
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rsleevi@chromium.org
, May 9 2017Status: Duplicate (was: Unconfirmed)