AFAIK, using self-signed certificates on public usage has following problems.

  1. Cannot verify its authenticity on the first-time key exchange. However, if first key exchange was successful, following communication would be secured by comparing stored server cert. on clients.

  2. If cert.'s private key is stolen, cannot revoke that cert.

If they are all the risks of self-singed cert, in the following situation, I think it is not that bad to use self-signed cert.

  1. All the clients are managed. So if the cert's private key was spoiled, I can remove all the previous certs on all clients and re-new it for new self-signed cert manually.

  2. I can pre-install self-signed cert to clients by offline before its first communication to server. So there's no risk of accepting fake cert on first handshake.

In this circumstance, is it okay to use self-signed certificate? or there still have important reason to use CA-signed certificate?

3 Answers 3


Yes, in this situation, it's ok to use a self-signed certificate, with the following proviso...

Not all browsers play nice with self-signed certificates. Firefox for example, usually wants to independently verify the CA for a certificate, and may not automatically trust certificates that have been manually added to the certificate store on the client.

The user may still be able to instruct the browser to ignore the warning, but it may not be possible to actually remove the warning.

If the users are not using Firefox, or they're ok with the warning messages, then self-signed is fine.

It's also worth keeping in mind that it generally won't be possible to add custom certificates on mobile devices. If your users may want to use mobile devices, then self-signed certificates may be problematic.

  • Oops I accidently entered enter. my service is not browser-based. server is based on node.js and client is custom program (I'm not sure how https communication is handled, maybe based on ie engine by default). client will be only desktop windows. So I think according to your answer, it is okay to use. Commented Oct 17, 2016 at 3:35
  • Using a custom program may introduce some other issues. Most SSL client libraries by default will want to verify SSL certificates, and will usually refuse to connect to a self-signed HTTPS URL, unless you switch the code to non-verify mode. This however means that they will then allow any certificate without verification, potentially making your application vulnerable to server spoofing. Commented Oct 17, 2016 at 3:39
  • I'd suggest that perhaps you should consider purchasing a certificate. They're quite inexpensive, and will effectively remove this risk. Commented Oct 17, 2016 at 3:41
  • Will it be a problem if I install my self-signed certificate in the trusted root store? After adding my certificate on there, clients accepts connections without warning although it is self-signed. (of course since I added it to the root CA store...) Since I can manually remove and re-new all the clients' certificate, I think it wouldn't be a big problem to add it to root CA store...is it? Commented Oct 17, 2016 at 3:47
  • Thank you for your advice! Of course, I'm also considering to buy CA signed cert. I'm asking these questions just in case. Commented Oct 17, 2016 at 3:51

If I correctly understand, you want to build a correct SSL connection without having to buy a certificate to a third party well known provider.

As you said that you could know all clients and pre-install certificates before first communication to server, it is perfectly fine. Simply if you directly use self signed certificate you could lead browsers (and users) in various corner cases, that you could easily avoid.

My advice would be to build a mini CA (openssl comes with all you need for that, include tutorials):

  • you create a self signed cerficate that will be used to signed auxilliary certificates and store the private key in a secure place
  • you pass it offline to you clients, and ask them to install it as a root certificate (all root certificates are by definition self signed)
  • you create a server certificate that you sign with the self-signed certificate and use it normally.

That way all browsers will process smoothly a standard certificate chain. As a bonus, you could even publish an initialy empty Certificate Revocation List, that you could later use if you needed to revoke one certificate.


... my service is not browser-based
... All the clients are managed

As long as you properly check the certificate use of a self-signed certificate is fine from the perspective of security. Your "not browser-based" application should just accept this single certificate then, either by comparing the public key or the full certificate. See OWASP: certificate and public key pinning for more information including sample code.

In your use case it might even be more secure than trusting the usual public certificate agencies because the less you need to trust the less can misuse your trust.

But, depending on where your application is used you might also run into trouble when trusting only this single certificate. SSL interception done for security reasons in company firewalls will not work in this case, both because the firewall does not trust your self-issued certificate and your application does not trust the firewall-issued certificate. This means that your application will either not work at all or only work if explicit exceptions are added to the firewall.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .