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?
17In terms of the CIA triad for information security, self-signed certs provide confidentiality and integrity (i.e., they allow encrypted messages between two parties), but only certs signed by a trusted source provide authenticity (i.e., the other party in your encrypted conversation is actually who you think it is).– apsillersApr 29, 2013 at 13:21
10Hopefully, when DNSSEC comes into play, people would be able to create their own certificate and store it in a DNS record. The DNSSEC chain of trust would then be enough to prove that the cert belongs to the domain's owner. (I don't think this is a formalised specification (yet), but it would be nice)– jackweirdyApr 29, 2013 at 14:08
2For internal use you can deploy the certificate as trusted using Group Policy (on windows).– BenApr 29, 2013 at 21:20
4I often wonder why people dont accept my own printed money too ;)– tgkprogMay 22, 2013 at 12:42
1Note: There are free basic certificate provider(s). 90% of people's needs can be fulfilled by these. And some CA's have very low cost certificates, no reason to break the bank no-matter what you need. (short of a delegation of course)– Chris SMay 28, 2013 at 19:01
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).
8If it is all internal stuff you can deploy your certificate as trusted using group policy.– BenApr 29, 2013 at 21:19
2On the other hand, driver signing is a bit of a scam. For what it is, yes it's a huge ripoff, but we don't have a choice. successfulsoftware.net/2008/02/27/…– hookenzApr 30, 2013 at 4:07
2@Matt - I've read that article before; when we were looking at doing code signing at work. We decided to just self-sign and advise people to check the signatures. Thankfully we have very high tech users (mostly). Apr 30, 2013 at 8:24
And self signed certs generate warnings in all browsers. While certs from providers can be verified by all major browsers because they have the public keys of those providers built in and can verify your certs and confirm that they were indeed signed by the provider.– hookenzMar 17, 2014 at 6:57
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.
You could also use DNSSEC stapling for your SSL certificate, so the certificate derives (ultimately) from ICANN as CA, rather than from a another certification authority. None of the current browsers support this, though Chrome used to. Jun 27, 2014 at 9:52
And nowadays you have DANE and its DNS TLSA records which allows you to limit certain services to specific keys or specific CAs. Apr 18, 2019 at 21:13
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 the 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!".
2This is correct, but it's still worth noting that paid-certs are only proof that someone went through the trouble of paying money to a cert authority. The sales folks on the other side of Verisign/Namecheap/Whatever-CA aren't going to do anything more than only send a cert to firstname.lastname@example.org (e.g. they'll send one to a exqmple.org potential phishing site). Apr 29, 2013 at 15:19
1@tristan Quite true, they could use better formal procedures for this sort of thing but I guess the logistical requirements would be unreasonable.– ThomasApr 29, 2013 at 15:20
1@tristan - it's an imperfect system, but cert authorities have some incentive to be trustworthy. Eg if they gave a random person a Google cert, they'd be removed from all browsers in short order. They also offer "extended validation" certs which, in theory, mean they do more checking. Any of them could decide that this requires in-person DNA tests if they thought it would bolster their reputation and earn them business. Apr 29, 2013 at 17:12
1@NathanLong It's not about giving a 'Google cert' to some unscrupulous chap, it's that even EV cert is still just a "someone can respond to e-mails from this domain" check. Anyway, we're circling the same points of: a) users still need to know to not give money to payqal.com, b) the cost barrier for SSL is not worth it for some scammers, c) paid certs mean that it's more likely that a site is likely to be the DNS lookup one wanted, and d) it's a reasonable approach to providing the seed value in the scenario of "this server is owned by the same/different people than last time you checked" Apr 29, 2013 at 17:36
Tristan, that is part of the cost. Very inexpensive certs do very inexpensive validation. Very expensive certs (enterprise level) can do very expensive validation. (although price is by no means a direct indicator of how good a job of validation was done) Some certs give an absolute guarantee of who you are but most just guarantee that you have some sort of control over the domain they are issued to...– user277984Mar 24, 2015 at 13:26
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.)
Would you trust someone that says "Trust Me"? Confidence in authenticity can only be provided by a "Trusted Authority", that everyone trust. This is why we have to pony up the big bucks for the certs.
2According to that logic there'd be no free certificate providers. But there are.– Chris SMay 28, 2013 at 19:10