New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 791869 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Jan 2018
Cc:
█ sc00335...@techmahindra.com
asymmetric@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

EV Certificate not displaying Properly

Reported by kesne...@gmail.com, Dec 5 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
1. Navigate to ca.darkmatter.ae
2. *Note the URL is not green nor does it say secure*
3. Open Developer tools --> Security
4. Certificate displays --> Certificate error
There are issues with the site's certificate chain (net::ERR_CERT_UNABLE_TO_CHECK_REVOCATION).
5. View Certificate --> displays certificate as valid

What is the expected behavior?
The website should have the green URL with a Secure or Company Name in it.  

What went wrong?
Website is not displaying the EV certificate correctly.  Also produces an error in the security Developer Tools: Certificate error
There are issues with the site's certificate chain (net::ERR_CERT_UNABLE_TO_CHECK_REVOCATION).

Did this work before? N/A 

Chrome version: 62.0.3202.94  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

We also have another website that uses the same certificate however it is not live yet.  But it also receives this error: Certificate error
There are issues with the site's certificate chain (net::ERR_CERT_UNABLE_TO_CHECK_REVOCATION).  

If you manually switch in the Mac Keychain to Always Trust the certificate it works, that however is not a real fix.  

The certificate displays as valid when you inspect it so we are not quite sure why we are getting this error. 

On Windows all browsers work flawlessly.
On Mac OS X Mozilla Firefox works however Chrome and Safari do not.  
-Firefox to my knowledge does not use the Macs keystore. 

EV policy : (2.16.784.1.1.7.35.2.2.1.1 ) .    

UAE EV TLS Certificates. 2.16.784.1.1.7.35.2.2.1.1.
Screen Shot 2017-12-05 at 8.33.22 AM.png
68.8 KB View Download
Screen Shot 2017-12-05 at 8.33.37 AM.png
5.1 KB View Download
Screen Shot 2017-12-05 at 8.39.54 AM.png
196 KB View Download

Comment 1 by sc00335...@techmahindra.com, Dec 5 2017

Cc: sc00335...@techmahindra.com
Components: Internals>Network>EV
Labels: M-64 Needs-Triage-M62 Triaged-ET
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on latest canary 64.0.3284.0 canary but not seen in equivalent dev version i.e 64.0.3284.0 dev and not seen on reported version 62.0.3202.94 with steps mentioned in comment#0.

Issue is not seen in Linux and Windows

As this issue is inconsistent but able to reproduce this issue marking as Untriaged and adding appropriate labels.

Could someone from Internals>Network>EV team take a look into this issue.

Thanks!
791869.mp4
3.6 MB View Download

Comment 2 by paulir...@chromium.org, Dec 8 2017

Components: -Platform>DevTools
Not an expert on security but AFAIK, Chrome asserts additional requirements beyond what Mac does, so the Mac certificate viewer not flagging anything doesn't mean Chrome will accept the certificate. 

This error indicates Chrome "cannot download the CRL or talk to the OCSP responder"

Reading the source a bit more indicates you can get this error under a few conditions:
* there is no revocation mechanism on the cert
* chrome is unable to check the revocation
* the revocation is offline
* oscp server error

good luck

Comment 3 by kesne...@gmail.com, Dec 10 2017 

If you visit the site on Chrome on Windows it works fine.  Leading us to believe that it is an issue with Mac + Chrome.  In the above video it seems that the newer version works fine for Mac + Chrome.  Do you know what the differences are between live and that dev version?
          ~The new Version 63.0.3239.84 (Official Build) (64-bit) still produces the same result as 62.XXX


Additionally we have already checked our CRL's and OCSP as we had the same thought process that you did.  Both turned out to be fine.

Best Regards,
Kesner

Comment 4 by kesne...@gmail.com, Dec 21 2017 

Good Morning,

We were having some issues, I will have our technical guy comment on this post to explain.  However they believe that they have fixed the issue.  Could you guys test again to see if the results are the same as in the video above or if everything works now.  Thank you!

Best Regards,
Kesner

Comment 5 by kesne...@gmail.com, Jan 7 2018 

We ended up finding that the Mac was routing to 443 by default for some reason even when entered as 80 for ports.  However after completely clearing Safari's cache it seemed to fix the issue for safari and Adobe signatures.  With a quick complete clear of the cache of chrome *AFTER* clearing Safari's cache, Chrome started to work again.

Thank you for your help and assistance.

I have attached the Wireshark screenshots if you are interested.

Best Regards,
Kesner
Safari_for_apple.png
88.2 KB View Download
Chrome_for_apple.png
257 KB View Download
FireFox_for_apple.png
222 KB View Download
Working_Safari_capture.png
592 KB View Download

Comment 6 by rsleevi@chromium.org, Jan 31 2018

Status: WontFix (was: Untriaged)
WontFix/WorkingAsIntended. The responder is failing when we attempt to check, and that is the expected behaviour.
►

Sign in to add a comment