Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
14  
In 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). –  apsillers Apr 29 '13 at 13:21
8  
Hopefully, 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) –  jackweirdy Apr 29 '13 at 14:08
2  
For internal use you can deploy the certificate as trusted using Group Policy (on windows). –  Ben Apr 29 '13 at 21:20
3  
I often wonder why people dont accept my own printed money too ;) –  tgkprog May 22 '13 at 12:42
1  
Note: 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 S May 28 '13 at 19:01

9 Answers 9

up vote 59 down vote accepted

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).

share|improve this answer
7  
If it is all internal stuff you can deploy your certificate as trusted using group policy. –  Ben Apr 29 '13 at 21:19
2  
On 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/… –  Matt Apr 30 '13 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). –  Mark Henderson Apr 30 '13 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. –  Matt Mar 17 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:

enter link description here

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.

share|improve this answer
    
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. –  Richard Gadsden Jun 27 at 9:52

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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?

share|improve this answer

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!".

share|improve this answer
2  
This 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 hostmaster@example.org (e.g. they'll send one to a exqmple.org potential phishing site). –  tristan Apr 29 '13 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. –  Thomas Apr 29 '13 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. –  Nathan Long Apr 29 '13 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" –  tristan Apr 29 '13 at 17:36

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.

share|improve this answer

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.

share|improve this answer
2  
According to that logic there'd be no free certificate providers. But there are. –  Chris S May 28 '13 at 19:10

Your Answer

 
discard

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.