Issue metadata
Sign in to add a comment
|
TLS negotiations fail on host only certificates with no SAN extensions defined.
Reported by
iab...@wayfair.com,
Apr 11 2017
|
||||||||||||||||||||||
Issue descriptionChrome Version : 58.0.3029.54 OS Version: WIN 10 URLs (if applicable) : All tested against internal sources Other browsers tested: IE 11 What steps will reproduce the problem? 1. Find a site with a host only certificate, and no SAN defined. 2. The certificate is otherwise trusted. 3. You'll recieve an error (net::ERR_CERT_COMMON_NAME_INVALID), and "Subject Alternative Name Missing" What is the expected result? The expected result is a request that is not denied for broken HTTPS What happens instead of that? The request is denied, for the reasons stated above. Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.54 Safari/537.36
,
Apr 11 2017
With regards to the linked article, I'm curious if there exists the train of thought for holding off at least for a little while for privately trusted certificates. "Ideally, we would do this for all certificates (publicly trusted and privately trusted), but if there are concerns about compat risk, we can restrict it to publicly trusted certificates." I know that we're kind of blindsided by this change, but i can't imagine we're the only ones on this boat.
,
Apr 11 2017
Merging into Issue 70059 which has the details of the enterprise policy to enable this.
,
Apr 11 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mkwst@chromium.org
, Apr 11 2017Owner: rsleevi@chromium.org
Status: Assigned (was: Unconfirmed)