9

I just installed a EV SSL certificate on my server. It has been done correctly and is working, the issue is that Chrome does not show the company name in the green address bar, just shows the green padlock and green https:// like you get when you have a standard SSL certificate.

IE and Firefox display the green bar and company name as they should.

Does any one know why I'm getting this issue with chrome?

I have no insecure content on my page, I have run a check with ssllabs.com and the results came back 'B' because

This server does not mitigate the BEAST attack. Grade capped to B

BEAST attack Vulnerable INSECURE (more info)

RC4 Yes PROBLEMATIC (more info)

Does anyone know how I get around this problem? Does this mean that chrome makes more in-depth tests to check whether it's valid, more so than other browsers.

Thanks.

Richard
  • 91
  • 1
  • 1
  • 4
  • 2
    It might be a Chrome bug. https://code.google.com/p/chromium/issues/detail?id=226080 – Xander Jun 12 '13 at 16:37
  • There have been a bunch of changes to how EV and Standards SSL certs are displayed with the different browsers, list with screenshots here: https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design.html – Mike Buckbee Jun 26 '14 at 21:32

3 Answers3

7

BEAST attack Vulnerable INSECURE (more info)

RC4 Yes PROBLEMATIC (more info)

These warnings are not directly related to your certificate. They're more about your SSL configuration. When a client connects to your server over SSL, the client and server will negotiate which protocols they want to use to exchange keys and encrypt data.

BEAST is a vulnerability with SSLv3 and TLSv1. Basically there's a crypto flaw in SSLv3 and TLSv1 (fixed in TLSv1.1, which isn't widely implemented) that allows a hacker (man-in-the-middle) to attack long running sessions. You can mitigate this issue by configuring your server to use ciphers that are immune to BEAST and to prefer those ciphers.

On nginx the configuration looks like this:

ssl_ciphers RC4:HIGH:!aNULL:!MD5:!ADH:!kEDH;

ssl_prefer_server_ciphers on;

This will use RC4 with clients that support it and fall back to AES.

u2702
  • 2,086
  • 10
  • 11
5

You can see the same effect on https://www.comodo.com/

They have an EV certificate signed by themselves. Firefox trusts it:

Comodo EV SSL cert in Firefox

but Chrome doesn't.

Comodo EV SSL cert in Chrome

Chrome works fine with Verisign:

Verisign EV SSL cert in Chrome

The problem here is likely that your browser doesn't trust your SSL certificate vendor. It's possible that you have messed up the configuration somewhere (chain certificates can be troublesome) but it will be hard for us to figure that out without you posting a URL here.

Try clicking on the lock then clicking on the Connection tab and then Certificate Information (as I have done in the second screenshot). Hopefully that screen will tell you what Chrome thinks is wrong about your certificate.

The browsers do behave differently with regards to many aspects of SSL/TLS and especially when it comes to EV certificates. Here's one example of them handling revocation differently.

Ladadadada
  • 5,163
  • 1
  • 24
  • 41
  • 4
    The example you give, `https://www.comodo.com/`, actually works OK for me in Chrome on _Windows_ - I get the green bar and full company name in the address bar. – MrWhite Jun 12 '13 at 14:39
  • Thanks a lot for your reply. I checked the certificate information tab and no errors being reported and chrome seems to have accepted the certificate. However on the 'details' tab there are two things that have a exclamation mark next to them, ive uploaded a screen shot here: http://imgur.com/jNhpvuW my URL is https://clippinghub.co.uk I'm not sure how I could resolve those. Or even if they would make a difference to the way chrome interacts with the certificate. edit- comodo.com also works for me on windows chrome. it's such a strange thing. – Richard Jun 12 '13 at 14:44
  • And your domain works fine for me in both Firefox and Chrome on a Mac. – Ladadadada Jun 12 '13 at 14:50
  • Yes it does, chrome, firefox and safari, they all work fine. – Richard Jun 12 '13 at 15:07
  • On Debian it just shows the https on green but checking the certificate it says it's valid – The Illusive Man Jun 12 '13 at 16:22
  • @Richard: FWIW, both comodo.com and starfieldtech.com have exclamation marks against the same two fields as your cert ("Basic Constraints" and "Key Usage") and both of those domains display the green bar/company name and yours doesn't so those fields are unlikely to be the problem IMO. – MrWhite Jun 12 '13 at 16:48
  • Thanks, I think it must be an issue with chrome on windows and linux. Tried windows 7 and 8 same problem. Mac OS fine on all browsers. As Xander commented under my question "It might be a Chrome bug. code.google.com/p/chromium/issues/detail?id=226080" might be worth waiting to see if anything comes of that. As least it's showing valid and not throwing a untrusted warning at users. – Richard Jun 12 '13 at 18:00
  • 2
    On the screenshot, Chrome shows a greep padlock icon, while it actually thinks the certificate can't be trusted. Isn't this really bad? – Andrey Vihrov Jun 12 '13 at 18:11
  • 1
    The exclamation marks on the Windows certificate details pane only mean that the properties are marked as 'critical' (ie clients that don't understand the property type should fail instead of ignoring them). This is standard for the properties shown and nothing to worry about. – bobince Jun 12 '13 at 21:09
3

Since the current highest rated answer isn't an actual answer, I'll provide one: Chrome requires Certificate Transparency on EV, Firefox and Edge and Safari do not.

Here's an example SSL Labs scan of a cert that is missing CT: it displays as EV in Firefox, Safari and Edge and as a low-trust DV cert in Chrome:

enter image description here

You can (and should) fix this by talking to your certificate vendor, asking them to include an Signed Certificate Timestamp (SCT) in their certificates using the relevant x509v3 field.

mikemaccana
  • 413
  • 3
  • 14