This post was originally published on this site is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to

We’re seeing a huge push towards encryption on the web right now and as a part of that push the topic of certificates comes up with some frequency. EV certificates, or Extended Validation certificates, seem to be quite polarising with either a love them or hate them response. I’m going to take a look at what EV certs are and if they’re worth it.

Extended Validation Certificates

Before we get started lets make sure everyone is clear on what it is we’re going to be talking about. When you setup HTTPS on your site and get a certificate there are 3 different types of certificate you can get. They are Domain Validation (DV) which is what my blog has, Organisation Valiation (OV) and Extended Validation (EV). When you visit a site like mine with a DV certificate you get the usual indicators in the address bar that you have a secure connection. In Chrome that’s a green padlock with the word Secure and a green https:// in the URL.


If you visit a site with an OV certificate everything looks exactly the same as a DV certificate as there is no difference in visual indicators. Coupled with them being more expensive than DV certificates I think this is why almost nobody uses OV certificates. That just leaves EV certificates which do get slightly different UI treatment from the browser.


Here we can see the EV certificate on Have I Been Pwned? by Troy Hunt who went through the process of obtaining one last year. You can see the browser treats it slightly differently and you get a company name and a country code instead of the word ‘Secure’ in the address bar.

The value proposition

There are a few advertised benefits to EV certificates so let’s take a look at each one and weigh up the pros and cons of each one.

Identify verification

When you go to a website like in your web browser you don’t know which company you’re talking to. If there is a green padlock in the address bar you can be sure you’re speaking to the owner of, you just don’t know who owns the domain. This is what EV certificates are supposed to resolve.


When I go to in my browser it tells me that the company that owns this domain is Twitter, Inc. based in the US. The idea is that I, the user, know that I want to visit the website of Twitter, Inc. based in the US and no other company and I can now manually verify that using the UI in the browser. One problem here is that the company name behind a domain might not be related to the branding on the website due to parent/subsidiary companies and other various legal structures.


The EV certificate on was displaying the name of the company that owned them for a long time which is Hibu (UK) Ltd. and not something like Yell (UK) Ltd. as you might expect. I’m not sure we could expect any user to know, or honestly care, that Yell were owned by Hibu and that’s why they were named in the certificate. I guess Yell thought the same because they did change the name of the company in the end so they could show a recognisable value in the certificate.


My problem with this whole aspect of EV certificates is that it places some pretty big requirements directly on the user. The user must first know the domain name of the company they want to visit, the user must then know the legally registered name of the company they want to visit and the user must finally validate that the name and domain are correctly shown by the browser. I’m not a fan of any security mechanism that places a burden on the user and I’m really not a fan of any security mechanisms that depends on the user behaving in the ‘correct’ way for it to work.

Green padlocks

One of the things that I wish we had across browsers was a consistent UI so we could reliably inform users of the indicators to look for. We can’t say ‘look for the green padlock in the top left’ because it might not be on the left and it might not even be green. The old faithful Microsoft Edge doesn’t show DV certificates with any green in the address bar and chooses to keep them grey instead.


On the bright side though you can go and buy yourself an EV certificate which Microsoft Edge will treat you with a green UI.


I have genuinely spoken to website operators with EV certs who got them because they wanted a green UI in Edge and EV CAs do use this as a selling point. I guess we must already be running out of valuable reasons to use EV certificates if we’re talking about working around UI quirks in one of the smallest market share browsers out there…

Revocation Checking

This is one aspect of EV certificates where there is actually a tangible and provable benefit to, but there are still some rough edges here. If a hacker manages to steal your private key it means they can use your certificate to trick your visitors and intercept traffic. This is obviously a situation that we don’t want to happen so you can mark your certificate as revoked with the aim of stopping the browser from accepting it. Unfortunately though revocation is broken and you can read my article there for more details. The TLDR; is that with an EV certificate the browser is not allowed to skip the revocation check and it must be completed. If you do want this level of protection on your DV certificate then you can request that your CA marks the certificate as OCSP Must-Staple to get the same level of protection. The OCSP Must-Staple extension is supported by Firefox already but Chrome is holding back because it places a requirement on the site operator to staple correctly 100% of the time otherwise your certificate would not be accepted. In the case of EV certs the browser can fall back to doing an online OCSP check which is slow and expensive. While I do like the idea of this particular requirement for EV certs, it’s not properly communicated to site operators that they absolutely must enable OCSP stapling or it will slow down their website whilst leaking their visitors browsing data to the CA or potentially make it unavailable in some rare circumstances.

