I just changed a password on a Google account while using the Chrome browser. After doing so, I noticed that the https connection to Google was not highlighted in green signifying that it was an "Extended Validation Certificate".

Does Google not use "Extended Validation Certificates"?

If they do, then why wasn't their https connection highlighted in green?

  • 1
    It doesn't make a lot of sense for Google to use EV certificates on google.com and youtube.com because the domains are the primary trust point. It might make sense on domains connected to real-world Google things such as Android phones so that users can be certain that the domain is owned by the same company that made the phone. – Ladadadada Feb 27 '14 at 17:43
  • Related: security.stackexchange.com/questions/13453/… – Pacerier Apr 12 '16 at 13:39

Note: I work for CertSimple, which specialises in verifying site owners for EV certificates.

The answer is no. Google does not currently use Extended Validation certificates. Apple, Microsoft, Twitter, GitHub and most banks do. Google does not.

Why doesn't Google use an EV certificate?

Google does include a verified legal identity in their certificates - the google.com certificate is an OV certificate, which, like EV, asserts Google Inc as the owner of the public key in the certificate - thanks @lie-ryan for noticing this. OV is a predecessor of EV, but does not show any visual indicators of the identity to the end user.

I run a company that specialises in EV. Having had many conversations with Google staff about EV (and having some idea of the culture from having worked for Google in the past), the answer is typically one or more of the following:

  • Google's own certificates are checked by Chrome itself. Unless your Chrome binary is altered it's very unlikely you'll see a fake Google certificate.
  • Until recently it was difficult to get a working SSL cert for google.com.mg or google.com.im, as even domain validation CAs would do some minimum work to check for well known companies when issuing certs. This has changed as CAs now entirely automate the process and do not perform any more validation work than what the baseline requirements include.
  • Inertia: Google's original certificate was issued when 90's era background checks were replaced by domain validation by the CAs.
  • Requirements for wildcard certificates - EV requires all domains be verified by the CA and included in the certificate as SANs. While the cost wouldn't be an issue (Google run their own CA), the change in process would.
  • Belief that end users will notice the difference between DNS domains. Imagine the following sites pop up in your browser:

    A https://www.google.co.uk/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

    B https://www.google.com.im/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

    C https://www.google.com/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

    D https://security.googleblog.com/

    E https://googlehelp.com/

    F https://www.withgoogle.com

    If it wasn't obvious, A, C, D and F are controlled by Google Inc, B and E not.

  • Belief that EV background checks are is slow, painful and expensive. This is true, though we are working on addressing this.

  • Google does not have any data on the effectiveness of Chrome's EV UI and is this unsure of how effective it is.
  • The CAs have behaved incredibly poorly in the past - companies selling IE5 support until 2015, 'seal in search' injects logos into Google search results pages, Symantec's 2015 miss-issuance and subsequent non audit. Many of these things are profoundly user-hostile. As a result, there is mistrust between the browsers and CAs and even things that are pro-user, such as helping Alice connect to Bob's Bank Inc get caught up in the friendly fire.
  • Due to to the AMP project hosting content on google.com for prefetching purposes, a lot of full-page content not controlled by Google is now hosted on google.com. This includes phishing content (specifically, fake Google oauth pages). Having an EV certificate for a site with user generated full-page content could harm users.

Responding to the inaccuracies of the current answer

Google wants added security in a technical sense, not visual cues.

Extended Validation is not added security by visual clues: it is added security by background checks, which assert the connection between a legal identity and a public key.

HSTS and HPKP keep users safe from all known attacks other than a local system compromise

This is incorrect. EV puts a legal entity inside the certificate, in the organization and jurisdictionOfIncorporatedName fields. These are then shown to the browser. If someone registers yourbank.com.mg, or yourbank.com.im, or any other domain they will be able to get a 'domain validated' certificate. However they will have a much harder time passing the EV background checks. HSTS and HPKP will not prevent the browser from connecting to the fake site.

instead Google created HSTS and HPKP  

This is incorrect. HSTS, HPKP and EV serve different purposes: HSTS prevents protocol downgrade attacks, key pinning prevents certificate misissuance, EV provides association of a legal entity to the certificate. These are different goals and a solution to one categorically does not help with the others.

EV is marketing. It doesn't provide anything.

This is incorrect. From the EV guidelines

The EV Certificate Warranties specifically include, but are not limited to, the following:

(A) Legal Existence

(B) Identity

(C) Right to Use Domain Name

(D) Authorization for EV Certificate

(E) Accuracy of Information

(F) Subscriber Agreement

(G) Status

(H) Revocation

Note that domain validated certificates do not assert any connection between a certificate and a legal entity. ie, the DV certificate on yourbanklogin.com doesn't make any assertion that the site has anything to do with Your Bank Ltd.

EV signals that the CA claims to have done more work in return

