87

After running a few tests from Qualsys' SSL Labs tool, I saw that there were quite significant rating differences between a GoDaddy and VeriSign certificate that I have tested against.

Are all SSL certificates from different providers equal? If not, what should one base their decision on? Currently I believe that most people will weigh up the cost vs. brand (I.e.: GoDaddy ~$70.00 vs. Verisign ~$1,500.00).

I have a feeling from what I have seen that a lot of this also depends on how the SSL is actually implemented - would this be a more accurate conclusion?

For clarity:

curiousguy
  • 5,028
  • 3
  • 25
  • 27
Kyle Rosendo
  • 3,965
  • 4
  • 18
  • 17

5 Answers5

62

Disclaimer: This answer comes directly from the eHow article. No infringement intended.

Domain Validation SSL Certificates

Domain validated SSL certificates are used to establish a baseline level of trust with a website and prove that you are visiting the website you think you are visiting. These certificates are issued after the SSL issuer confirms that the domain is valid and is owned by the person who is requesting the certificate. There is no need to submit any company paperwork to obtain a Domain Validation SSL certificate, and these types of SSL certificates can be issued extremely quickly. The disadvantage to these types of certificates is that anyone can get them, and they hold no real weight except to secure communication between your web browser and the web server.

Organization Validation SSL Certificates

An Organization Validation SSL certificate is issued to companies and provides a higher level of security over a Domain Validation SSL certificate. An Organization Validation certificate requires that some company information be verified along with domain and owner information. The advantage of this certificate over a Domain Validation certificate is that it not only encrypts data, but it provides a certain level of trust about the company who owns the website.

Extended Validation SSL Certificates

An Extended Validation SSL Certificate is a "top of the line" SSL certificate. Obtaining one requires that a company go through a heavy vetting process, and all details of the company must be verified as authentic and legitimate before the certificate is issued. While this certificate may seem similar to an Organization Validation SSL certificate, the key difference is the level of vetting and verification that is performed on the owner of the domain and the company that is applying for the certificate. Only a company that passes a thorough investigation may use the Extended Validation SSL certificate. This type of certificate is recognized by modern browsers and is indicated by a colored bar in the URL portion of the browser.

Additonally, OV versus EV also have an impact in terms of insurance amounts in case of compromise. The insurance premium for an EV lies a lot higher than with an OV.

Read more/original: Mickey Walburg, Differences in SSL Certificates | eHow.com

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • 22
    Only EV SSL certs give you the green address bar; OV certs do not. – josh3736 Apr 04 '12 at 15:53
  • 14
    "The disadvantage to [DV] certificates is that anyone can get them". Not quite: you still need to be the owner of the domain, which in many cases is good enough. – Bruno Apr 09 '12 at 18:12
  • 4
    This information contains a number of inaccuracies. As mentioned already, it's not true that "anyone can get" a DV cert, nor that they "hold no real weight" - browsers trust them without warnings same as any other cert, they just don't show "green bar" (this is equally true of OV certs). OV/EV certs don't really provide a "higher level of security" at least not in a technical sense - security is not determined by the cert type, only that the cert was legitimately obtained. OV certs don't let you trust a company, just tell you who the company is. EV certs don't provide extra "reliability". – thomasrutter Aug 11 '15 at 07:08
  • 3
    All OV and EV certs do is show that the issuer verified additional details about the organisation than just their domain name - such as the company name - and in the case of EV this is reflected in the browser with a "green bar" and the company name being displayed. OV doesn't have a green bar so its benefits over DV are not visible to most users. There is no need to vaguely talk about "extra security" or "reliability" as if these are directly related, and obviously the cert never verifies that a company is "trustworthy", just that it is who it claims to be. Evil companies can buy EV certs. – thomasrutter Aug 11 '15 at 07:12
  • 1
    @fjw You're right, I removed that sentence. I think the main difference is probably more in regard to insurance amounts. – Lucas Kauffman Aug 11 '15 at 07:31
  • 2
    Note: No criticism intended toward you because the information is from the eHow article. It's only one of hundreds of inaccurate and misleading articles on the web about the differences between certificate types. – thomasrutter Aug 12 '15 at 01:06
  • @LucasKauffman your links now redirect and the content on the new link does not match your quotes – schroeder Jan 04 '19 at 09:21
  • Please note that in 2020, browsers such as Chrome/Firefox/Safari do not show any Green Bar anymore. This has been gone for quite a while. More info here: https://www.ssls.com/blog/why-the-green-bar-is-gone-for-good/ – Willster Nov 04 '20 at 17:47
