Why do I need to purchase an SSL certificate when I can generate one locally?
Solution 1:
One word - trust. The SSL certificate from a provider that your browser trusts means that they have at least done basic verification to say that you are who you say you are.
Otherwise I could make my own certificates for google.com or yourbank.com and pretend to be them.
Paid certificates do not provide any extra level of encryption over self signed (usually). But a self signed certificate will cause the browser to throw an error.
Yes parts of SSL are a scam (a verisign certificate vs a geotrust where verisign are up to 100x more expensive) but not all of it.
If this is all internal stuff, then there is no need for a paid certificate as you can employ your own trust methods (e.g. Do nothing, or perhaps just fingerprint checking).
Solution 2:
The whole point of an SSL certificate is so that the browser has a reasonable degree of trust in the server's public key for HTTPS transactions.
First, let's explore what would happen if we didn't use certificates. Instead, the server would send over the public key in plaintext and the browser would initiate encrypted communication using it (the first thing it would do would be to encrypt its own public key and securely send it over). What if I, and attacker, wedged myself in the middle? I could replace your public key on the fly with mine, have an encrypted connection with the browser, decrypt all the stuff I receive, encrypt it with your public key, and send it over (and vice versa for response-type traffic). No party would notice the difference, as nobody knew the public keys beforehand.
OK, so we have established that we need some way for the browser to trust my public key. One way to do this would be to store all registered public keys in the browser. Of course, this would require an update every time someone registered a public key,and this would lead to bloat. One could also keep public keys in the hands of DNS servers1, but DNS servers can be spoofed as well and DNS isn't a secure protocol.
So the only option left is to "chain" trust through a signing mechanism. The browser stores the details of a few CAs, and your certificate will be sent along with a chain of other certificates, each one signing the next and going up to the root/trusted/in built CA. It is the job of the CA to make sure that the domain belongs to you before signing a certificate for you.
Since being a CA is a business, they charge for this. Some more than others.
If you made your own certificate, you would get an error similar to:
There's no value to an unsigned certificate. It's like taking a pencil and a booklet, an drawing a passport that claims that you are Barack Obama. Nobody will trust it.
1. After all, your DNS entry is created when you register a domain. Using a more robust protocol that lets you simultaneously register public keys would be an interesting concept.
Solution 3:
The answer to your question depends on your audience: Since the whole system of certificates is based on "trust", your users must have the availability to proof your certificates themselves or trust a 3rd party that has done this checks and shows the success by signing your certificate. The term "to proof your certificates" I used is a bit inaccurate: the long version should be: "to proof that you are the owner of the certificate and are allowed to use it".
If all your users know you in personal and have the technical ability to proof that your certificate has been issued by yourself, there is no technical need to use a certificate from a "certified" provider. In this case, the self-signed certificate might even be better than one from one of there providers.
But in most cases, there is no possibility for the users to do this process by themselves. Here, those SSL providers come into market. They offer the service to do these checks and express the result of the checks by signing the certificate. But one important fact to have in mind is: By signing a certificate, a SSL-provider expresses that it has checked the certificate issuers identity according to its own signing policy. So the user has to decide if this policy is precise enough and if he/she can trust the provider.
Solution 4:
The main point is, if the cert is self generate, the common users have no way to verify its truthfulness. For a purchased cert, they suppose to at least verified what is print inside the certificate is correct. Idea: if you put your phone and address in the cert, the CA suppose to verify it, but they seldom do.
In additional, purchase certificate are traceable, that means they user can always trace where did the cert comes from, while a self-signed cert is only an random identity.
To many system, "code-signing" was required to from an authorized CA in the past, which is policy driven, but since self-signed cert are so numerous, it is no longer 100% enforce now.
Solution 5:
There is no technical difference (your own ones are not less secure) just an organizational one: Your CA's certificate is not part of the browsers standard installation. This makes it uncomfortable for most people to connect to your certificate. But it would not make sense to buy a certificate for an internal network.