When are self-signed certificates acceptable?

This question was posted on Slashdot and it solicited many different responses. UltraLoser posed the question this way:

When is it acceptable to encourage users to accept a self-signed SSL cert? Recently the staff of a certain Web site turned on optional SSL with a self-signed and domain-mismatched certificate for its users and encourages them to add an exception for this certificate. Their defense is that it is just as secure as one signed by a commercial CA; and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. In their situation is it acceptable to encourage users to trust this certificate or is this giving users a false sense of security?

There were hundreds of different responses but many people displayed a mistaken understanding of the purpose of SSL certificates. This is expressed in the first poster's response:

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

This is common perception of SSL certificates. It is also completely wrong! It is easy to see why server administrators think this. They think, "I need to get an SSL certificate to secure my server." But the certificate doesn't secure anything. The web server (IIS, Apache, etc.) simply requires a certificate so that it can do the encryption. It could do it all automatically if it wanted. But there is a reason for the SSL certificate. It is required by the server to enable encryption because it is an essential to establishing a trusted/secure connection.

It's All About Trust

A self-signed certificate is like a fake drivers license. Who would accept a fake drivers license? Most people wouldn't. But Internet communication is very different from real-life communication. You have little idea who is sending the information on the other end. The biggest problem with a self-signed certificate, is a man-in-the-middle attack. Even if you are 100% sure that you are on the correct website and you completely trust the site (your email server for example), you could have someone intercept the connection and present you with their own self-signed certificate. You would think that you are using a secure connection with your email server but you are really using a secure connection to an attacker's email server. Oh, and they now have your login credentials and anything else you gave them.

JSBiff explains it well:

It all comes down to, can you determine that you are using the same crypto key that the server is? The reason for signing certificates and the like is to try to detect when you are being hit with a man-in-the-middle attack. In a nutshell, that attack is when you try to open a connection to your 'known' IP address, say, Even though you are connecting to a 'known' IP address of a server you trust, doesn't mean you can necessarily trust traffic from that IP address. Why not? Because the Internet works by passing data from router to router until your data gets to it's destination. Every router in between is an opportunity for malicious code on that router to re-write your packet, and you'd never know the difference, unless you have some way to *verify* that the packet is from the trusted server.

A crypto key, if you have the *correct* key, can verify for you that the data hasn't been tampered with. The problem is, however, that before you can begin encrypted communications, you must do an *unencrypted* key exchange, where the server gives you it's crypto key. Here's where the man-in-the-middle has an opportunity. If your traffic is going through my router, I can intercept the self-signed key from the server, and generate a new self-signed key with the same server name, etc in it, so that it *looks* like the self-signed key from your server, but which allows me to decrypt the communications between you and the server. My router then establishes a connection to the server using the *correct* key, and as data passes between you and the server, I unencrypt the data using the real key, then re-encrypt it using the 'fake' key. So, the data is encrypted between me and the server, and between me and you, but gets unencrypted in my router, giving me the opportunity to spy on your data, or even alter if if I want.

The point of a CA-signed certificate is to give slightly stronger verification that you are actually using the key that belongs to the server you are trying to connect to.

Yes, self-signed keys have some uses - in particular if you happen to know the real key's fingerprint (a fingerprint is a numeric or hex string which identifies a cryptographic key), so that you can verify yourself that you are using the correct key for SSL. If you don't happen to know the fingerprint, it's probably still fine to use self-signed certs on a LAN, where you control all the equipment, so don't have to worry so much about a man-in-the-middle (although, arguably, on a LAN you might not even need encryption).

So, in summary, yes, SSL adds security to the connection, but ONLY if you can verify that the correct SSL key for your server is being used, and not a different key that a hostile router has injected.

Got it? Don't use self-signed certificates for sensitive, public connections. If you don't want to buy an SSL certificate, at least set-up your own certificate authority with its own root certificate. This will still give an error message to visitors unless you or they import the root certificate into the browser, but there is far less of a chance of a man-in-the-middle-attack.

When Is a Self-Signed SSL Certificate Acceptable? - [Slashdot]

Originally posted on Tue Jul 1, 2008