The other problem with the revocation checking component is that it only protects certificates that you, the genuine host, obtain. If an attacker is able to obtain a mis-issued certificate then it’s most likely going to be a DV certificate (without OCSP Must-Staple) and then EV is no use to you.

Certificate Transparency

I’m super excited about Certificate Transparency and honestly it can’t come soon enough. CT will require that any certificate issued by a CA will have to be logged into public logs for the whole world to see. The idea behind it is that no one will be able to obtain a certificate for your domain name without you knowing. We can also fully audit what the CAs are doing to make sure they’re behaving themselves too. EV certificates have had to be logged into CT since Jan 2015 but the requirement is coming for DV certificates too. It was supposed to be Oct 2017 but after problems including CAs not being ready, it was pushed back to April 2018 instead. So, whilst EV certificates may have to be logged to CT now, all certificates will soon have to be logged to CT anyway. Not only that, but just like the revocation issues above, an attacker is most likely to obtain a DV certificate anyway. That means it doesn’t have to be logged to CT right now and EV still didn’t help you. For the CT requirement of EV certs to be useful an attacker would have to obtain a mis-issued EV certificate from a CA for your domain which is an unlikely prospect.

The problems with EV

I did outline a few problems with EV certificates weighed against the value proposition above but there are still a few more things that I just can’t come to terms with about EV.

Depending on the user

I touched on this above with the identity verification in that the user has to know and identify the correct legal name in the address bar. Depending on the user for a security mechanism to work is just nuts. There, I said it. We shouldn’t expect and require the user to care, we shouldn’t expect the user to perform this check manually and correctly every single time they visit a page and the next logical step here is to blame the user if they used the site without the appropriate EV markers in the browser. How else would this work? “Oh, you used our site but the correct EV indicator wasn’t there? Never mind.” Didn’t think so…

If EV is to be successful it needs some kind of technical measure that can be enforced without the required cooperation of the user in our security. This isn’t theoretical and we’ve actually already been through exactly this problem before and solved it. Cast your mind back a few years when we’d constantly hear things like ‘check for the padlock in the address bar’ or ‘check for https in the URL’, remember that? How did that work out of for us? It didn’t work out that well and we knew it was a problem to demand and expect the user to perform these checks each and every time they came to our website. This is one of only two reasons for the introduction of HTTP Strict Transport Security, because SSL stripping attacks were just so easy and successful. If it was sufficient to simply tell the user to look for https in the address bar, why did we need HSTS? When we look at EV we’re now expecting the user to identify and require an inconsistent UI indicator for various sites that they visit.

If EV had some kind of technical measure that would force the UA to perform this check on behalf of the user then maybe I could start to get on board with the idea of EV. Maybe we could have an extension to the HSTS spec and add a require-ev directive or some/any other mechanism to do the same thing. Without a way to enforce EV and shed the dependency on the user, EV will never be reliable because the user is not reliable.

EV –> DV fallback

This largely ties in with my closing point in the section above but does introduce some other considerations. If you have an EV cert on your site right now and someone obtained a DV certificate without your consent, the revocation and CT requirements further up are already blown right now. The other problem is that we are again back to depending on the user for our security. The user now has to visit your website and notice that the UI has changed from EV to DV. Not only do they have to notice that but they now have to refuse to use the website, despite having a green padlock and https in the address. The likelihood of this happening is again near zero and without some kind of require-ev mechanism to prevent this fallback from happening, you having an EV certificate offers you no protection in terms of the revocation of transparency issues mentioned above.

Bonus Round: Go to Twitter in your browser, take a screenshot and post it in the comments below and tell me the country you’re in. Twitter uses EV and DV certificates depending on your location so some of you will get EV and some of you will get DV. Here’s what I see when I visit Twitter and take a look at what Troy sees in the next section.


Who uses EV?

Given the apparent benefits of using EV certificates and the value in proving to your visitors that you are indeed a legally registered business, it’d be fair to expect that companies the world over would be using EV certificates on their sites. I was going to take screenshots of the address bar across some of the largest sites in the world, but I think this tweet from Troy sums it all up nicely:

