Why Choose OV TLS Certificates? The dilemma of the middle child

Choosing amongst the different certificate types

Imagine three brothers. The youngest is nimble, outgoing, and popular. He’s also growing very rapidly and will soon be the tallest in the family. The oldest is steady, thoughtful, and circumspect. He’s a high achiever, in a job with lots of responsibilities and makes loads of money. But what about the middle sibling? The classic middle child syndrome would have him struggling to find his niche between these two exemplars.

It’s much the same (as far as analogies go) with the three types of SSL/TLS certificates – Domain Validation (DV), Organization Validation (OV) and Extended Validation (EV) – available for use in the internet security ecosystem.

First, just like siblings, all three share the same genes. That is, from a cryptographic point of view, all three certificates provide exactly the same level of confidentiality and integrity protection of the communications channel by using standard security technologies (private/public keys, cipher suites, encryption algorithms, etc.) in exactly the same way using SSL/TLS. The difference, as with siblings, is how they interact with their environment and take advantage of the opportunities presented to create and project their public persona. The choice of a certificate type for a website aims at projecting a particular image of its trustworthiness and dependability.  Is the site trustworthy enough to interact with for the purposes the end user has in mind?     

DV certificates, the most basic type of certificate, are inexpensive (and in some cases free, these days!), quick and easy to obtain and growing tremendously in popularity as they provide a straightforward way for anybody to join the HTTPS Everywhere movement. EV certificates are at the top of the hierarchy, more thoroughly vetted before issuance and not given out to just about anybody. These are also audited from time to time and provide the stolid and trustworthy persona that successful corporations and organizations wish to project: they get their corporate name and the green lock icon displayed on the browser address bar.

But what about OV certificates? While these offer somewhat greater assurance of identity beyond DV certificates with respect to vetting the certificate holder, what is probably most frustrating for this sibling is that it just cannot stand out when compared to its younger, and more popular, brother. Both DV and OV certified sites show the same visual indicators on the browser address bar – a lock and, in some cases, the word “Secure”. An obvious question is why anyone would purchase this certificate type instead of a DV certificate if its greater assurance of the identity of the owner of the visited website is not more overtly recognized by the industry and proclaimed from the browser address bar.

This post will explore exactly what niche this middle child of the certificate fraternity fills. To that end, we’ll explore the certificate vetting process, the environment in which the different types of certificates are used and point out situations where OV certificates might just fit the bill, as it were.

The certificate issuance vetting process

Prior to the formation of the CA/Browser Forum (CABF) in 2005, each Certification Authority (CA) followed similar, but not identical, processes to verify the identity of a domain owner before issuing one of the three types of certificates.  There was no formal standard to guide their choices and differences, leaving room for variations in the quality of assurance, warranties and, naturally, price. CA vendors were also not very rigorous in describing their vetting practices in their published Certification Practice Statements, the reference to which could be included in each issued certificate.

The CABF is an industry consortium, currently made up of ~50 CAs and all the major browser vendors, that was formed “as part of an effort among certification authorities and browser software vendors to provide greater assurance to Internet users about the web sites they visit by leveraging the capabilities of SSL/TLS certificates.” To this end, in 2007 it published version 1.0 of the Extended Validation (EV) SSL Certificate Guidelines which its members were expected to adopt. (In addition to formalizing the enhanced steps to vet the identity behind a domain name, this document mandated the presence of a clear signal in the browser window to show the use of an EV certificate, which has led to the almost universal adoption of the green lock icon.) In 2011, the CABF adopted the Baseline Requirements for the Issuance and Management of Publicly-Trusted SSL/TLS Certificates, which extended the common standards for issuing SSL/TLS certificates beyond EV to also include DV and OV certificates.

What follows is an attempt to distill, for our purposes, the key features contained in these very detailed and formally worded documents.  It is not a description of technologies, but processes. Needless to say, the description below is a summary and the documents should be consulted for the nuances, exceptions and other nitty-gritty details.

Common steps

There are the steps that all CA members of the CABF are mandated to follow as part of the certificate pre-issuance process independent of the type of certificate sought:

• Check the certificate signing request to see that it meets minimum cryptographic requirements;
• Check the submitted customer/applicant data against an internal database maintained of all previously rejected certificate requests and revoked certificates, and reject (or at least further probe) any that appear to be at high risk for fraudulent use;
• Check that the customer/applicant at a stated location is not in any government black list of individuals, organizations or country prohibited from getting a certificate.

Domain Validation Certificate issuance steps

These include all the common steps described above together with additional checks to create a baseline level of identity assurance that defines this type of certificate. The most significant point to be noted for DV certificates is that the identity of the customer/applicant or owner of the website where the certificate will be used is NOT verified. All that is assured by the following checks is that a particular public key is cryptographically bound to a particular domain, the one for which the certificate is sought. The additional steps are all ways to check that the site owner/certificate applicant has control over the domain. These include:

• An email exchange confirming the application between the CA and the administrator of the domain as provided in the Whois record or at one or more standard email addresses for a domain that administrators might be expected to monitor;
• Verifying that the site administrator can make a requested change (e.g., adding a resource encrypted with the public key of the applicant) to a server hosted by that domain, thereby establishing the applicant’s control over that domain as well as showing the ownership of the associated private key;

