Personal like or dislike of EV aside for a moment, we can all agree on what the name of EV certs implies. Organisations get their company details in the certificate and CAs have to do some extended validation of that data compared to a normal certificate. Turns out, that doesn't always happen...


Extended Validation

The current version of the EV Guidelines (v1.7.0) might not make for exciting reading but it's the basis for this blog post. In the document you can see that the number one, defined purpose of an EV certificate is to "Identify the legal entity that controls a Web site". There are strict details on what information the certificate should contain and how that information should be verified, which if course is the whole purpose of an EV certificate and the responsibility of the issuing CA to conform to. That's why I was a little intrigued when I saw this tweet.



This looked like a simple error in the issuance of an EV cert where a company that operates in different countries had provided their Danish company number whilst registering a certificate for their company in the Swedish jurisdiction. Now, whether the company provided the wrong number to the CA, or the CA was only provided an address and looked up the company number, it doesn't really matter, the data in the certificate is wrong. Because the data in the cert is now known to be wrong it must be revoked by the CA in question. There is no alternative. You can see that the certificate was indeed revoked here.



This did get me wondering though. Are errors like this common?


Certificate Transparency to the rescue!

I've talked about CT a lot on my blog but if you're not familiar with CT you should check out my blog on Certificate Transparency, an introduction. One thing that we can do with CT logs is search all certificates for things that we're interested in. For example, here is a query that returns all EV certificates where the country code for the organisation is "GB", which is all EV certs in my country that I might be interested in looking at...



Checking for certificates with bad data

Given that the initial tweet grabbed my interest because the company number field was bad, I thought I'd start there. Companies in the UK are registered with Companies House who assign a company number that conforms to a general format of a numeric value and can start or end with a letter. Given my basic understanding of company numbers I thought I'd start there with some simple checks to see if I could find anything that didn't conform. Whilst scanning over results that didn't pass my simple regex, a certain value quickly caught my attention.


Subject:serialNumber N/A


Now, Subject is the technical name for the organisation that applied for the certificate so the Subject section of a certificate contains all of the details about that organisation. The serialNumber field within the Subject section of the certificate should contain the organisation's company or registration number. The appropriate section of the EV Guidelines is 9.2.5 which outlines in detail what is required.



Having read that, we can see that N/A is not a valid value, yet here are certs that contain it:



You can click through onto each of those certificates and see that they should all be revoked now. The whole point of an EV certificate is to bind the certificate to a legally registered company so how we ended up with the company number being "Not Applicable" is a bit of a mystery. Of course this is wrong so when I notified the CA they had to revoke them and issue their customer a new certificate with the correct information present inside it.

Another interesting one was these certs which seem to have the company phone number present instead of the company number. Close, but not close enough.



The phone number thing gave me the idea to scan certificates and see if I could find other phone numbers, and I got a hit... This particular certificate contains a phone number in the Subject:jurisdictionLocalityName field and it contains the name of the person who applied for it in the Subject:jurisdictionStateOrProvinceName field?! I'm not sure who Lisa Cord is, but I'm pretty sure that a person cannot be a State or Province within a country!



So far I'd just looked at certificates where the Subject:serialNumber didn't conform to an easily recognised format and found quite a few things. Then I wondered what about if the field was set at all. Could it be missing? Turns out, yeah!



Again, have a click through and you will see a large amount of those are now revoked and presumably replaced by new certificates with the appropriate information present. Along similar lines of the field not being set, I wondered if it was set to something like an empty string or no value. Another quick query and it took a little while to return, so I waited. Had I broken something? Was the database busy? Or, was it just returning a large number of certificates... I apologise for not being able to embed the gist here, but the following list contains 3,887 certificates! Instead, here is the link to the gist and here is what that gist looks like, all 67 pages of it.



That's quite a list... Again, click through a selection of those and you can see that the majority are already revoked and we can assume replaced by new certificates with the appropriate values set.


Why are there so many errors?

This seems crazy to me. As a security researcher with a little bit of interest in this field, I was able to find over 4,000 EV certificates that needed to be revoked, corrected and re-issued by the CA in question. Assuming an average cost of $250* per certificate, that's $1,000,000 worth of EV certificates that needed revoking. To top it off, these are the ones I'm talking about publicly because they've been reported to, and confirmed by, the CAs in question. I have another few batches with problems that are currently being worked through.

It's also not just me doing work like this and highlighting problems, there are others too. As I said at the beginning of the blog, it was Cynthia finding a problem that prompted me to look for a problem and many others before us too. For example, here's a heap of EV certificates issued to US companies in states that don't exist?!

It's really concerning that the whole point of an EV certificate is to contain reliable information yet with a little work I was able to find huge amounts of problems. According to Censys there are ~845,000 currently issued and unexpired EV certificates, meaning that just the ones mentioned in this blog post are ~0.5% of all EV certificates and they are invalid.


Further work

It's known within the industry that there are some widespread issues with the validation of data within EV certificates. We've seen default fields like "SomeState" and "SomeCity" left in certs by accident, but I'm talking more systemic than that. Another avenue I'm looking into at present is the jurisdiction fields in GB certificates. The EV Guidelines state, in section 9.2.4, that:


These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency.
For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information.


The jurisdiction values that can be set are subject:jurisdictionCountryName, which is required, followed by subject:jurisdictionStateOrProvinceName and even subject:jurisdictionLocalityName if required. If the company registration agency operates at the country level, like Companies House does here in the UK, then State/Province and Locality must not be included according to 9.2.4 above. Now, that's all based on my reading and understanding of 9.2.4 but I'm happy to stand corrected so if you believe or know otherwise, drop me a comment below and let me know. The appropriate Censys query for these certs is here and it does return ~14,000 certificates that I'd be interested to know more about, especially the ones where the State/Province and Locality values match, which also seems odd.



Going forwards

I plan to keep an eye on a few other things regarding the issuance of EV certs and if anyone has ideas on other avenues to research then let me know or please do join in and contribute. I'm not here looking for issues with CAs just to cause problems, I believe that with the power that a CA is granted they should be expected to strictly adhere to the rules and quickly rectify problems when they are identified. CAs are powerful organisations and monitoring them is a worthy cause! I'm glad to see that all of the problems I've reported so far have been dealt with quickly and appropriately and I'm sure that any future findings will be too. Just to wrap up, here's a few other issues I found with basic typos in the certificates themselves, but only happening on individual certs, perhaps suggesting manual entry of the data?





* Looking around at certificate cost I can see that Sectigo sell single/multi domain certs starting at $232/$697 and DigiCert also sell single/multi domain certs starting at $344/$574. It's possible to get them cheaper at re-sellers, though I didn't see any that indicated they were purchased from re-sellers and I also didn't inspect every single certificate. An average cost of $250 is at the lower end of the spectrum where I'm comfortable but it could also be higher too.