Issue metadata
Sign in to add a comment
|
Cert error inconsistent between Windows and OS X
Reported by
dcili...@gmail.com,
Mar 9 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36 Steps to reproduce the problem: 1. Use the attached cert/key pair with a HTTPS server. (tested against openssl s_server and an embedded TLS stack) This is a self-signed pair. 2. Attempt to connect to server. 3. Observe the reported error in the advanced expansion or in net-internals. What is the expected behavior? 1. Connecting from Chrome 57.0.2987.98 on Windows 7, SSL_CONNECT reports '--> net_error = -207 (ERR_CERT_INVALID)'. 2. Connecting from Crome 57.0.2987.98 (64-bit) on OS X 10.10.5, SSL_CONNECT reports '--> net_error = -202 (ERR_CERT_AUTHORITY_INVALID)' What went wrong? Windows version of chrome reports a hard certificate error. OS X reports a bypassable error. I have no idea *why* this is the case. It's entirely possible that the issue is in the cert itself, but there is no clear indication what's going wrong. Did this work before? Yes ??? Chrome version: 57.0.2987.98 Channel: stable OS Version: OS X 10.10.5 Flash Version: Welcome to the embedded development...
,
Mar 9 2017
,
Mar 9 2017
Further information: We've identified that this issue is *only* occurring with a Common Name of '10.1.1.161' and an email of 'sales@netburner.com'.
,
Mar 9 2017
This is a partial list of working and failing keys from our tests.
,
Mar 9 2017
Further Details: issue appears to be affecting IE 11.0.9600.18499. It appears to not affect FF 47.0.2 or 52.0
,
Mar 9 2017
Not sure I understand your expectation. This is a self-signed certificate (doesn't chain to a trust anchor), so the certificate verification should be failing one way or another. The certificates in question are all v1, and lack subjectAltName and extendedKeyUsages. According to https://bugs.chromium.org/p/chromium/issues/detail?id=308330 such certificates (lacking SAN) are going to fail in Chrome 58 anyway, so you will want to start generating v3 certs regardless.
,
Mar 9 2017
ERR_CERT_INVALID vs ERR_CERT_AUTHORITY_INVALID is just a distinction about whether or not the underlying cryptographic library outright rejecting the certificate - as it may be doing for v1 certificates on Windows. I'm going to go as close as WontFix/WAI - as Eric mentioned, these certs are outside the realm of what's reasonable to expect to support. I left the view restrictions on because there's a private key there, and want to confirm with the reporter that it's OK to share before opening it up.
,
Mar 10 2017
The issue with v1 certs is noted. Keys involved in this test were generated for the test.
,
Mar 10 2017
,
May 10 2017
Issue 720070 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by palmer@chromium.org
, Mar 9 2017Components: Internals>Network>Certificate