There are multiple sources claiming that self-signed certificates are dangerous because ultimately the client has to accept connection to a website that his browser tells him is unsafe and he has got no way to verify whether the website is genuine or an impersonation by a man in the middle. However, what if those certificates are distributed to the clients in a trusted secure manner and they import them. Wouldn't this allow them to actually verify the identity of the website? Are there any additional dangers from that?


I see an additional problem with this type of setup. As self-signed certificates usually are signed by itself, not by a CA (otherwise it would not really be a self-signed certificate), you won't be able to revoke the certificate if the private key is compromised. The only way to revoke the certificate will be removing it from the clients trust store, which usually cannot be done remotely.

If you want to do this setup, create a CA, and save it securely (offline is preferred). Then, create an intermediate certificate signed by your CA and use that to sign the final certificates. Then, you will be able to revoke the certificates (unless base certificate is compromised).

  • This is the setup I had in mind but it didn't occur to me to be more clear about the distinction between self-signed and signing with your own CA. Thanks for clarifying! – Conor Mancone Oct 25 '17 at 11:36
  • Good point! Having a CA allows more control over certificate lifetime. – Worse_Username Oct 25 '17 at 12:21
  • Are you sure this would actually work? Some browsers (such as Chrome) don't do online revocation checks (and even those that do tend to soft-fail, making the measure effectively useless), and I think it's unlikely you'd be able to convince browser vendors to add the CRL for your small, internal CA to their master CRLs. For revocation to actually be effective in this scenario I imagine you'd need to set up not just a CA cert, but also an OCSP stapling server. – Ajedi32 Oct 26 '17 at 14:47

I'm not sure if I'd call self-signed certificates dangerous personally. They are less dangerous than sending information in the clear and pinning can be used to make sure that the site remains consistent from one visit to another (though pinning has it's own set of significant problems).

That said, to your direct question, as long as trust in the certificate is established, there is no problem with a self-signed certificate. The real risk with having clients import the certificate trust is that they need to be careful where they trust the key. They likely shouldn't be putting it as a root trust as you aren't taking the same cares to protect the private key as a CA would and don't want you being compromised to allow any site to be compromised.

The point of the entire CA system is just to help establish trust. If trust can be established independently and certificates properly trusted outside of delegated trust, then self-signed is no different, it just has it's own set of limitations that need to be overcome in order to make proper use of it. A client for installing the certificate correctly wouldn't be a horrible idea if this is the only option.

That said, services like Lets Encrypt offer free SSL certs, so there aren't a whole lot of situations where the headaches of using a self-signed key are actually worth it.


If you can get the client to install your CA so that the computer trusts the website as valid, then yes, this would allow them to verify the identify of the website. As a result, the concerns over self-signed certificates would no longer be applicable. Typically, the biggest hang-up to this kind of solution is the fact that it can be hard to execute in practice. If your service is going to be accessed by a small number of clients, and the people managing those machines are tech-savvy enough to properly install the CA, then this can be a perfectly reasonable solution (presuming everything is transmitted securely). However, having considered such a solution myself in the past, I've found that circumstances are rarely so favorable, and the devil is in the details.

1) If you are talking about installing the CA on servers, for which you might come up with a fairly automated process to securely share and install the CA, then great!

2) If you are talking about walking any number of non-technical experts through the process of installing your CA on their personal/work machines (which I imagine is the case since you mentioned browsers), then the process is unlikely to go smoothly. I don't think it will be as easy as you might think, but that depends on the details of what you are doing, and how many clients are involved.

Also, there is one very critical aspect to keep in mind: if you do this you need to make sure and protected your root certificate with the utmost security. Presumably this application that lives behind the self-signed cert is protecting some valuable data/services. If a malicious attacker gets a hold of your root certificate they can sign themselves some new certs and execute a MITM attack with no-one the wiser.

An alternative

Especially since you mentioned browsers, you should know that let's encrypt no provides free and automated SSL certificates. I've used it myself a few times and it is extremely easy to use and setup. If you can, don't bother attempting a self-signed cert. Just get a free certificate from let's encrypt.

  • 1
    "presuming everything is transmitted securely" That's the tricky part. You can't just tell your users "oh, just tell your browser to trust that particular certificate", because you have no idea whether the cert the client is seeing is the legitimate one or not. You need a secure way to install the cert on the client's computer, and the logistics of doing that in a truly secure way can be rather complex. – Ajedi32 Oct 24 '17 at 14:13
  • @Ajedi32 I don't disagree. The OP asked with the stipulation that everything was transmitted securely. Feel free to add in another answer that discusses the challenges in doing that. – Conor Mancone Oct 24 '17 at 14:19

The distinction between a self-signed certificate and a certificate signed by a previously unknown CA made by amau is critical. (+1)

However the security issues are not just about revocation - the point at which you distribute/install the certificate (and the mechanism) has risks and costs. By only distributing the CA cert, you eliminate recurrence of these issues if you ever distribute a second cert....or a third...

amau suggested you should use an isolated root CA and intermediate CAs rather than just signing the certificates from the root CA. While the former is certainly a more secure approach, we can't say whether the latter would be sufficient for your requirements.


Public key systems are based on trust, basically you have a third party that is trustworthy and both the user and server trust it.

Then we have a transitive relation if the third party trusts the server and the user trusts the third party then the user will trust the server.

It is all based on trust.

If all your customers trust you and you can properly protect your root CA then I see no issues but the trouble of adding your CA to their trust authorities lists.

If you do not know what you’re doing or clients don’t trust you, you might be creating opportunities for man in the middle situations and putting at danger your systems and users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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