Issue metadata
Sign in to add a comment
|
ERR_SSL_SERVER_CERT_BAD_FORMAT with serial number longer than 20 bytes
Reported by
shawnsmi...@gmail.com,
May 8 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/604.1.19 (KHTML, like Gecko) Version/10.2 Safari/604.1.19 Steps to reproduce the problem: Microsoft Internally generated Root CA is now failing on both beta and dev channels. This certificate is being used by an enterprise proxy server to decrypt traffic. The certificate was functioning up until recent (last 2 weeks) chrome 59 and chrome 60 (Dev and Beta Channels). Certificate appears fine in all respects. It appears the certificate returned by the proxy is an intermediate certificate which references the root CA. The intermediate certificate is NOT loaded into the keychain and has not been in the past when this was working. What is the expected behavior? This certificate should work correctly. Certificate is trusted in in the OS X Keychain. What went wrong? The certificate is now failing and Chrome is returning: ERR_SSL_SERVER_CERT_BAD_FORMAT for all web sites attempting to traverse proxy where certificate is being used. Did this work before? Yes Chome 59 Beta Chrome version: 60.0.3088.3 Channel: dev OS Version: OS X 10.12.4 Flash Version:
,
May 8 2017
,
May 8 2017
Also, can you try on latest Canary channel and see if it works there?
,
May 8 2017
It is not working on Canary Version 60.0.3093.0 (Official Build) canary (64-bit). I will grab the net-export.
,
May 8 2017
Thank you for providing more feedback. Adding requester "xunjieli@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 8 2017
Thanks for providing the log. It appears the end-entity certificates generated by this intercepting proxy have a very long serial number field, in this example, 37 bytes long. RFC 5280 specifies a maximum of 20 bytes for the serial number.
,
May 9 2017
Did something change recently to start enforcing this serial number length? I don't believe the certificates changed. Just wondering so I can communicate with our security teams on next steps?
,
May 9 2017
It should not have worked on other Chrome platforms (including ChromeOS, Linux, and Android), but we've been trying to harmonize our enforcement and bring consistency to our platforms. Chrome 59 brought a bit more consistency to macOS as our other platforms. Definitely resolving that length should be a top priority :)
,
May 10 2017
It seems that this issue is not one that must be fixed by enterprise team. Removing "enterprise" label.
,
May 10 2017
My enterprise team who is on windows 10 can't seem to reproduce the error with chrome 59 beta. Is it possible the macOS branch is more restrictive?
,
May 10 2017
Yes, see Comment 9
,
May 10 2017
Please note that I ran across this as well in the beta channel. If this change makes it into stable, will cause huge pain for large enterprises that are using ADFS (Active Directory Federation Services) SSO.
,
May 10 2017
brian: by "this" do you mean your certs also have too-long serial numbers? Or just that you got an ERR_SSL_SERVER_CERT_BAD_FORMAT error? If it's the latter, please file a new bug including a net-export log as described above (but first try the latest version: beta 59.0.3071.47, or latest canary)
,
May 10 2017
Ah apologies. It was the ERR_SSL_SERVER_CERT_BAD_FORMAT. Bumping to latest beta 59.0.3071.47 resolved the issue.
,
May 11 2017
,
May 11 2017
Going to mark as wontfix, but feel free to reply if you have more questions later.
,
May 15 2017
We have noted that the intermediate certificate in question with the bad serial number is being generated by CISCO WAS using our root certificate. We have escalated a case to CISCO and they have noted they have 3 other cases already in queue regarding this issue. I will note case status as we receive updates.
,
May 16 2017
Note that we have decided not to tie stricter serial number parsing to this release, but we will revisit it in the future. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by xunji...@chromium.org
, May 8 2017Labels: Needs-Feedback