It works on older versions of macOS (tested on OS X 10.9 Mavericks).

I'm removing Security labels and adding SSL>EV + Security>UX components.

Removing RV-G

I'm not sure this is something we should characterize as RBS, given the discussions about EV.

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Re: this not being RBS, this looks like a regression in expected behavior. I'm not sure which EV discussions you mean, but as far as I know no changes have been decided upon or targeted for M55. 

mattm@ - how is progress coming on fixing this regression?

I have a fix, but it needs a bit more work, and cleanup and polishing.

re: Comment 8: Whether or not EV represents a security feature, or if this is 'simply' a UI regression. I agree, it's a regression, but it's a question about whether or not it significantly breaks users' to be a release-block versus a regression to resolve in a subsequent release.

Got it. I think it meets the bar of RBS.

mattm@ : Could you please review the screen shot if its fine now on 56.0.2905.0.
Seems to be working fine on Mac 10.11.6 and 10.12.

Deleted: 655612_Oct_31.png 451 KB

	655612_Oct_31.png 451 KB View Download

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

durga: Hm, I'm not seeing that. 56.0.2905.0 on 10.12.1, doesn't show EV still for me.

Agree with mattm@ I don't see the EV on Mac OSX 10.12.1 with latest Chrome Beta(55.0.2883.35), Dev(56.0.2906.0) and Canary(56.0.2907.0).

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure all fixes are ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16.

Tested this issue on Mac OS 10.12.1 using chrome latest Dev M56-56.0.2914.0 by following steps mentioned in the original comment. Observed EV UI in the certificate.

mattm@ - Attaching screen-cast for reference, Could you please confirm is this is the expected behavior of the issue? 

Deleted: 655612.mp4 1.4 MB

	655612.mp4 1.4 MB View Download

The EV UI is in the omnibox, next to the padlock. If the site validates as EV, there will be an company name in green next to the URL.

What that screencast shows is just the certificate viewer. Having the text "EV" in a string in the cert doesn't mean it successfully validated as EV.

Removing Needs-Feedback, as it sounds like it was directed at mattm@ and has been responded to.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b

commit 1a282f54af2ea79cf9aa0b78234e3b4053b4d73b
Author: mattm <mattm@chromium.org>
Date: Thu Nov 10 21:49:42 2016

Mac EV verification using Chrome methods rather than OS methods.

Previously we were using some internal/private Mac OS APIs to get the results of OS EV checking, and those APIs stopped providing results on Sierra when we stopped passing the hostname to the OS verification (see crbug/621684). Additionally, it was impossible to unittest the old implementation. The new method is similar to what we do on other platforms, does not depend on OS handling, and can be unittested. Due to OS API limitations, the new method will be less efficient, but that additional inefficiency is limited to sites with EV certs.

BUG= 655612 

Review-Url: https://codereview.chromium.org/2456523003
Cr-Commit-Position: refs/heads/master@{#431367}

[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/chrome/browser/ui/certificate_viewer_mac.mm
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/cert_verify_proc_nss.cc
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/ev_root_ca_metadata.cc
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/ev_root_ca_metadata.h
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/ev_root_ca_metadata_unittest.cc
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/x509_util_mac.cc
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/cert/x509_util_mac.h
[modify] https://crrev.com/1a282f54af2ea79cf9aa0b78234e3b4053b4d73b/net/url_request/url_request_unittest.cc

**** Bulk edit -  please ignore if not applicable ****


A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

re: "the new method will be less efficient"

Can we get a ballpark on how less efficient we expect it to be? Will be see user complaints on this (sluggishness, beachballs, etc)? Do we have metrics that we can watch to see if if this is taking an inordinate amount of time for the long tail of users, and if we do not, should we add some before marking this fixed?

It executes on a worker thread, so it wouldn't cause any sluggishness/unresponsiveness, just might take slightly longer for the page to load.

There is the Net.CertVerifier_Job_Latency histogram, though it doesn't break down EV vs not.

Looking at that histogram for canary channel results on versions before/after 2916:
on 10.11: mean is 54ms both before and after the patch.
on 10.12: mean is 92ms before the patch, 44ms after the patch.
(The prior poor performance on Sierra was due to the hack to get AIA working again, this CL re-worked the revocation policy handling on Sierra.)

Requesting merge to 55. Been on canary for a few days, don't see any crashes or related bugs filed. 

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/945b76c48334c49d343cd43139418a3ef2298e1b

commit 945b76c48334c49d343cd43139418a3ef2298e1b
Author: Matt Mueller <mattm@chromium.org>
Date: Mon Nov 14 22:45:06 2016

Mac EV verification using Chrome methods rather than OS methods.

Previously we were using some internal/private Mac OS APIs to get the results of OS EV checking, and those APIs stopped providing results on Sierra when we stopped passing the hostname to the OS verification (see crbug/621684). Additionally, it was impossible to unittest the old implementation. The new method is similar to what we do on other platforms, does not depend on OS handling, and can be unittested. Due to OS API limitations, the new method will be less efficient, but that additional inefficiency is limited to sites with EV certs.

BUG= 655612 

Review-Url: https://codereview.chromium.org/2456523003
Cr-Commit-Position: refs/heads/master@{#431367}
(cherry picked from commit 1a282f54af2ea79cf9aa0b78234e3b4053b4d73b)

Review URL: https://codereview.chromium.org/2499083003 .

Cr-Commit-Position: refs/branch-heads/2883@{#568}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/chrome/browser/ui/certificate_viewer_mac.mm
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/cert_verify_proc_nss.cc
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/ev_root_ca_metadata.cc
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/ev_root_ca_metadata.h
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/ev_root_ca_metadata_unittest.cc
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/x509_util_mac.cc
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/cert/x509_util_mac.h
[modify] https://crrev.com/945b76c48334c49d343cd43139418a3ef2298e1b/net/url_request/url_request_unittest.cc

Verified this issue on Mac OS 10.12.1 using chrome latest M55-55.0.2883.51. Observed EV UI certificate is in the omnibox, next to the padlock as expected. Hence adding TE-Verified label.

Attaching the right screen-cast for reference.

Deleted: 664807.mp4 1.3 MB

	664807.mp4 1.3 MB View Download

The CL also fixes  issue 655612 , which breaks WebSocket connections to a subset of secure sites.

I would like to request a merge to stable M54. Should I do it here, or on  issue 655612 ?

Adam: as one of the OWNERS, I would like to request this not be merged to M54, which is a large CL with risk. Happy to discuss this offline.

Hi +mattm, it seems this fix still doesn't work for all sites.

For example. https://secure.ingdirect.fr is EV-certified on Chrome 54, but in Canary 57.0.2937.0 on macOS 10.12 it still doesn't display the EV badge.

Previously EV verification on Mac would depend on the OS idea of what CAs are EV, but now Mac Chrome uses the Chrome-internal EV policy list. This means there may be some differences from earlier versions, but on the upside we now have consistent behavior across platforms. That site already was not shown as EV on chrome on other platforms. (See  issue 442481  for that particular CA.)

Security>UX component is deprecated in favor of the Team-Security-UX label