Take the 2-minute tour ×

A friend of mine asked me why we pay so much for SSL certificates if everyone could theoretically issue one. Why indeed? And how do we judge if the little lock in the browser is really trustworthy?

share|improve this question

9 Answers 9

up vote 23 down vote accepted

Certificates are cryptographically signed by something called a Certificate Authority(CA), and each browser has a list of CAs it implicitly trusts. These CAs are entities that have a set of cryptographic keys that can be used to sign any certificate, often for a fee. Any certificate signed by a CA in the trusted list will give a lock on a browser, because it's proven to be "trusted" and belongs to that domain.

You can self-sign a certificate, but the browser will warn you that the signer is not trusted, either by showing a big error box before allowing you in, or showing a broken lock icon.

In addition, even a trusted certificate will give an error if it's used for the wrong domain, or is modified to include another domain. This is ensured because the certificate includes the domains it is allowed to be used for, and it also has a cryptographic checksum/fingerprint that ensures its integrity.

This is not 100% safe at the moment, as there is the possibility to fake CA certificates that use MD5, see this link: http://www.phreedom.org/research/rogue-ca/. Though it has to be noted that this is pretty hard, as they exploited a weakness in an already existing CA, which may or may not have been closed by now.

In essence, we trust the certificates as much as we trust that our browser providers know how to select "proper" CAs. Those CAs are only trusted on virtue of their reputation, as a single misstep theoretically would be a very heavy blow on their trustworthiness if detected.

share|improve this answer
Possible, but still extremely difficult. They exploited the fact that their SSL issuer was using sequential ID's on the certs it issued, and thankfully most don't do that. It also took 2 weeks of cranking on a ton of PS3's to generate the collision, and it took 4 tries before they got lucky. –  Bob Somers Feb 25 '09 at 8:27
I'll clarify that it's hard, but it's noteworthy that it HAS been done. =) –  Daniel Bruce Feb 25 '09 at 8:31
I heard it's much more possible to fake the whole certificate chain. For someone controlling the uplink (e.g. for business building admin) it's not hard to make a fake distribution of Firefox (for instance) with generated fake Root CAs for it, and then divert HTTP traffic to this fake distribution. As the result, user starts with a browser with fake Root CA. Any time a SSL session is initiated, the certificates should be replaced (even generated on the fly) if the request comes from a faked client. Having all the private keys admin can monitor the whole traffic. –  Vladimir Dyuzhev Jun 1 '09 at 13:35
@Vladimir Dyuzhev - fyi: The "fake root" SSL keys happen all the time whenever a browser (or WebHTTP Client) is behind an SSL proxy. These certs should not be replaced on the fly as you say because that will break SSL proxing. Yes, the admin can see your SSL traffic. And in corporations, the HR department can see it too. Just stating a fact, not taking sides on if the practice is good –  makerofthings7 Oct 13 '10 at 2:27

The whole CA business is amazing. I've purchased a couple of certificates from rapidssl.com, and all the "proof" they required was:

  1. I could receive mail to the domain.
  2. I could answer my phone.

That was it. Keep in mind, when trusting the little locks in the browser.

share|improve this answer
Just FYI, RapidSSL was the CA that was exploited in the MD5/SSL attack. They were chosen because they issue certs with predictable, sequential ID's. –  Bob Somers Feb 25 '09 at 8:30
Thanks for the info. I chose them because they were relatively inexpensive. Luckily I'm not running any banking-level stuff, just wanted to keep the browser quiet while using ssl. –  Joonas Pulakka Feb 25 '09 at 8:34
There's a reason RapidSSL's root certificate is removed from my browser - I simply don't trust them. –  MSalters Feb 25 '09 at 8:57
Well, other Root CAs are not much different. –  Vladimir Dyuzhev Jun 1 '09 at 13:38

First, some background on strong public/private key cryptography, which SSL is based on:

A key has two parts, the private part and the public part. The public key can be used to encrypt material that requires the private key to decrypt. This allows the use of open communication channels to communicate securely.

