What kinds of SSL certificates are usable for encryption?

Question

I know that Verizon SSL certificates cost close to $600. There are couple of cheap alternatives, but I never really understood why Verizon does not offer such certificates. Look for RapidSSL at nameCheap. They don't say anything about encryption for the $20 plan.

Assuming the above does not provide encryption: Does manually generating an SSL certificate provide mutual encryption?

I see couple of questions on SSL certificates, but looks like none of them answers my question:

• Does an established SSL connection mean a line is really secure?
• Does it matter which Certificate Authority I source my SSL Certificate from?

Avid's answer to the first question sounded a little complicated for me for who has no background on SSL certificates.

Answer 1

Certificates do not provide encryption. Encryption comes from SSL itself. The certificate is about convincing the client that the data it dutifully encrypts is really sent to the genuine intended server, and not somebody else impersonating the server. A certificate for a SSL server can use a key which works only for digital signatures (e.g. a DSA key) and the data will still be encrypted.

The price of a certificate, from a commercial CA, is driven by the following tendencies:

• The CA is supposed to perform more or less thorough checks on the identity of who buys the certificate. That's the whole and only point of the CA: to link a "physical identity" with a public key. Such verifications imply human labour, and that can be expensive.

• The CA has insurances. When you buy the certificate, the CA becomes liable for security trouble which may emerge from the CA not following the intended verification procedures, as defined in their "certification policy statement". In short words, when you buy a more expensive certificate, you get the right to sue them for more money.

• Commercial CA will charge you as much as possible. If a CA sells you a 600$ certificate, then this means that they estimated that they would lose too many sells if the price was 650$. The commercial value of a certificate comes from the fact that the CA root key is already known to the SSL client's browser; for Windows / Internet Explorer, the default list of known CA is managed by Microsoft, and they will not include just any CA. Consequently, the CA market is not totally open, and competition fails to lower prices. Right now, SSL certificates tend to be overpriced. For instance, this allowed Thawte founder Mark Shuttleworth to buy a trip into space and then create and fund the Ubuntu Linux distribution -- so one can assume that commercial CA make quite a lot of profit out of each sold certificate.

You can create your own certificates (OpenSSL is a free tool that can do that, for instance; see EJBCA for something with a nicer interface); homemade certificates are often self-signed (in a certificate, there must be a signature from the issuing CA; the format does not allow omitting that signature field; so it is customary to have the certificate "sign itself" in the case of a stand-alone CA-less certificate). The practical consequence of a homemade certificate is that Web browser will display some scary warnings when they encounter them the first time (but users are quite good at ignoring warnings -- which, by the way, is also a problem, generally speaking).

Answer 2

You seem to be a little confused on what SSL actually does. SSL transactions are always encrypted -- always. They don't even exist without encryption. What you want to know about is authentication, which is entirely different. [Update: It's possible to choose a non-encyrpting algorithm.]

Under a normal shopping scenario, say Amazon.com, your connection is encrypted end-to-end. How do you know they are who they say they are? Verisign signed their certificate with their private key. Your browser shipped with the Verisign certificate, so you can know with certainty that the amazon.com you're talking to is the one that Verisign signed. They only know you are who you claim to be because you know your password. So, you know them through a PKI certificate, they know you through a password.

In certain circumstances, both client and server can use PKI certificates to identify themselves. This can be done with a local file, a USB device, or a smart card reader. In that case, you check the clients signature and they check yours.

I suggest getting involved with CAcert. It's a free, community-supported certificate authority. The only downside ( and it can be a big one ) is that they major browsers aren't shipping their root certificate yet. You're free to use it, but you may have to distribute it to your browsers on your own. It's something to at least learn from and think about.

Answer 3

Usually, the certificates are pretty much equivalent - there is a clear standard for cryptographic certificates (X.509), and while there are different "modes" for certificates, they all typically support whatever kind of encryption you want to use.
My admittedly complex answer (because, this is not simple), applies mostly to server configuration. E.g. the cipher suites are configured in the web server (and browser).

The cert is mainly a public key (with associated private key), with additional fields, and a "wrapper" that certifies that someone verified the identity of the cert holder.

(Note that there are encryption algorithms specified in the certificate too, but this applies to the cert' signing and such. )

Please let me know if you need any more info...

Answer 4

RapidSSL will provide encryption as will any SSL cert (it's possible that a server-client connection could end up using null ciphers under some circumstances, but that's not down to the certificate)

Additionally in some environments, self-signed SSL certificates which are free are a perfectly reasonable option.

The difference you're seeing in cost of certificates usually comes down to level of checking that's done by the certificate authority and other "features" provided by the certificate, like what it can be used for and whether it's a wildcard certificate.

Cheaper certificates tend to not involve a lot of checking by the CA that you're actually entitled to a cert for a given domain, with some it can be as little as being able to receive an e-mail to certain pre-specified email addresses at a given domain (eg, ssladmin@domain).

The theory is that the more expensive certificate with more checking is better because users can have more trust that it's legitimate. However hardly any users ever check the certificate issuer, so I'm not sure that's a valid reason.

The primary thing to watch on certificates for public services is that the root certificate used to sign yours is embedded in all the major browsers. If that isn't the case your users will get certificate warnings when connecting to your site which may deter them from using it.

There is one exception to that which is the use of "EV-SSL", which is quite popular with banks and some larger e-commerce sites. an EV cert will provide some visual notification in the browser that it's in use which is designed to make the user feel that there's more trust in that connection.

To get an EV certificate the issuing CA should be doing quite a few checks to ensure that you are the appropriate owner of the certificate, which is one element of why they have a higher cost.