Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am a newbie in this field. I am confused with why SSL certificates cannot be free of charge. In my understanding the certificate is just a text file consisting of cryptic numbers installed on a server. What do the SSL certificates cost?

share|improve this question
You can get free class 1 certificates at startssl.com (they can be used for SSL). –  Rob W Nov 14 '13 at 21:01
They can be free of charge. See startssl.com or cacert.org (I have no affiliation with either) –  ruief Nov 15 '13 at 13:05
Your question shows no prior research. "Cryptic numbers" are you kidding? Downvoting. –  ruief Nov 15 '13 at 13:05
@ruief - for someone knew to the field, understanding what a certificate is is non-trivial. He at least understood there was some secret and understood that there isn't a real cost associated with creating the secret. He has a valid question that many people have a hard time understanding if they aren't already pretty familiar with SSL. Sure it shows a lack of knowledge of how SSL works, but the question isn't about how SSL works, it's about why it has a cost in most cases. –  AJ Henderson Nov 15 '13 at 20:47
With SRP, you won't need any certificates after account creation. –  Smit Johnth Nov 26 '13 at 7:58

3 Answers 3

up vote 17 down vote accepted

SSL certificates provide two things, encryption and authentication. For encryption, any SSL certificate will do. You can use a self-signed certificate which you can make free of charge and it will provide encrypted communication between your server and a client.

The problem is that since it lacks any authentication, an attacker could simply make their own certificate and claim to be the server you want to connect to. Your browser wouldn't know the difference and would connect to the attacker with an encrypted connection and the attacker could then attach to the real server and monitor all your communication.

To avoid this problem, SSL certificates also need to provide authentication and that means that someone has to verify domain ownership and identity information. The policies have to be administered and systems have to be run to handle dealing with lost keys. Relationships also have to be built with browser makers to get the root keys for the certificate authorities in to the applications. This all has costs and so those costs are passed on to those who buy SSL certificates from a Certificate Authority.

In exchange for that cost, the CA verifies the identity of the organization and domain that they are issuing the certificate to. Now back in our original case, the attacker may be able to get between the client and the server, but they can't get the client to connect to their SSL certificate since it isn't trusted and if the client connects with the real SSL certificate, then the encryption kicks in blocking the attacker from being able to monitor what is happening.

share|improve this answer
Could you pleae elaborate more about how the three parties (client, real server, and CA server) communicate during the transmission? –  kiss my armpit Nov 14 '13 at 20:09
The communication is primarily between the client and server. The server provides the certificate to the client, the client sees that the public certificate is signed by a CA that it trusts (because it has the CA's public certificate pre-installed as trusted). The client then may or may not check a revocation list (hosted by the CA) to make sure the certificate hasn't been lost. The client can then make an encryption key for the session and encrypt it with the public key of the server. The client can then send the encrypted key to the server and only the proper server can decrypt it. –  AJ Henderson Nov 14 '13 at 20:12
That shared key is then used for communication during the SSL session. –  AJ Henderson Nov 14 '13 at 20:13
When a bad person interrupts my request to CA for checking a revocation list, is it still safe? –  kiss my armpit Nov 14 '13 at 20:15
@DonutE.Knot - as long as the certificate has not been revoked it is safe. If they are able to compromise the private key on the server and also compromise the revocation list on the CA then there are bigger problems (for example, they could just issue another certificate with the CA's system). This has happened on a few occasions with poorly run CAs. Technically, if they are only able to block access to the revocation list, then the client is supposed to reject the certificate and the revocation list should be signed by the CA's private key, so it can't be faked without compromising the CA –  AJ Henderson Nov 14 '13 at 20:17

You can certainly generate your own SSL certificate. Charges are not for the generation of them; rather the fee is for someone else to say they trust your certificate.

Presentation of a cert doesn't mean anything, it's the chain of trust associated with it that has meaning. You don't know me, and if I gave you a cert that said I'm Bob Smith of www.google.com, you would either trust me (fool!) or not. If I gave you a similar cert that carried the trust of, say, Verisign, if you trust them then you would extend that trust to me. Verisign isn't going to do that for free since they have administrative requirements before they'll trust me enough to relay that trust to you.

share|improve this answer
Can I just trust the url? If Bob Smith met me in a real life and he gave me the url www.google.com, is it enough to trust him by browsing https://google.com? –  kiss my armpit Nov 14 '13 at 19:41
Typically you would configure a client (browser, or other app that uses certificates) to trust certificates that have been signed by root entities that you trust. Often in these apps, if they receive a cert they don't trust due to that, they'll ask the user if it should be trusted (just this once, or forever)… so you would have to make your own judgement call. –  mah Nov 14 '13 at 19:44
@DonutE.Knot - the problem is how do you tell you are actually getting to google.com and not my server that I have snuck in-between your computer and google.com and have maliciously claimed is google.com. Unless some third party verifies the certificate, you have no idea if the url you entered is actually the site you intended to get to. That is the entire point of SSL certificates being signed by a certificate authority. –  AJ Henderson Nov 14 '13 at 19:55
Sorry. So does it imply that the url to which I want to visit cannot be redirected to a fake server by a bad person during the transmission? –  kiss my armpit Nov 14 '13 at 19:56
@DonutE.Knot - correct, the SSL certificate verifies to the client that the connection comes from a server which has the private key and the CA will only give the private key to a server that can verify it belongs to the company that has the domain. If someone tried to redirect, they would need to be able to use the private key for a trusted certificate that says they are that URL and company, but since they don't have that, your browser would reject it. –  AJ Henderson Nov 14 '13 at 19:57

There are not many free things in this world.

If you want to use SSL publicly and you want the browser to display a trusted status for a root CA cert then you will need to use a trusted CA to sign your cert. This is where VeriSign, Go Daddy etc come in. IT is quite expensive to maintain a Trusted Root Cert Authority. You need infrastructure, auditing, staff, etc to provide certs then you need to pay browsers vendors to store them in the browser, around $250K for IE for example although that number was a while ago.

If your SSL certs are internally facing then, you can create your own CA, create your own certs using OpenSSL and then push them out to your corporate users. This is much cheaper but not exactly free as you still need infrastructure, staff etc to maintain it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.