Starting September 2017, there will be an additional mandatory requirement: administrators that wish to obtain a DV certificate for a domain must ensure that the corresponding DNS entry includes a notation (formally called a resource record) that identifies those CAs that are permitted to provide certificates for that domain. This is called CA Authorization (CAA), an Internet Standard defined by the Internet Engineering Task Force to add an additional check to prevent the mis-issuance of certificates. Prudent domain owners would use the CAA record to ensure that no CA other than those they authorize can issue certificates for their domains. We will describe CAA more fully together with other techniques mitigating certificate mis-issuance in a future blog post.

After April 2018, Google’s Chrome browser will only accept certificates which have been registered prior to issuance in a publicly available Certificate Transparency (CT) log. (We provided an overview of Certificate Transparency in a previous post and shall follow up with a more detailed post in the future.) This is not a CABF requirement yet, but one can expect other browser vendors to soon follow the leader’s move and also require CAs to use CT logs if they expect their certificates to be trusted by browsers.

The steps for domain validation can be complete by email exchanges and API calls, which allow for automation. This minimizes costs, allowing quick and easy issuance of DV certificates which contribute to their increasing popularity. It allows literally anyone controlling a domain to get a SSL/TLS certificate.

Organization Validation Certificate issuance steps

OV Certificate issuance requires completing all the steps described above, and also additional checks to verify the identity of the organization or individual that owns the domain for which the certificate is sought. This added validation is the OV certificate’s key distinction.

The domain owner’s identity information in the certificate application is checked by a variety of means (with some distinctions depending on whether the applicant is an individual or an organization):

1. For businesses, verifying the information against 3^rd party business databases, government business registries, etc., or obtaining a signed letter vouching for the ownership of the domain from a duly-vetted legal representative;
2. For individuals, verification of the identity using a valid government issued ID (e.g., passport, driver’s license etc.)
3. Verification of the domain owner’s address via utility bills, bank statements, etc.
4. A verification that the applicant for the certificate is connected to the domain owner with a phone call using information from a public database or, for an organization, calling a senior employee of the named organization to confirm the applicant’s employment status.

Successful completion of these checks allows the CA to include the organization name, and some or all other relevant information such as locality (city, state, province), and country in the OV certificate.

The steps taken for OV certificate issuance must be recorded and made available to an independent auditor for verifying compliance with the CABF Baseline Requirements.

Extended Validation Certificate issuance steps

The validation steps for obtaining an EV certificate are an extension of all previous steps. Many of the steps are much more rigorous versions of the steps described above for issuing an OV certificate. For instance, step 1 above is enhanced by checking the “active” status of the organization, step 2 requires a site visit while step 3 requires independent verification using a variety of means to check the applicant’s employer, relationship to the organization, etc. There are additional checks such as the use of uniform character sets in the domain name, consistent data (for names, addresses etc.) in all the supporting sources of information, etc.

EV certificates, therefore, include information beyond those of the OV certificate, such as the type of entity (corporation, government organization, etc.), where it is registered and registration number in a named database.

Such thorough vetting prior to the issuance of EV certificates make them the strongest level of identity assurance, and earn them the special visual indicator in the browser address bar that we described in an earlier post.

In what follows, we only point out factors that could motivate why EV certificates might not be suitable or even available to all customers.

• The CABF does not allow issuing EV certificates for wildcard domains, such as *.example.com.
• EV certificates are not issued to individuals, but only to an organization (specifically, those that the CABF define as a Private Organization, or Government Entity, or Business Entity) that is in an active state of doing business.

 

So, why use OV certificates?

By this time, the alert reader may well have discovered the sweet spot where an OV certificate is useful, indeed the only option possible in certain cases. In any case, we reiterate the following circumstances where OV certificates are uniquely placed to serve a particular customer segment:

1. The OV certificate is the highest level of trust that an individual as a domain owner can project. In other words, an individual does not have to register as a business entity (a sole proprietor of a LLC, say) simply to have this level of trust conferred.
2. Gaining access to an EV certificate requires adherence to the qualifications defined by the CABF for the eligible types of organizations or businesses. If a business finds that it cannot meet these, an OV certificate provides the highest level of trust possible under the circumstances.
3. Individuals or organizations that do not see the need (and added expense expense) to protect sub-domains under their ownership with individual certificates can take advantage of certificates issued to wildcard domains.
4. Organizations that do business using a different name than the name used in the formal registration of their organization would not, in any case, see the Doing Business As (DBA) name in the browser address bar when using the more expensive EV certificate – it shows the legal name of the organization.

Additionally, OV certificates have their own additional advantages over DV certificates:

1. When the certificate details are viewed, organizational information is clearly visible.  Organization information provides savvy end users and software applications with additional assurance that TLS connections are being made securely to the proper site, that there is not a “man in the middle” eavesdropping.
2. Some certificate authority companies, e.g. Comodo, offer insurance and/or warranty to protect against losses due to improperly issued certificates.  Typically, such insurance is included with OV and EV certificates and not available for DV certificates, for which only cursory validation is performed.

While not cheerfully profligate like DV certificates, nor as exacting and expensive as EV certificates, OV certificates do have a niche to fill which offers those that fall into this category a nice compromise between cost and value provided.