Comments (8)

  1. Robert:
    Aug 21, 2009 at 06:10 AM

    If you can get the client certificate installed on the server beforehand, then there is no problem with a self-signed client certificate because there is no chance of a man-in-the-middle attack.

  2. SSL Confused:
    Aug 20, 2009 at 07:59 PM

    what about self-signed certs used for client authentication? Can't we trust them? If the server admin receives the client cert directly from the client and imports it in the trust store, can't the self-signed cert now be trusted when the client establishes SSL connection? This seems like a case where self-signed cert would offer strong authentication on the server than if the client presented a CA signed cert, in which case anyone with a cert signed by a trusted CA could connect to the server. This matters if the goal of using SSL is to allow only selected clients to connect and not just anyone with a, say, Verisign cert.

  3. thetrivialstuff:
    May 24, 2009 at 05:00 PM

    Really, the way I think the certificate model should work is this: 1. The first time you connect to a secure site, ANY secure site, your browser says "you've never connected to this site before. It has offered this certificate." 2. You then review the certificate and see what its credentials are. Those credentials might be the fact that a CA signed it, and you may or may not trust that CA. An EQUALLY VALID credential is that you know what the fingerprint should be, because someone communicated it to you earlier by some other means (e.g. your bank gave you a piece of paper that said "when you connect to our online banking site, make sure the certificate you see has this fingerprint"). There should be no difference in validity between these methods in the browsers' UI, because security-wise the fingerprint method is actually more secure (because you're not trusting a third party). Presently, the browsers give absolute credance to CA-signed certificates, while erroneously advising users that all self-signed certificates are bad and dangerous, sometimes without even giving the user a chance to verify it as correct. 3. If the remote site's certificate changes in ANY way, no matter what, the browser should advise the user. Even if the new certificate is signed by the same CA, the browser should advise the user. Presently most browsers do not do this, so if a forged certificate (perhaps a CA was compromised, or one of their root certificates was successfully cracked) replaces a legitimate one, the user gets no warning at all. In this case, the CA-signed certificates are far LESS secure than self-signed ones because of the browsers' behaviour: if a trusted self-signed certificate is replaced with a different self-signed certificate, the user at least gets a warning.

  4. Kyle H:
    Dec 23, 2008 at 10:25 AM

    My belief is this: if I run the CA, I know what it's doing. It's been shown that Comodo (at the least) has issued improperly-authenticated certificates (they say they're "domain control validated", but Eddy Nigg of StartCom was able to obtain one for mozilla.com, a domain which he certainly does not control or have the ability to send mail from or place content on the website of). All TLS certificates do is state that someone has authenticated the endpoint. If I've authenticated the endpoint elsewhere, and I've issued a certificate to it, I know for myself that it's the right entity. The only reason why CAs get into the browsers is because they're theoretically audited and their internal controls are deemed to be sufficient to prevent unauthenticated issuance. Obviously, in the case of Comodo, this trust was misplaced. (Nevermind Verisign's mis-issuance of two certificates for Microsoft Corporation way back when, which forced MS to come up with CRL-handling code very quickly.) I look at my own issuance of certificates very much like signing an OpenPGP key. I've done my due diligence, and if you believe that I have you can add my root to your trusted store.

  5. Duane:
    Jul 16, 2008 at 04:58 PM

    I didn't bother reading all the comments on the slashdot thread, but I'm sure there is still a bug open on the mozilla bug tracker about Verisign, they are in a position to issue certificates trusted by most browsers, they also control a root server and more directly control .com and .net. Browsers never warn the user when certificates change, so how do we know we aren't suffering a man in the middle attack being proxied via a Verisign redirection. A Verisign employee went so far as to say they would issue duplicate certificates to government entities if they were compelled to on one of the Mozilla newsgroups/mailing lists a few years ago. SSL certificates really shouldn't be trusted for anything more than financial transactions and maybe protecting passwords, after that all bets are off.

  6. Robert:
    Jul 15, 2008 at 05:42 PM

    Duane, You are correct in distinguishing between different kinds of trust. An SSL Certificate primarily allows a customer to "trust" that the website they're using is actually owned by the company listed on the certificate and that all the encrypted communications will be sent to that company's servers. It can also increase trust a little because a a company is verified by the certificate authority to be an active entity and have a verified address. However, an SSL certificate doesn't stop the company from lying or commiting fraud. The only way for that kind of trust to be gained is for the customer to use the web site and have a good experience.

  7. Duane:
    Jul 14, 2008 at 10:16 PM

    For someone trying to clean up the myths surrounding what SSL is and what it isn't you still perpetuate the trust myth, trust is a much to fluid term even in such a specific context to use so flippently. You aren't trying to establish trust that comes over time by dealing with the same person or compamy repeatedly with amicable outcomes, it certainly doesn't come from some faceless multinational corp that says this is Joe Smith, just like drivers licenses can be faked, Verisign has issued false certificates in the past too. What SSL certificates really do is try to express a level of confidence that you have that people are telling the truth or acting in good faith, sure this is a type of trust, but it is by no means the same thing as trusting someone with your car or your child.

  8. Alan:
    Jul 01, 2008 at 07:52 AM

    There truly are some clueless comments on that thread. As you said, the purpose of the certificate is for establishing trust (ie, for the client to verify the identity of the server).

Allowed tags: <b><i><br>Add a new comment: