When trying to send an email over smtp with SSL in Java code I get the following exception:

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Failed messages: javax.mail.MessagingException: Could not connect to SMTP host:

This would make sense if the SMTP server I am approaching used some self-signed certificate that I simply didn't import but I don't think that is the case, because when my colleague (in another country) runs the exact same code it works just fine.

What could this mean?

  • My laptop is compromised
  • My internet provider is doing something fishy
  • Something else
  • All of the above

For the record, I'm living in Indonesia and there are some sites that are blocked.

I am able to ping, a password is needed for this smtp server, the settings are fine (it works for my colleague). I have tried this with both my VPN turned on and off.

  • Answer these questions: Are you able to ping the same server? do you need a password to connect to the SMTP server? Are you sure you are using the right settings (as in port number)? Are you behind a proxy or a firewall? Can you use those settings in a regular mail program (e.g. Thunderbird) and send mails? Feb 26, 2018 at 6:37
  • Yes I am able to ping, yes a password is needed, yes I am sure about the settings (it works for my colleague). I have tried this with both my VPN turned on and off. The latter I have tried in Thunderbird actually, but I couldn’t configure it since it requires configuration of the inbox at the same time and there is no server for that. I will try with a simpler tool later. I’ll edit this into my post when I’m back home Feb 26, 2018 at 7:16
  • 3
    Are both of you on the same platform(s)? If using Sun/Oracle Java, different versions/updates sometimes change cacerts, e.g. versions below 8u101 didn't trust the root used by LetsEncrypt. OpenJDK may use different truststores depending on how it is packaged. I believe (but can't test) IBM Java has its own list. And the default can be overridden by -Djavax.net.ssl.trustStore* settings without any difference in code. In j7+ keytool -printcert -sslserver host[:port] shows the certs received (without checking). Feb 26, 2018 at 12:00
  • Examine the certificate presented to you by the server. Check if it is trustworthy, e.g. issued by a CA you trust. Then you may want to check Java's keystore to see if the certificate or its root authority are stored. See also superuser.com/questions/55470/…
    – JimmyB
    Feb 26, 2018 at 12:06
  • To add to dave_thompson_085 comment. There are knwon stuff between Java 6 & 7 where this can happen because security that tighten in Java 7.
    – Walfrat
    Feb 26, 2018 at 12:36

2 Answers 2


If the SMTP server is using a self-signed certificate and you did not import the certificate as trusted this exception would be the expected one and something would be wrong (insecure) with your code if you would not get such an error. If instead the certificate should be signed by a public CA it might be a problem that you don't trust this CA in your code for some reason (unlikely), that you get a different CA then was sent by the server (i.e. SSL interception) or that the server is not properly setup and might be missing a chain certificate.

If it works for your colleagues you need to check with them what they do different. It might be that they get a different certificate then you if they have a different network connectivity (i.e. one without SSL interception vs. one with SSL interception). It might also be that they've explicitly imported the relevant certificate as trusted. Or it might be that they explicitly ignore certificate errors in their code. And while ignoring certificate errors is usually a terrible idea since it makes man in the middle attacks undetectable, it is still a commonly recommended workaround by users which don't understand or don't care about security.

  • I said this would make sense IF the server had a self-signed certificate, but it doesn’t Feb 26, 2018 at 7:13
  • 2
    @SebastiaanvandenBroek: I understand your question that your only indication you have that the certificate is not self-signed is that it works for your colleagues. Which means that you did not actually check the certificate but simply assumed something about it. To find out what the problem really is you would actually need to find out a) if your colleagues get the same certificate you get and b) if this certificate is properly signed by a public CA or not. Everything else is just blindly guessing what could be the case. Feb 26, 2018 at 7:19
  • Fair point to check out the actual certificates, I will. The code is exactly the same (same repository checkout) and this person is on a brand new laptop and not the kind of person that would ignore bad certificates. But either way we’ll have to verify all steps at this point. Feb 26, 2018 at 7:43
  • 1
    @SebastiaanvandenBroek: Note that even some antivirus on the local system is doing SSL interception, i.e. it might depend on the network but also on the setup of the local machine. Feb 26, 2018 at 8:18
  • It was indeed my virus scanner getting involved, thanks for the pointer. I already upvoted you before but self-answered the question with what was actually wrong in this case, but will accept your more generic answer if you include the virus scanner possibility. Feb 26, 2018 at 16:34

The certificate authority was Comodo which was fine, after running keytool -printcert -sslserver host as per Dave's comment, I found out the problem was on my end with my virus scanner (Avast) inserting its own certificate. Even after disabling SSL scanning and SMTP scanning the certificate still showed as theirs, so I unfortunately had to disable that whole component.

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.