Is it possible to add ownership information to a Let’s Encrypt Certificate?
Picture Related:
What you’re looking for is an Extended Validation (EV) certificate, which allows you to provide your organization’s name as part of the certificate. CAs issuing EV certificates need to vet any information on the certificate (Does the organization exist under that name? Did the organization authorize the issuance? etc.), which is typically a manual process that cannot be completely automated and therefore would be too expensive to provide for free.
Let’s Encrypt issues Domain Validation (DV) certificates which essentially connect domain names to cryptographic keys, but do not connect them to any real-world entities.
2 Likes
There's also the "OV" certificate 
Although, obviously, Let's Encrypt doesn't issue those either.. 
1 Like
Worth noting that Firefox only recognizes two categories of certificates - DV and EV - so the organization/“Owner” info would not be visible in the screenshot provided by OP with an OV certificate.
1 Like
That's interesting. Makes you wonder what's the point of having OV then ...
P.S. @AutoJukebox 2 links that might be useful:
https://www.cybersecureasia.com/blog/firefox-security-making-your-site-safe-for-mozilla-firefox-users
Thanks for the response. Hopefully one day Let’s Encrypt will support EV
Not a chance… Let’s Encrypt is all about free and automated certificates… There’s just a core team of developers and management people… How on earth could they provide a certificate which would require manual and in depth verification of an organization? Quick answer: they can’t 
Well, there are 3-5 major web browsers depending on how you count, and Firefox is just one. As I understand it, the story goes roughly like this. OV certificates existed (though without anyone formally recognising them as a category) from the outset of the Web PKI in the mid-1990s when Netscape invents SSL. At first there was no DV. All certificates were as expensive and difficult to get as EV certificates are today, with manual steps involved. Certificate Authorities declared "Classes" of certificate, with the more expensive classes being "better". But there was no indication of class in browsers and each CA set its own rules. The X.500 Distinguished Names were inconsistently filled out, mostly by signing whatever was in the CSR. With no formal standards and precious little enforcement from Netscape or Microsoft, a race to the bottom began, as companies which secured themselves a place as trusted roots in the major browsers began to offer "Domain Verified" certificates for less money. The means of verification were largely hand-rolled (some big CAs have patents you read about how they "verified" domains). Generally the indication that this far inferior verification had happened was in some human readable text in the certificate, for example OU=Domain Verified, or even OU=Verified by Name-of-CA O=Name-of-CA and CN=domain.example. If you paid more money, you could fill out more fields and they might do some rudimentary checking of the values in those fields, depending on how much money you'd paid and the "class" of certificate.
One problem with a race to the bottom (if you're a commercial outfit) is that prices hit zero and then income hits zero and then you go out of business. But perhaps just as important, quality also diminishes to hit the reduced price point. Should a person be able to get an SSL certificate for hotmail.com by asking Hotmail for the email address systemadm@hotmail.com and then just filling that out in a web form and clicking the resulting email link? Erk. Trust in the system dimished, and some backlash began to hit the browser vendors who'd selected these CAs to trust.
So, browser vendors were sick of DV, and public CAs were sick of DV but for different reasons. The CAs thought the best way forward was to have a new kind of "really, really trusted" certificate (for which they'd charge a lot of money), EV but keeping all the old ones. The browser vendors thought the CAs should apply all their proposed new rules for EV to their existing certificates and stop the race to the bottom. The CA/Browser forum is the incarnation of that ongoing discussion, and the results are the compromise we all experience day-to-day. EV certificates have that "green bar" that CAs believed would help sell them, OV, DV (and IV and others) were standardised, with a policy OID to tell browsers programatically what sort of verification was done. The rules for EV are tighter than they ever had been for older certificates, but the rules for all other certificates were also tightened up gradually.
But CA/B has no formal legal status, and all browser vendors actually implement their own rules, albeit referring to the CA/B Baseline Requirements and EV Guidelines. So, Chrome on Android doesn't have a green bar, and Firefox doesn't consider OV certificates different from DV certificates and Internet Explorer / Edge ignore all policy OIDs except the ones from the CA/B but other browsers accept custom OIDs, and so on.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.