44

It is ultimately the responsibility of the client's user to check the validity of the certificate. As a service provider, apart from educating the user if you can, there is not much you can do on your side: you don't control which certificates are trusted by the user's browser and you can't know whether the users have verified they using SSL/TLS properly and have not ignored potential warnings.

What you need to try to assess is how your user is going to react and check your certificate. I'm assuming the target audience for your website isn't necessarily technical or PKI expert. How your users are going to react will depend on what they've learnt about certificates. Unfortunately, there is a lot of conflicting or vague information on this topic out there, even coming from CA themselves (remember that CAs have a vested interest in making their customers want to purchase more expensive certificates).

Validation modes

The general purpose of a (public key) certificate is to bind an identity to a public key (therefore binding the identity to the server using the corresponding private key in the SSL/TLS handhsake).

Lucas Kauffman has already written an answer detailing the difference between domain-validated certs, organisation-validated certs and extended-validation certs. The real question you need to ask yourself is what you are trying to prove to the user.

The difference between these types of certificates is how that identity itself is defined.

The domain-validated certificates guarantee you that the certificate was issued to the owner of that domain. No more, but no less (I'm assuming the validation procedure was correct here). In many cases, this is sufficient. It all depends on whether the website you are promoting needs to be linked to an institution that is already well known off-line. Certificates that are validated against an organisation (OV and EV certs) are mainly useful when you need to tie the domain to a physical organisation too.

For example, it's useful for a institution that was initially known via its building (e.g. Bank of America) to be able to say that a certificate for bankofamerica.com is indeed for the place where you've given your physical money. In this case, it makes sense to use an OV or EV certificate. This can also be useful is there is ambiguity regarding which institution is behind the domain name (e.g. apple.com and apple.co.uk), which is even more important is the similar domain name is owned by a rival/attacker using the name similarity for bad purposes.

In contrast, www.google.com is what defines Google to the public; Google has no need to prove that google.com belongs to the real Google. As a result, it's using a domain-validated certificate (same for amazon.com).

Again, this is really useful if the user knows how to check this. Browsers don't really help here. Firefox just says "which is run by (unknown)" if you want more details about the cert at www.google.com, without really saying what is meant by this.

Extended-validation certificates are an attempt to improve this, by making the organisation-validation procedure more strict, and by making the result more visible: green bar and more visible organisation.

Unfortunately, this is sometimes used in a way that increases confusion, I think. Here is an example that you can check by yourself: one of the large UK banks (NatWest) uses the https://www.nwolb.com/ for its on-line banking services. It's far from obvious that the domain name belongs to NatWest (who also own the more logical natwest.co.uk name, by the way). Worse, the extended validation (if you check the name next to the green bar) is done against "Royal Bank of Scotland Group plc":

EV certificate look

For those who follow financial news, it makes sense because both RBS and NatWest belong to the same group, but technically, RBS and NatWest are competitors (and both have branches on the high street in the UK -- although that's going to change). If your user doesn't have that extra knowledge about which groups trade under which name, the fact that a certificate is issued to the name of a potential competitor should ring alarm bells. If, as a user, you saw a certificate on gooooogle.com issued to Microsoft or Yahoo, however green the bar is, you should not treat this as Google's site.

One point to bear in mind with EV certificates is that their configuration is hard-coded into the browsers. This is a compile-type setting, which cannot be configured later on (unlike normal trusted certificate stores, where you could add your own institutional CA cert, for example). From a more cynical point of view, some could consider this as a convenient way for the main players to keep a strong position in the market.

Seals

Some CAs also offer various "seals" that you can put on your website, usually with different colours depending on the type of certificate you purchased. They seem to be intended as an extra step to prevent less-reputable CAs issuing a valid certificate to the wrong party.

As far as I'm aware, these are completely useless from a security point of view. Indeed, when you click on it to have your certificate verified (for example, if you click on GoDaddy's "verified an secure" logo, you end up on this page), nothing tells you that the certificate you see is the same as the one that's sent to the service behind seal.godaddy.com. Indeed, if there was a MITM attacker between you and example.com, with another valid certificate for example.com issued by a sloppy CA, that MITM attacker wouldn't be between example.com and seal.godaddy.com. Unless the user really looks at the certificate in detail, the seal wouldn't help very much (bearing in mind that the attacker could simply remove the seal link or point it to the one from the other CA).

Insurances

Some certificates also come with some sort of insurance. You would get some sort of compensation should something go wrong during a transaction up to a limited amount. It's not clear to me what the conditions to claim such insurance would be.

Which one to choose?

At the end of the day, most users keep the default list of trusted CA certificates that are bundled with their OS or browser. Since the user interface don't distinguish between CAs very clearly, the overall security as seen by the user (whose responsibility it is to check the certificate) will be driven down by the lowest common denominator in each category (blue and green bars).

If it's important to tie the domain name to a "brick and mortar" organisation, it's worth considering an EV certificate. I personally don't think that the way UIs distinguish DV and OV certs is good enough to make displaying the organisation name with a blue bar useful.

If you're primarily known by your domain (or if there is no ambiguity at all that the domain is yours, from a user's point of view), go for any blue bar certificate. (Check the insurance details if that's relevant to your website.)

Vilican
  • 2,703
  • 8
  • 21
  • 35
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • 1
    Some CA imply, or clearly claim, that **EV means better crypto**, in addition to serious identity verification. (This seems no imply that non-EV means snake-oil identity verification.) – curiousguy Jun 27 '12 at 02:32
  • 1
    @curiousguy, "*Some CA imply, or clearly claim, that EV means better crypto*" I must admit I have never noticed this (do you have a link by any chance?), but that would be completely wrong. The cryptographic strength is determined by the cipher suite (and the PRNG, I guess), which is rather independent of the certificate (except key type, e.g. RSA/DSA). Of course, the key size matters, you get more or less the same key sizes for EV certs. – Bruno Jun 27 '12 at 02:38
  • I don't have a link or even remember which CA it was, but I do remember the claim was about minimum guaranteed RSA key size for EV certificates. Elsewhere I read a claim that EV certificate do not use MD5 (unlike regular certs). To me both claims actually read: "the weak cryptographic link will not be in EV certs, and might be in regular certs". IOW: there is absolutely no point unless you also fix the weak spots. – curiousguy Jun 27 '12 at 03:13
  • 1
    @curiousguy, you're right, as far as I remember EV certs require a 2048-bit key at least, and no MD5. This being said, I think MD5-based CA certs have been removed from most OS/browser distribution programmes. Not sure about the keysize, but even some cheap CAs only accept CSRs with 2048 bits or more. – Bruno Aug 18 '12 at 15:07
  • Even CAs make mistakes: http://googleonlinesecurity.blogspot.sg/2013/01/enhancing-digital-certificate-security.html – Pacerier Aug 13 '13 at 19:48
  • @Bruno, ***All*** CAs imply that DV is crap stuff only used by amateurs, OV is "so-so", and EV is what the big boys use. I've seen about 20 CAs implying this already. It always starts with the harmless phrasing "*Level 1, 2, 3*" and double-meaning phrases like "*provide the lowest level of validation*". Digicert, in an attempt to brainwash the world into spending more money on certs, jumped the shark by refusing to allow DV registrations for the reason "*[we believe that the drawbacks of issuing domain validated certificates far outweigh the benefits](https://goo.gl/Wfgsx4)*". – Pacerier Apr 12 '16 at 13:23
  • 1
    @Pacerier Yes, that's quite possible. It's true there can be issues with DV certs, but the vested interest these CAs have in selling you more expensive EV certs, along with the fact that they've somehow managed to get themselves hard-coded in the browser's code makes them clearly biased unfortunately. – Bruno Apr 12 '16 at 13:28
  • Besides this DV/OV/EV issue, some CAs also seem to maintain some technical confusion around what they're promoting and what actually enforces security, for example [RapidSSL's FAQ](https://www.rapidssl.com/learn-ssl/ssl-faq/) "*the encryption level is determined by the capability of the [...] SSL certificate, [...]*", which is obvioulsy [not quite true](http://security.stackexchange.com/a/19555/2435) (assuming you have a cert with the right key type anyway, but that's easy enough). – Bruno Apr 12 '16 at 13:29
  • @Bruno, From their collective profits, we can see that the [confusopoly](https://en.wikipedia.org/wiki/Confusopoly) is working very well indeed. This kind of double-language ambiguity and [lack of consistency](https://en.wikipedia.org/wiki/Consumer_confusion#Lack_of_consistency) gives the CAs a lot of plausible deniability. At least those CAs founded/controlled by real coders/developers will ***try*** to justify their stance with *some* information and data, for example https://certsimple.com/blog/domain-validated-ssl-google-com-mg – Pacerier Apr 12 '16 at 13:36
  • @Bruno: while it may be confusing, their claim is not strictly speaking incorrect. There are several SSL key types: RSA, DSA, ECDSA, Ed25519, and a few others. The [key type determines what ciphersuite are available](https://pjklauser.wordpress.com/2013/10/29/how-are-tls-cipher-choices-affected-by-certificate-key-types/). – Lie Ryan Apr 12 '16 at 16:56
  • @LieRyan, indeed, that's why I linked to [this answer I wrote a while ago](http://security.stackexchange.com/questions/19473/understanding-2048-bit-ssl-and-256-bit-encryption/19555#19555) too. The main problem is that they mix all this explanation with the number of bits used for the encryption... (and it looks like this particular CA only offers RSA certs according to its CSR guide and other documents). I think what Pacerier and I were talking about was the fact that this overall confusion was often misleading and unhealthy. – Bruno Apr 12 '16 at 17:07
21

The important point is that the (only) purpose of the SSL certificate is to verify the identity of the server you're communicating with.

Everything about the encryption and security of the connection is negotiated between the browser and server independent of the certificate. As long as the key embedded in the certificate is large enough and not compromised, your connection is equally secure with a free certificate as with a $2000 certificate.

The price of the certificate reflects (or at least should reflect) the amount of vetting the issuing company has done to verify that you should be allowed to have that certificate.

EDIT

Certificates are about trust rather than security. It's a subtle distinction, but an important one. I am perfectly secure with a self-signed certificate as long as I can verify the key. In that case, an EV certificate offers absolutely no more protection for me even to the slightest degree. But what about other people? I know ahead of time which key to trust, but they do not. That's the role of a CA.

All publicly-trusted CAs require you to verify ownership of your domain before issuing a certificate, so in that sense a $2000 Verisign certificate is equal to a free Startcom certificate. But that's only half the story.

Remember the curious case of Mountain America Credit Union? Attackers were able to pose as a bank and get an SSL certificate from Equifax, an official seal from the issuing company, a ChoicePoint indicator verifying the location (and presumed legitimacy) of the company -- all totally clean, legit, and properly issued. Their secret? The bank uses the domain name macu.com, while these attackers used the name mountain-america.net. When they applied for the certificate, they did NOT say that they were a bank (that would have raised red flags), but instead put up a totally innocent-looking site. It could have been for something like hiking boots or bottled water or a blog about living in the mountains. Who knows. But they changed it to duplicate the Credit Union site after the credentials had been issued.

Theoretically, this is exactly the sort of attack that EV certification is supposed to guard against. It should be much harder to get an EV certificate using a false identity or based on a nonexistent company. Probably not impossible, but theoretically more difficult. So presumably if it turns out to be a fraud, at least you have the address of the perpetrator.. or so you hope.

The thing is, when you're selling trust at a large scale it's difficult to keep your product clean. Breaches like the Mountain America fiasco happen, even with all the vetting and examination you can summon, because once the certificate is issued, the user can change his story.

Possibly the most important security feature of a $2000 certificate is the price itself. It says, "this person paid $2000 for this certificate". Presumably someone who intends to use it for evil would opt for a cheaper alternative instead. It's a bit silly, but probably also correct.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 3
    While I mostly agree with your answer, you seem to be downplaying the role of certificates and authentication. "*As long as the key embedded in the certificate is large enough and not compromised, your connection is equally secure with a free certificate as with a $2000 certificate.*". Security isn't just about the encryption strength: you need both good encryption and good remote party authentication. The latter is what certificates are for. There is no point exchanging data using the best encryption scheme ever if you don't check who you're exchanging this data with in the first place. – Bruno Jun 26 '12 at 12:13
  • @Bruno added add'l explanation – tylerl Jun 27 '12 at 00:39
  • 3
    I agree with "*I am perfectly secure with a self-signed certificate as long as I can verify the key.*", but disagree (partly) with "*Certificates are about trust rather than security. It's a subtle distinction, but an important one.*": certificates are indeed about trust, but trust is an inherent part of security. The fact that you can be perfectly secure indeed with a self-signed cert or a cert from your own CA relies on the fact that you establish trust in your certificate yourself. For security, you need both to trust the cert (via a CA or manually) and to have encryption. – Bruno Jun 27 '12 at 00:51
  • 1
    "_I am perfectly secure with a self-signed certificate **as long as I can verify the key**._" Last I went to a bank agency, no one was able to either give me the fingerprint of the certificate or even confirm which CA they use. – curiousguy Jun 27 '12 at 02:29
  • @Bruno I'm intentionally separating out trust from the technical security (i.e. encryption, etc.) specifically for the purpose of explaining that the certificate itself does not play any technical role in the mechanics of how the connection security works. Of course trust is a security factor, which is where the rest of the post factors in. – tylerl Jun 27 '12 at 07:00
  • @curiousguy you can verify the key of your own self-signed certificates, which is what that statement refers to. Also, I call shenanigans on your story about attempting to get cert fingerprint for your bank. – tylerl Jun 27 '12 at 07:02
  • 2
    @tylerl "_Also, I call shenanigans on your story about attempting to get cert fingerprint for your bank._" how much you bet? – curiousguy Jun 27 '12 at 09:03
  • 1
    @tylerl "*I'm intentionally separating out trust from the technical security*". That's what I think is a mistake. Security isn't solely about its technical features: administration and usability (and social aspects) are also core aspects of a security system. It needs to be looked at as a whole. Security systems are only as strong as their weakest links. (In addition, when CAs are used, certificate and identity verification can be quite technical, see RFC 5280/6125.) – Bruno Jun 27 '12 at 17:56
  • 1
    @curiousguy, Even if the employee gives you that, it doesn't mean that it's trusted. Employees often get things wrong. – Pacerier Apr 12 '16 at 13:10
3

Mainly There are 3 types of SSL Certificates:

(1) Domain Validation SSL Certificates

  • It has a less rigorous validation procedure.
  • Only the applicant's name and contact information are checked and verified with the data that was entered during registration.
  • The legitimate factor is not checked, and therefore, this is excellent for online sites or businesses who do not transfer or deal with very sensitive data.
  • It is tied directly to the domain name, thus it assures users about the authenticity of the website; however, it does not encourage browser warnings.

(2) Extended Validation SSL Certificate

  • Launched in 2007, it is one of the first protocols to stringently follow industry guidelines.
  • The certification application and validation process are extremely rigorous.
  • Each and every business credential is carefully and minutely verified.
  • For sites using this protocol, a way to ensure if the site is protected or not is to check the browser navigation window. It turns green if the site is safe, and turns red at the onset of danger.
  • It helps maintain a high assurance standard, and verifies the authenticity of the business.

(3) Organizational Validation SSL Certificate

  • The legitimacy of the applicant's business is checked.
  • It follows a strict validation procedure, and verifies practically all the information of the business.
  • It is an excellent option for online businesses dealing with extremely confidential information.

(Source: Buzzle)

Nathan Tuggy
  • 118
  • 1
  • 1
  • 6
0

There are two sides to this debate.

First is how far a CA will go in assuring you are actually who you claim to be.

Second is how many of the more advanced features a CA supports.

Both are important... a CA that will give you a cert with all the newest features but wont check your id is useless as is one who will check you out well but only issue a cert with features that were obsolete 5 years ago.

Mr. C
  • 131
  • 1
  • This is quite obsolete info. Now that ICANN is forcing registars to keep info about domains CAs like *let's encrypt* can allow you to add a certificate directly to the domain simply by proving that you can run a program behind that domain. And that (in theory) should be good enough since it is a domain owner's responsibility that his server is hardened and a registar's responsibility that its servers are not compromised. – grochmal Jan 16 '17 at 01:12
  • As long as you keep it low key you can still register and keep a domain under totally false info and get a perfectly valid cert for it. If you use if for some big scam it wont last but if you use for something nobody will notice or care about you can keep it indefinitely. – Mr. C Jan 16 '17 at 09:58