Take the 2-minute tour ×
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

2 Answers 2

up vote 33 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

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.