TLS handshake error


I am getting below error in my application logs

2017/07/31 07:33:01 server.go:1775: http: TLS handshake error from <some-ip>:22034: remote error: bad certificate

Thought this is not the case that every time this error, but from few specific clients. I am using golang’s standard ListenAndServe() function.

My ssl certificate is valid for sure, As I can see it from anywhere on the internet.

Please help me out to resolve the problem.

Advanced thanks.

What is your code doing on this line?

It is very hard to help you based just on your question. We would need to know more about your code, the setup of your server and clients.

Is there anything special about these clients?


this is from golang net/http package’s server.go file

if err := tlsConn.Handshake(); err != nil {
			c.server.logf("http: TLS handshake error from %s: %v", c.rwc.RemoteAddr(), err)

Below is my code where I am passing certificate and key to start https server on port 443

err := http.ListenAndServeTLS(":443", “certificate”, “key”, nil)`

The error indicates that the client (i.e., the TLS speaker on the other side) doesn’t like the certificate you presented. If you think your certificate is fine this is probably due to an error on the client. I usually see this with clients that have an old (or just plain unavailable) root certificate store. The certificate store can be unavailable for Go programs in particular if they are cross compiled and running on Windows or macOS.


Thanks Jacob!!

As I suspected the problem is at client end. But when I am creating a ncat ssl server with the same certificate on linux machine, then those particular clients are able to connect properly. So is there any way that I can do something from server end to handle these situations?

The typical way I kind of debug this problem is by using OpenSSL client.
Openssl s_client -connect server:443

If this signed by known authorities (read verisign all those folks) you should get a error of 0.
If it is a self signed certificate you would get an error code 19. And on passing in caFile argument you should be able to obtain 0.

And if the client and server use different version of ssl we would have issues.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.