Are there any benefits of a self signed certificate on a live site?

I know in IIS 7 you have the ability to self sign a certificate and I was wondering if using that as a precurser to buying one from a CA would be a good idea.

Do you get the same encryption benefits that you get from a CA signed cert or am I confusing terms? (running off the https protocol)

  • On a side note, you can get a free CA signed ssl cert for a single domain without wildcards from cert.startcom.org.
    – OliverS
    Feb 22, 2010 at 11:25

7 Answers 7


The encryption is not a property of the certificate or where it is signed from. The benefit you get from a CA signed cert is that it is automatically trusted by web browsers (and other SSL-aware applications). A self-signed certificate will pop up a warning that the certificate is not trusted. In more recent browsers, such as FireFox 3, the default action is to refuse to show the page and the user has to take deliberate actions to enable use of a self-signed (or expired, for that matter) certificate.

If you can talk to everyone who will use the web page (if this is for your family only, for example), this isn't a problem. Tell them to expect that warning and how to handle it in their browser and it's a one-time issue.

However, if this is for any use that requires anything approaching real security, you probably want a true, signed, not self-signed certificate.

  • Thanks Eddie. I knew the trust issue was the big one, I was wondering if there was anything else I should be thinking about.
    – Joseph
    Apr 30, 2009 at 16:11

You get the same encryption benefits, but everyone viewing your site will get a warning that your certificate is untrusted (or from an untrusted source). The advantage of getting one of the main stream certs is that they are already in the browser as trusted.

In IE 7, go to Tools, Internet Options, Content, Certificates, Trusted Root Certification Authorities. Those are all the authorities IE trusts by default.


Trust. A self-signed certificate gives the same encryption.

But I trust a CA. I do not trust you.

So why shouldn't I trust you? Because there's no guarantee that the name on the certificate ("Discount Bob's Hanggliding and BBQ Emporium") was the person who actually created the certificate. I could create a certificate that said "Discount Bob's Hanggliding and BBQ Emporium" and when you go to ritter.vg it'd say "Discount Bob's Hanggliding and BBQ Emporium".

But when I ask a CA to sign my certificate that says "Discount Bob's Hanggliding and BBQ Emporium", they'll ask "Sure, show me some credentials" and I don't have any, so they'll tell me to piss off. But the actual Discount Bob will have those credentials, the CA will sign it. So when you see the certificate, signed by the CA, you'll know that it actually is Discount Bob, because if it weren't the CA wouldn't have signed it.

The purpose of a signed certificate is to verify that the person is actually who he says he. Because the CA said he is, and I trust the CA.

The encryption isn't directly relevant to a certificate - it just gets added in because it's good to have and it goes hand in hand.


Pros of self-signed cert:

  • Free
  • Same encryption technology as CA signed


  • Browser will display some form of security warning requiring user interaction to view the site. This can be suppressed by the user choosing to trust the cert.
  • The trust you are implying is against the signer of the cert. Anybody's cert can enable SSL encrypted connections. The trust policy protects the user form man-in-the-middle attacks. No one can issue a signed cert but the CA it came from and only to be used on the server it was created for. Therefore, it's contents cannot come from another source or be modified in transit.

Quick scenario: If someone setup a rogue wifi access point in an internet cafe, it's then possible to transparently proxy victim users' activity and watch it in a network sniffer. Normally, SSL is encrypted and the data is unusable. However, tools exist to proxy the user's HTTPS requests and inspect the victim's content in transit. This has a side effect of giving the affected user an unauthentic cert that is typically not trusted.

If you go to log into your bank's site and get an SSL security warning, DO NOT proceed. You may be a target.

Some might recognize this as the Hak5 Pineapple.

  • Thanks for the scenario. I'm planning on using the self signed cert to test my app on the live system while I prepare it for deployement, so I'm not really worried about any "clients" because it's just me. When I'm ready to deploy I'll have already purchased a signed cert. It's still very useful to know this information, though.
    – Joseph
    Apr 30, 2009 at 16:33
  • I believe this is only possible with the TLS variation of a SSL request. A pure SSL handshake whouldn't reveal any packet content right?
    – djangofan
    Jun 13, 2011 at 18:35
  • Packet contents are always visible, but encrypted by a key that is randomly selected and exchanged during handshake. This is true for all SSL/TLS versions.
    – spoulson
    Jul 8, 2011 at 3:21

Since you asked specifically for the benefits of a self-signed cert, I suppose the "benefits" would be that it's cheap (ie free) and quicker to set up initially. These are obviously far outweighed by the negatives of all of your site visitors having to add an exception to their browsers' security policies to allow them to view your site.

If you haven't listened to them already, you may find some of the past Security Now Podcasts of interest - SSL is discussed at length in a number of episodes.


You're confusing encryption with authentication.

Any cert will provide encryption.

A CA cert also proves that CA is vouching that you are who you say you are.

A self-signed cert provides encryption but not authentication.

  • I was under the assumption that a CA provides authentication, but that using the https protocol encrypts your pay load. However, in order to use the https protocol, don't you have to have a cert?
    – Joseph
    Apr 30, 2009 at 16:04
  • Yes, the way TLS (aka SSL) is implemented you need a cert. But that's a requirement of the protocol, NOT a requirement in theory. I could communicate with anyone and at the beginning we'd negotiate how we're going to encrypt, and what keys. But I wouldn't know that I'm talking to Bob and not someone pretending to be Bob.
    – Tom Ritter
    Apr 30, 2009 at 16:10
  • I understand, you wouldn't be confident in knowing it was really Bob, but at least you could be confident knowing that no one is sniffing your conversation with said "Bob". Hence the need for both, encryption AND authentication. I just didn't understand why I needed to have a cert if all I wanted to do was encrypt my pay load.
    – Joseph
    Apr 30, 2009 at 16:14
  • You need a cert to do encryption, but it doesn't have to be a signed cert.
    – pjz
    Apr 30, 2009 at 16:25

Main benefit is you do not need to visit a 3rd party to handle your site's security. You can do this yourself. The problem is it's complicated to get right.

Their browser would need to "trust" the self-signed certificate. If you change the cert in the future, the same dialog should appear. Some answers explain how to do this. This is still bad, since users would be more susceptible to attacks, such as man-in-the-middle when they are trained to accept self signed certificates. I've seen companies where this is standard procedure! Too bad for those users!

Ideally, you would have a process to install a custom root cert on their box prior to attempting to hit your site. This root cert would then issue your site's cert. This way, their browser would trust your self signed cert prior to connecting to your site the 1st time, without displaying a trust error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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