Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Let's say I sign a SSL certificate for myself, and I'm not using a certified CA. What are the risks and/or threats of doing it?

share|improve this question
In short: There's no real threat/risks to you, but your clients who use whatever services are signed by the cert will probably be dubious of its validity. – Iszi Oct 13 '11 at 18:54
Side note: why not use certified CA? if cost is the reason, there are free lvl 1 certs. better then self signed. – Mark Coker Sep 9 at 1:01

3 Answers 3

up vote 37 down vote accepted

The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.

When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.

On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).

It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.

share|improve this answer
"extensive verification" ... that or mere domain validation .... – yfeldblum Oct 14 '11 at 1:42
Nice answer! Thanks it makes it really clear for me :) – Timo Willemsen Oct 14 '11 at 7:04

From the accepted answer:

Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.

Not true.

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.


So basically...using a self signed certificate is completely unsafe unless

  • you control every machine between you and the server
  • OR you check that the keys in the certificate are what you expect them to be.
share|improve this answer
It is nice of you to explain the scenario of a MITM scenario for SSL in simple terms, but the accepted answer does not contradict anything of what you said. A man in the middle who intercepts certificates and keeps two differently encrypted connections is certainly not a passive attacker. – zinfandel Sep 8 at 23:57
@zinfandel passive attack as defined by the answer the attacker observes the data but does not alter it in any way is not thwarted. – basarat Sep 9 at 0:37

You will be presented with a security warning (unless your CA cert is installed in your browser). Unless you inspect the certificate and verify the thumbprint matches what you expect, you can not be certain you are communicating with the right server (DNS pinning can help, like how chrome wasn't vulnerable to the diginotar and comodo problems.

SSL is about protecting data while assuring identity. A self-signed cert can cause you to lose both benefits.

Also, getting in the habit of accepting certificate warnings will lead to badness. So from a psychological perspective, it should be avoided at all costs.

Also, using self-signed certs means the terrorists win (ok maybe not)

share|improve this answer

Your Answer


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.