This is misleading: the CA has done more work. Additionally the CA's work is audited for compliance against the EV Audit Criteria Guidelines

  • 2
    Why doesn't Google include a verified legal identity in their certificates? Google's certificate is an OV certificate, so their certificate do include verified legal organization identity. In addition to that, they run their own sub-CA, who only issue certificates for "Google and Google Affiliates" according to their CPS. – Lie Ryan Feb 19 '16 at 14:04
  • Excellent point @lieRyan - I've amended the answer and credited you. – mikemaccana Feb 19 '16 at 14:17
  • Re "many conversations with Google staff about EV"; But are these people also the ones working on Google's cert? (e.g. Adam Langley-esque?) – Pacerier Apr 12 '16 at 11:35
  • 2
    I think the biggest problem with EV certificates is that they are "backwards". Meaning that when they show up, you are confident that the site is properly secured. But when they don't show up, you don't know if there has been a compromise in the certificate chain, or if the site just doesn't use an EV certificate. Consequently you don't know any better whether or not to trust an https site without drilling down the entire chain at every request, which no user will ever do. – Eric B. Aug 9 '16 at 20:45
  • 2
    I guess the question then becomes "why don't browsers display the Organization of an OV certificate more prominently, like they do for EV certs. – RomanSt Apr 19 '17 at 18:02

Nope. Extended validation is a way of getting extra vetting from the CA in exchange for increased prominence in the browser. It's a feature offered by CAs like Verisign allowing them to charge more in exchange for more thoroughness.

But extra thoroughness on the part of the CA isn't what a company like Google is after. Google wants added security in a technical sense, not visual cues.

Any additional niftyness implied in the green bar UI indication only serves to reinforce trust once the user has already correctly landed on a safe page; these users are safe anyway, no matter what color the UI bar is. The users that need protection are the ones whose connection is not already secure, and those users can't be protected by any level of certificate verification.

So instead Google created HSTS and HPKP to strictly enforce that only valid certificates be used on critical domains (such as google.com, accounts.google.com, gmail.com, etc.) and ensure all sensitive communication happen only over verifiably secure channels.

They add to this a rigorous anti-phishing, anti-spoofing, anti-malware campaign which flags sites that conduct malicious operations and automatically displays an warning interstitial page when the user visits a known-bad site. Not perfect, but immensely helpful.

And most importantly, they invented and support via third-party (yubico) a second-factor security token which is reliably impervious to all variations of phishing attacks. Using this token, you cannot be phished.

Taken together, these technologies make their users safe from all known attacks other than a local system compromise. And what's more, all the security tools they've created are available for anyone to use themselves to secure their own platforms, so any company can protect their users.

The common theme here is removing the burden of security from the user, as it should be. The (old and broken) way that EV certificates try to provide security is by providing more information to the user when things are going right. But this doesn't work. Users are not reliable guardians of their own security, and giving them positive feedback when they visit the right site won't help them detect when they've visited the wrong one. It may help in a couple of cases, but by and large this is a non-starter and a waste of resources.

  • 7
    @mikemaccana EV isn't technology, it's marketing. It doesn't provide anything, it signals that the CA got paid more and claims to have done more work in return. But there's no guarantee, no technical controls. No actual protection. But that doesn't mean no protection exists; that's where HSTS, key pinning, Certificate Transparency, and other features that Google has deployed come in. The company is interested in solutions that protect the user, and is willing to pay a lot to get them. But EV doesn't qualify. – tylerl Feb 17 '16 at 16:18
  • EV is not marketing. It is a process for running background checks, the process is here: cabforum.org/wp-content/uploads/EV-V1_5_7.pdf EV providers are audited yearly (and sometimes more frequently) for their adherence to the processes in the EV checks. EV associates a legal identity with a public key. By checking, and explicitly showing that a given legal entity controls a domain it allows users to know that they're actually connecting to 'Bank Inc' (their bank) rather than bank.com.mg (not their bank). – mikemaccana Feb 17 '16 at 16:25
  • 3
    @tylerl: this is where many people misunderstood what OV and EV certificate is about. OV and EV certificate is all about identification, not technical security. Technical security (encryption) is the same across all certificate types (well except DSA or SHA-256), but the level identification checks are very different. OV ties a certificate with a legally registered organization and to the person who have access to the organization's registered phone, EV does extra checks to ensure that the organization's representative are really authorized to represent the organization. – Lie Ryan Feb 19 '16 at 14:23
  • 2
    @mikemaccana EV is marketing because ultimately the protection is at the human level, not the technology level. An actual person behind the keyboard and chair has to understand, notice, and care that the browser now has a shiny "green bar". I'd hazard a guess that 99+% of people have no idea what the "green bar" means. – Steve Sether Feb 19 '16 at 15:48
  • 2
    @SteveSether: EV certificate can be quite powerful at the technology level when combined with HPKP and HSTS. The idea is that you pin your certificate to your EV CA's certificate. Unlike pinning to your own certificate, pinning to your CA gives you the flexibility to reissue/replace your certificate which takes effect immediately; but now your attacker will have to compromise an EV CA which presumably better internal security practices than a DV CA. – Lie Ryan Feb 19 '16 at 16:42

