Issue metadata
Sign in to add a comment
|
On OS X Sierra, a wildcard certificate behaves differently for two subdomains
Reported by
claudio....@gmail.com,
Oct 10 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17 Steps to reproduce the problem: Please note that I redacted the real names of the 3rd level domain for security reasons since not all those domains should not be accessible from outside our network. Our domain "tech26.de" uses a DigiCert wildcard certificate. If you access FOOBAR1.tech26.de Chrome doesn't complain, but if you access FOOBAR1-api.tech26.de (note the "-api" suffix) Chrome complains with "This certificate was signed by an unknown authority". Those subdomain are both served from an AWS EC2 machine. The only difference about those subdomains is their name and the cypher (one is using AES_128_CGM and the one failing is using AES_256). I fetched the certificate with `echo | openssl s_client -showcerts -servername gnupg.org -connect FOOBAR1-api.tech26.de:443 2>/dev/null | openssl x509 -inform pem -noout -text` and `echo | openssl s_client -showcerts -servername gnupg.org -connect FOOBAR1.tech26.de:443 2>/dev/null | openssl x509 -inform pem -noout -text` and the result is exactly the same (empty diff between the outputs). Note that Safari and Firefox are not complaining and the problem is only present on Sierra. What is the expected behavior? There should be no complaining about a bad TLS certificate. What went wrong? I cannot access my subdomain due to a security exception (which is not). Did this work before? No Chrome version: 53.0.2785.143 Channel: stable OS Version: OS X 10.12 (16A323) Flash Version:
,
Oct 10 2016
Sorry, bad copy/paste for `echo | openssl s_client...` part, where there is a spurious "gnupg.org". I retried again with the correct hostnames and the results are the same.
,
Oct 10 2016
,
Oct 10 2016
Removing Security type and view restrictions, as this is a functionality issue that fails in the secure direction.
,
Oct 10 2016
claudio.cicali -- Could you attach a chrome://net-internals log? https://dev.chromium.org/for-testers/providing-network-details provides details. Possibly Related: https://bugs.chromium.org/p/chromium/issues/detail?id=645629
,
Oct 10 2016
Not at the moment because I don't have Sierra and I asked a colleague but apparently even going incognito the log contains A LOT of things we'd like not to share. I'll try again when I will find a "clean" Sierra to work with. I took a look at the related bug and it looks indeed related.
,
Oct 10 2016
Re #6, In the absence of the log, two pieces of information would be useful-- 1. Does this repro in the latest Chrome Canary build on the affected machine, and 2. How many certificates are being sent from the server (e.g. when you check openssl s_client -showcerts, how many certs are listed)?
,
Oct 11 2016
We tested on Canary and the problem is solved. So it's definitely the same issue as #645629 Hope the fix will deployed in stable shortly. Thanks for inspecting it; tell me if you need more information, but I consider this issue closed.
,
Oct 11 2016
There's also a possibility it might be related to issue 621684 , which changes hostname checking. Could you test on beta as well (54.0.2840.40 or newer)? That should narrow it down.
,
Oct 12 2016
Version 54.0.2840.50 beta (64-bit) also works.
,
Oct 12 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by claudio....@gmail.com
, Oct 10 2016