I'm doing an integration with a system that has a self-signed certificate. For initial development, we choose to ignore the certificate checking to bypass some errors:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

because we first need to understand how to add the certificate using the Java keytool on a docker environment.

But, my question is: what is the advantage in that case to import a self-signed certificate as a "Trusted Certificate" when I could just ignore it?

  • You should read Peter Gutmann's Engineering Security book. There are two or three chapters dedicated to the business of PKI. Self-signed certificates are fine, and often better than warez you get from PKI vending machines. The web security model is a whole 'nother can of worms, and you should avoid it if possible.
    – user29925
    Commented Jul 2, 2019 at 11:20
  • I think that a statement like "the web security model is a whole 'nother can of worms, and you should avoid it if possible" needs references. But I nonetheless agree with your advice about using self-signed certificates when it is possible.
    – jjmontes
    Commented Jul 2, 2019 at 15:51
  • If you can transport the certificate or at least it’s fingerprint over a secure channel you have a very reliable way to be able to recognize impersonation attacks. In fact the trust level might be much higher than trusting any of a hundred public CAs to not do their work correctly. So a Self signed (or privately signed) certificate is not only a convenience hack but might add additional protection (but also more work)
    – eckes
    Commented Jul 2, 2019 at 18:22
  • "For initial development" ==> I think it's a good idea to reduce the complexity and effort of work by relaxing certain constraints. It's, however, extremely important that you track with //TODOs or Jira tickets that your software needs a change before going live. While you and your fellow developers build the application, one of the team may focus on adding the certificate to the trust store, which is a joke, without slowing the development process. I would also add a software engineering advice: please implement code that will turn SSL validation on or off based on a switchable property Commented Jul 3, 2019 at 7:58
  • (Continued) so that you disable certificate validation only under exceptional circumstances like developing on your machine or test network and only when needed. Commented Jul 3, 2019 at 7:59

4 Answers 4


If it's an official service you are integrating with the provider should really have a valid, publicly signed certificate installed for the sake of security.

Assuming that you need to continue on with your provider using a self signed certificate, the big difference between ignoring the certificate and adding it as trusted is the following scenario. This ues DNS poisoning as an example of a man in the middle attack.

Take the following example:

  • api.example.com has a self signed cert with thumbprint XXX listening on the IP
  • Adding it to your trust store makes your system expect the thumbprint to be XXX when connecting
  • If someone was able to poison your DNS - make api.example.com resolve to - the thumbprint would be YYY.
  • By adding the cert to your store your product would refuse to connect to the malicious site.
  • By disabling the check entirely, your product would happily connect to the malicious api.example.com at
  • To be fair, it depends what the system is. If it's self-hosted, it's not really fair to expect the service provider to ship certs with their program; they don't know what domain it'll be hosted on. If it's externally hosted, though, I agree -- it's weird that they don't have a proper, CA-granted cert.
    – anon
    Commented Jul 1, 2019 at 22:14
  • 11
    Not just DNS poisoning, any sort of MitM would be included as well, however that M manages to insert himself into the M…
    – deceze
    Commented Jul 2, 2019 at 5:01
  • 1
    @NicHartley If it's self-hosted, I expect the vendor to provide a way to install a custom certificate. Commented Jul 2, 2019 at 5:03
  • @chrylis That's... what I was trying to say. That the system itself just has a slot to put a cert in, and whoever set up the system was doing it wrong, not the system's designers.
    – anon
    Commented Jul 2, 2019 at 5:08
  • 2
    @deceze fair point, I just used it as a specific example. Commented Jul 2, 2019 at 11:28

By importing a known good self-signed certificate where the private key is unique and not compromised, the connection is just as safe as a full global CA PKI signed certificate. Those are after all also simply stored and trusted at some point.

The reason to get a PKI CA signed cert is one of practicality more than security; if you have to trust a self-signed certificate on many clients, that can be a lot of work. And doing key rotation almost exponentially increases that work.

If you control the server and client, like during development, and you don’t have the skill or resources to setup a private CA, then adding a specific self-signed certificate to a trust store is not so bad. Accepting any certificate is bad, never do that.

  • 2
    Key rotation has turned out to be mostly useless from a security point of view. In fact it appears to be harmful. In practice key continuity is a much better security property.
    – user29925
    Commented Jul 2, 2019 at 11:16
  • @jww "Key rotation has turned out to be mostly useless from a security point of view." Can you point me to something that elaborates on this? Thanks.
    – JimmyJames
    Commented Jul 2, 2019 at 14:54
  • Key rotation has no relation to password change enforcement, if that’s what you’re getting at Commented Jul 2, 2019 at 15:06
  • @jww I'd be interested about sources as well. There's good reasons to use key rotation (e.g. you limit the amount of data that is exposed if a key ends up being exposed) and I haven't experienced any downsides either. I assume it's to do with the fact that short rotations mean the intermediate CA won't be as well protected as it would be otherwise?
    – Voo
    Commented Jul 2, 2019 at 18:58
  • See Peter Gutmann's Engineering Security. He dedicates an entire section on key continuity. He also offers a couple chapters on PKI and its numerous problems. Key continuity is how DigiNotar was discovered. You might also be interested in the web security model, and how interception is a valid use case.
    – user29925
    Commented Jul 2, 2019 at 19:00

If you ignore the certificate check, anyone who can gain the man-in-the-middle position (with the ability to modify traffic) between you and the other system can read/modify the plain-text traffic. An attacker will simply break the TLS/SSL tunnel by starting his own TLS server using his self-signed certificate, route your traffic to it, decrypt it, and proxy it to the real server. There are many tools which make this attack pretty easy, for instance, mitmproxy for HTTPS or stunnel in general for TLS/SSL.

An attack can get into the man-in-the-middle position in many different ways. Thus, it is tough to completely rule out, that there is no way for an attacker to gain this position even if you're a network security expert.

If there is no way to replace the self-signed certificate with a publicly signed certificate, you can trust self-signed the certificate manually by adding it to a Java keystore using keytool and trust this store. This is sometimes called Certificate or Public Key Pinning


Certificates are the way that the signer can vouch for the signee. If you trust the signer, then you can trust the certificate and the signed public key. If you trust the signee, you can ignore the certificate.

In more real world terms:

Example 1: Cindy Certificateauthority is very well known. Everyone knows Cindy. Cindy has a really good reputation for verifying who people really are before she introduces them to other people. Someone claims to be Pablo Pubkey - a well known and trustworthy salesman - wants to sell you something. Cindy introduces you to this person and says that he's Pablo. You trust Cindy, so you believe that the person is Pablo, and so you decide to give Pablo your credit card number and buy stuff.

Example 2: You grew up with Freddy Friend since you were a child. You know who Freddy is - you met him in kindergarten and seen him become an adult alongside you. Freddy is also a salesman. If you want to talk to Freddy, you just go find Freddy - you don't need anyone to introduce you to him.

In the first example, you relied on a certificate authority whom you trust to tell you who owns a particular public key. In the second example, you had direct trust in the public key and didn't need a third party to tell you who owns it - for example, your software may issue public keys to its users and associate those public keys in your software's database. This second example is exactly the same when you have a self signed certificate and an unsigned certificate.

You must log in to answer this question.

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