The Google Certification Practices Statement (available here) indicates the CA follows the CA/Browser Forum Baseline but does not mention the Extended Validation Guidelines.

Moreover it is specified that the Google CA may issue wildcard certificates (and does, google.com, youtube.com, android.com are using wildcard certificates) which is not allowed for EV certificates. Therefore Google should amend the CP and CPS if she decides the issue EV certificates.

  • 2
    This is probably the reason why. Google runs their own sub-CA, probably because of the large number of domains they use, and they probably do not qualify for the audit requirements to run an EV CA as set out by the CA/B Forum, which is much more stringent than the audit requirements to be a regular CA. – Lie Ryan Feb 19 '16 at 13:55

Google is not a fan of EV. Just follow @sleevi_ on Twitter or look at the CA/B minutes and you'll see this.

Their contention seems to be that it offers no technical benefit, is sales and marketing for the CAs, is being mis-marketed by those CAs as provided by extra security and most importantly, is ignored by users.

They have also indicated they may drop the extra UI you gain from EV because of this.

There are some merits in that argument though I must say I don't agree with it in its entirety.

While I agree that technically they don't differ from DV or OV and that most users don't look for EV indicators - and wouldn't even notice if a site stopped using EV, I do think any extra UX indicators are worth considering - especially given their relatively cheap cost. Web designers spend long enough arguing about button colours and any improvement in sales that they make, that splashing green all over the address bar cannot be a bad thing in my opinion! This may seem woolly and fluffy rather than based on facts (and I would like to see some more recent, independent, research made into EV!) every tweak counts in the competitive online market.

And here's where Google has extra differences:

  • Most of their services are free. They do not require a credit card to use. So people use them without thinking. An ecommerce site, where an extra reassurance could be the difference between a sale or not, might easily see the value in an EV cert.
  • Google has fantastic name recognition. "Bob's example inc." may not.
  • Google has lots of engineer and runs the most popular browser on the Internet, and it's own CA, so can implement HSTS, HPKP and even bake those right in to Chrome. Preloading HSTS and HPKP is not something I would advise most sites to do as they wont have the technical expertise and resources to prevent screwing it up! To be perfectly honest I'm not a fan of HPKP at all. Too little reward for too much risk. But that's another argument.
  • Google has lots of muscle. If a CA mis-issues a cert for a Google domain they come down on them light a tonne of bricks, add extra restrictions on them, or simply put them out of business.

These put Google in a very different situation than most other companies.

Finally there ARE technical reasons why EV is better. Not because it's EV, but because of how they are implemented or what's required by browsers to show extra EV UI. CT is mandatory for EV status for example but not yet for DV or OV. As I say this is nothing to do with EV per se, but does give you access to new technologies earlier. Again Google, running its own CA, does not need to be held up in implementing these for it's own OV certs.

  • "They have also indicated they may drop the extra UI you gain from EV because of this." Do you remember the source for this statement? Also, Regarding HPKP, a better alternative is to use CAA records which prevent rogue or misconfigured CA's from issuing certificates for your domain (as long as you can trust your current CA). – Judge2020 Dec 31 '17 at 22:11
  • Ryan Sleevi from Google has stated the this on the CA/B mailing list several times and in other places (e.g. follow him on Twitter). Most recent discussion here: groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/…. It’s already gone from Chrome on mobile. My thoughts on the subject are here in case that’s of any interest: tunetheweb.com/blog/what-does-the-green-padlock-really-mean – Barry Pollard Dec 31 '17 at 22:26
  • HPKP is on its way out (groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/…) precisely for the reasons I didn’t like it. And yes CAA and CT are much better, less dangerous technologies though not a direct replacement. – Barry Pollard Dec 31 '17 at 22:28
  • @BarryPollard 'already gone' from mobile Chrome isn't quite accurate - Google never bothered showing users identity in mobile Chrome. Keep in mind Google are not concerned with whether users understand what they're connecting to - APF's research is focused on ensuring users proceed with any encryption connection regardless of who is on the other end. Google's browser indicator team could easily research better identity markers - eg, flagging identity on first POST (this is Apple Inc, this is google.com, this is google.com.mg) - but does not does do. – mikemaccana Jan 31 '18 at 12:46

An EV certificate makes little sense when the domain belongs to a company with much greater brand recognition than the CA doing the verification.

An EV is useful if you might have a customer who's going to say, I wonder who this "Google" company is, and if they're actually a legitimate business. This seems improbable.

An EV doesn't in any way increase the security of the connection, or make an online transaction any safer.

Your Answer