The ten largest sites in the world, that probably have the ten largest budgets to spend on their sites in the world, are not using EV certificates to provide the crucial registered company information to their visitors. This really doesn’t help set an example as to why EV is such an important and much needed feature for site operators. One counter argument I have seen to this is that these sites are so big and so well known that they simply don’t need the additional proof of legitimacy that EV brings. Everyone knows who Google and Reddit are, we don’t need EV to know we’re on Amazon’s site, their brand presence is enough for them. This would imply that smaller and lesser knowns sites benefit more from EV as it allows them to establish more confidence in their visitors, but the numbers don’t back it up. As we move down the site rankings and look at the smaller and smaller sites, they’re less likely to use an EV certificate:

This could be tied in to the fact that EV certificates are really expensive and as sites get smaller and smaller that cost is comparatively larger and larger. Still, the fact remains that tiny numbers of websites are using EV certificates overall.

Bad hygiene

There, I said it, EV certificates encourage really poor hygiene. I’m not talking about having a shower in the morning though, I’m talking about certificate lifetime and key rotation. EV certificates are expensive, running into hundreds of dollars, and they’re a pain to get, generally taking hours or days, everybody wants to avoid the process as much as possible. This results in people going for the longest possible lifetime on their certs to avoid this whole painful process. I can totally understand the motivation behind that, but this really isn’t the kind of thing we want to be encouraging. We need to be encouraging lower certificate lifetimes, not higher.



We’re only seeing a 2 year maximum age here because the lifetime is limited by the CA/Browser Forum otherwise they could have been valid for longer, which is even worse! For comparison here’s my certificate which is only valid for 90 days.


Not only that but the CAs themselves are encouraging site operators to go for longer validity periods with discounts and offers. Of course this makes commercial sense as a business because they get a larger payment but again, it’s not the direction we want to be heading.



Encouraging sites to use longer validity periods on certificates is bad for security and bad for the ecosystem.

Independent research

This is probably my biggest complaint and my biggest problem with EV certificates to date. In all my time working in the field and in all the research I’ve conducted for this blog post, the only people I can find that advocate the use of EV certificates are either a CA, a reseller of a CA or someone else who stands to gain financially from the sale of EV certificates. Now, to clarify, I don’t have a problem with a business promoting the use of their product, don’t get me wrong. My problem is that there’s no data to backup the claims that EV has any value. Where are the user studies, the empirical research, the independent findings? If EV certificates provide such outstanding value then prove it to me, show me the data! Right now it seems that all we can do is take the word of the CAs that the thing they’re selling us really does have some value, and I’m just not sure that’s a sane approach in any way, shape or form. If there is someone out there that advocates the use of EV, or there is some research or whitepapers on the proven value of EV then please do drop by in the comments below and link me (seriously, please do, I want to present a balanced argument wherever possible). CAs are making a healthy profit on the sale of EV certificates and I think it’d really help their case if they spent some of that profit on some proper, independent research to prove their value.

User education

Another thing that’s always struck me as odd is that I’ve never seen any form of user education program around the use of EV certificates. Sites that use them never seem to inform their users that they should be looking out for EV indicators and I’ve never seen an EV CA putting effort into educating users either. If users aren’t aware of what EV indicators are or mean then surely the total value they provide is absolutely zero? Are we working on the assumption that all users are already aware of exactly what EV is and that we simply don’t need to educate them?

Yes this is a very small Twitter poll and while we can’t take the results as conclusive proof, it highlights the point I’m trying to make. Outside of my tech friends I’d struggle to find someone that could even explain what a certificate is, let alone understand the differences between EV and DV or that they’re supposed to behave differently in the presence of one or the other. The entire value proposition of EV lies in the user understanding what the indicator means and what significance it has. Right now I just can’t see how they have any value.

The TOFU problem

Much like HSTS, EV also has a kind of TOFU problem that is difficult to avoid. If a user visits a site for the first time, and that site shows a DV certificate, what should they do? Maybe the site is supposed to be using an EV certificate and any frequent visitor would know that, spot the downgrade to a DV UI and immediately stop using the site as a result. But what about those that have never been before? They see a secure connection and simply continue using the site with the DV certificate as they would for any other site on the web. This does tie in a lot to the EV –> DV fallback issue I mentioned earlier and perhaps we could fix it with a similar preloading mechanism to HSTS, but it’s just another small problem that needs addressing.