One important aspect of public/private key cryptography is that the private key can be used to digitally sign a message which can be verified using the public key. This gives the receiver of a message the ability to verify concretely that the message they received was sent by the sender (the holder of the key).

The key to SSL certificates is that encryption keys themselves can be digitally signed.

A "certificate" is composed of a private/public key pair as well as digitally signed data. When someone buys an SSL certificate they generate a private/public key and submit the public key to a Certification Authority (CA) to be signed. The CA performs an appropriate level of due diligence on the buyer of the SSL certificate and signs the certificate with their private key. The SSL certificate will be bound to a particular website or set of websites and is essentially the CA indicating that they trust the owner of the private key of the certificate to be the proper owner of those websites.

The root certificates (public keys and other meta-data) for trusted CAs are included by default in major shipping browsers and operating systems (in windows, type "certmgr.msc" into a run prompt to see the certificate manager). When you connect to a web server using SSL the server will send you its SSL certificate including the public key and other meta data, all of which is signed by the CA. Your browser is able to verify the validity of the certificate, through the signature and the preloaded root certificates. This creates a chain of trust between the CA and the web server you are connecting to.

share|improve this answer

Because we have to trust someone.

Trusted SSL certificates have signatures of trusted authorities. For example, VeriSign has a deal with Microsoft, that their certificate is built in your browser. So you can trust every page with a VeriSign trusted certificate.

This graphic really picks the point:


  • RA = Registration Authority
  • CA = Certification Authority
  • VA = Validation Authority

Rough outline: A user applies for a certificate with his public key at a registration authority (RA). The latter confirms the user's identity to the certification authority (CA) which in turn issues the certificate. The user can then digitally sign a contract using his new certificate. His identity is then checked by the contracting party with a validation authority (VA) which again receives information about issued certificates by the certification authority.

share|improve this answer
Nice picture, but without some explanation it loses much of its purpose. –  tehvan Feb 25 '09 at 8:25

If you are not using one of the accepted CAs people will get a message box when accessing the site talking about an untrusted certificate. That won't help to generate traffic to the site.

The lock only means that the site owner showed a CA some kind of proof that he really is who he claims to be. You must judge on your own if you trust that person/site.

It's like a stranger showing you a photo ID. Do you trust him more because you know for sure his name is John Doe? Probably not.

But when people you trust told you: "John Doe" is a good guy. The proof that the guy in front of you actually IS "John Doe", than you might choose to trust him as well.

share|improve this answer

Why? Because you're paying to ride along on someone elses reputation.... to vouch for you.

Its all about whose validating your claim to be you. Despite some of the documentaries Ive watched lately, and the recession, I'm still more likely to believe corporate America when they confirm your identity to me, than I am the Russian mafia. Even though both can just as easily issue certificates.

The amount you pay is basically just (how much it costs them to secure that reputation and/or suppress any security breaches) + (however much they can afford to gouge the market as a margin %).

Now the barriers to entry are quite high, cos its really expensive to earn that trust, so theres not a lot of competition. Therefore chances are the price isn't going to fall anytime soon.... unless Sony or GE etc decide to play.

share|improve this answer

Certificates are built on a chain of trust, and if let anyone be a signing authority, we would be implicitly trusting everyone. It's a bit scary today though, since there are over 200 so called "trusted authorities" whose certs are built into your browser!

There is one free CA that I know of though: StartCom. They issue free SSL certs, but they are only accepted in Firefox, not IE. (Not sure about Safari or Opera).

share|improve this answer

You pay for a certificate so that when you go HTTPS (which you should for anything a little sensitive) your clients don’t get big warnings and go call your support saying that you have infected them & al…

Very little security, lot of FUD.

If you have the possibility of giving your clients your own certificate directly, do it. But it is a rare case.

share|improve this answer

The other answers have explained the CA-system. The perspectives project aims to deploy a new approach to SSL, where you can choose whom to trust: http://perspectives-project.org/

share|improve this answer

Your Answer


