I am having trouble understanding why we need to purchase SSL certificates when we can generate them locally using openSSL. What is the difference between the certificate I purchase and a test certificate I generate locally? Is it just a big scam?
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).
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.
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.
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.
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.
It comes down to trust. A "certified" SSL provider is supposedly reputable (though this can be manipulated) versus a self-signed cert from the server itself.
If your organisation has it's own certificate signing then this is perfectly acceptable and should not cause any warning for users (providing that they are using your cert keychain as a trusted source) but will still create a warning if you try to use it externally.
Bottom-line: for internal use it is fine, if you are providing it externally to a paying customer, having no warnings is peace-of-mind. Would you feel safer having your financial transactions going via an accredited source, or some guy standing on the street you don't really know?
Recently, LetsEncrypt has announced the availability of their command line tools to generate valid certificates.
No validation emails, no complicated configuration editing, no expired certificates breaking your website. And of course, because Let’s Encrypt provides certificates for free, no need to arrange payment.
For those wondering if those certificates are valid in major browsers, the answer is Yes:
On October 19, 2015, the intermediate certificates became cross-signed by IdenTrust, causing all certificates issued by Let's Encrypt to be trusted by all major browsers.
..... On March 8, 2016, Let's Encrypt issued its millionth certificate after seven months of existence.
On April 12, 2016, Let's Encrypt left Beta.
Link for system admin and developers: https://letsencrypt.org/getting-started/
In the age of blockchain technology and the elimination of third party trust systems, it was about time the issuance of expensive certificates by a few chosen authorities starts to be questioned.
Though Letsencrypt has nothing to do with blockchain technology, it's a start in the right direction. The need to pay a high fee every year to an expensive Certificate Authority is hopefully coming to a logical end.
Simply put, a self-signed SSL certificate doesn't mean anything. It has no value to the external world. It's like saying "I own Spain". You might honestly think you do, but nobody is going to recognize your claim.
A similar analogy would be inventing something and then claiming you own the rights to the invention, but unless you registered a patent at the office, it's going to be hard to take your word for it, now is it?
The whole point of a certificate is that it is signed by an authority people trust. If some website has a valid SSL certificate, it means the owner has gone to the trouble of registering his website, paying for the SSL certificate, and gotten official certification from some real-world certificate authority, so it's likely not a cheap phishing website. On the other hand, if you trust self-signed certificates, then said phishing website could simply generate his own forged certificate (which you will happily accept) and voila.
Of course, if this is an internal network on a private intranet, then you probably trust one another already so in this case an authoritative certificate doesn't really add anything, so you can safely ignore the bright red lights your browser will throw at you. Same for small websites where you still want client-server traffic to be encrypted but your threat model doesn't warrant for strong authentication, in which case you can get by with a self-signed certificate and accept the (negligible by your threat model) risk of an MITM.
Which is probably satisfactory considering how expensive trusted SSL certificates can be.
In other words, a self-signed certificate amounts to saying "I certify I am who I am - trust me!".
To keep it short and simple... and dismistify a little what was said...
It's not the Encryption issue, with proper tools you can generate a certificate locally with the type of encryption you want... and get a valid certificate.
The main advantage you have when buying a certificate from a certification entity is that during the period the certificate is valid they hold in their servers a mechanism for validating anything you signed with your certification online...
Your PC's do not need to be connected for your digital products to be verified and validated with your certificate... you should redirect the validation to the certification entity.
Sorry to come in on this discussion so late - I thought it was worth pointing out that using openssl, it is possible to set up a private CA, with its own root certificate, and then to create server certificates signed by this CA. Provided that the CA root certificate is imported into the browser, and the browser is told to accept it, the server certificate will be accepted without comment. (Obviously this is only a viable option if the user community is small, and the users all know each other personally.)