8

I'm using pyOpenSSL which is a wrapper for OpenSSL. I had a client program trying to connect to my server and repeatedly was getting sslv3 alert bad certificate on the server. It wasn't until I realized it was due to the client's clock being improperly set that I was able to figure out the issue. I'm guessing that the client saw the server's certs as being dated in the "future" and somehow that resulted in a sslv3 alert bad certificate on the server.

Is there any way to get better descriptions as to why a particular cert failed? I'm assuming in this case the verification failed on the client side due to the clock not being set right, but the error on the server side is the same as if a bad certificate was sent and the verification failed on the server side.

Tim Tisdall
  • 9,914
  • 3
  • 52
  • 82

2 Answers2

4

Unfortunately the problem descriptions are fairly limited. Errors are transmitted with TLS alerts. Each alert is only a number without any additional information and there are only few alerts defined, see http://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol. For example there is an alert for an expired certificate, but no alert for a certificate which is not yet valid which would be necessary in your case. So all the client could send back is that the certificate is bad.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Well, I'm using OpenSSL on both ends... is there anything I can do on the client side to see the error so I can at least log it? – Tim Tisdall Oct 29 '14 at 14:39
  • See the documentation for [X509_STORE_CTX_get_error](https://www.openssl.org/docs/crypto/X509_STORE_CTX_get_error.html). This way you can get more detailed error codes on the side where the validation fails. – Steffen Ullrich Oct 29 '14 at 14:59
2

In most cases sslv3 alert bad certificate means that CA information is not provided at all or is wrong. In curl there is a parameter --cacert , for openssl s_client use -CAfile.

Jarda Pavlíček
  • 1,636
  • 17
  • 16