Mobile UI

With the rise of the mobile platform in recent years, an ever increasing portion of browsing takes place on mobile devices. What users of iOS devices may not know is that Chrome does not show the EV UI on mobile platforms, you just get a standard DV UI for your expensive EV certificate. Here is Chrome on Android showing an EV cert and a DV cert.



Here’s Chrome on iOS showing an EV cert and a DV cert.



Finally here’s Safari on iOS showing an EV cert and a DV cert.



The only time on the mobile platform that it seems to even be worth having an EV cert is if you’re using Safari on iOS. Even then though, I have to say, the difference between PayPal, Inc. and isn’t exactly massive. Yes, to you or I sat here inspecting the address bar we can see the difference, but the average user going about their business has a green address bar with the word PayPal in it, which is probably going to be enough to use the site, if they even look at the address bar.

EV does not mean trustworthy

If you have an EV certificate it means you registered a company name. It can be trivially simple to register a company name in various jurisdictions and being a registered company certainly does not make one trustworthy. I can name plenty of registered companies that I wouldn’t ever do business with, but they can all apply for an EV cert. When Troy was working on getting his EV cert for HIBP he registered, de-registered, re-registered and tinkered around with various things to get exactly the name he wanted to show up in the address bar. It just seems like there shouldn’t be that level of flexibility in the system already. My other concern here is that I think we’re falling into the trap that we saw with DV certificates in that EV certs would just become a race to the bottom. Years ago it was hard to get a DV cert and that’s why people overloaded the trust we placed in them, and we could well be on the way to doing exactly the same thing with EV by treating them the same way. An EV indicator does not mean a site is trustworthy, it does not mean a site will not phish you, it does not mean anything other than the domain is owned by a registered legal entity. As EV certificates become cheaper and easier to obtain, it will erode the little value placed in them already.

EV indicators can be removed by Antivirus and other apps

There are quite a few different scenarios when the user should have an EV UI in the browser but will instead end up with a DV UI despite there being nothing wrong. This happens when any form of TLS termination is happening and this is increasingly common. When software like antivirus installs itself, it will generally install a root CA so it can do traffic interception and make sure your internet traffic doesn’t contain any nasties. The problem is that on the outbound side the AV program will get an EV certificate but it cannot generate an EV certificate to present to the browser, only a DV certificate. This is true for any browser on any platform and this can be more common than you’d expect. Just think, any device with an AV program that does traffic inspection can never see an EV UI, any corporate device that has a root CA installed so they can inspect traffic or any other scenario where proxying may be taking place. I simulated this on my own local PC using Fiddler and this is what PayPal looks like.


That’s a standard DV UI and the EV indicators have been stripped because the certificate was issued by a locally trusted CA. You can see the details in the certificate inspector.


In this scenario I guess that as a user I’m supposed to notice the missing EV UI and immediately cease using the site because I can no longer be sure this is PayPal Inc. If we were to depend on this EV UI there are a lot of scenarios where it might not show up which is proven by the recent standardisation issues of TLS 1.3 because of middle box hardware being intolerant.


I’m not opposed to the idea or the value of EV certificates but right now they just seem like a nice revenue stream for CAs. The technical and user issues outlined above need to be addressed before EV can have real value. The amount of information and mis-information surrounding them really doesn’t help and there’s also some pretty wild claims from CAs about what EV can do.

Entrust recently spoke of the need for EV certificates and Comodo tell us how we can avoid phishing attacks by using EV. Again though the requirement on the user to act accordingly is the ultimate downfall and we saw phishing sites using EV as far back as 2011 and as recently 2 months ago.

Perhaps we will see some technical advances to strengthen EV and address other issues in the wider CA ecosystem too, but until then, count me out.

At L Technology Group, we know technology alone will not protect us from the risks associated with in cyberspace. Hackers, Nation States like Russia and China along with “Bob” in HR opening that email, are all real threats to your organization. Defending against these threats requires a new strategy that incorporates not only technology, but also intelligent personnel who, eats and breaths cybersecurity. Together with proven processes and techniques combines for an advanced next-generation security solution. Since 2008 L Technology Group has develop people, processes and technology to combat the ever changing threat landscape that businesses face day to day.

Call Toll Free (855) 999-6425 for a FREE Consultation from L Technology Group,