I have a Go program that uses tls.Server to accept TLS connections from clients. When a particular client connects, I'm getting the error "tls: failed to verify client's certificate: x509: certificate signed by unknown authority".
I'd like to see the certificate chain that was presented (and failed to verify) so that I can figure out what the client is doing wrong. Is there a way to do that using Go's tls package? The obvious answer - to use the ConnectionState method - doesn't work because the ConnectionState's PeerCertificates field is only populated after the handshake has completed successfully.
Related
I have written separate client and server applications that use OpenSSL to exchange encrypted data. Both applications work. The only minor issue I have involves the client application. SSL_is_init_finished returns true after the client receives the first TLS handshake message. I need something that can be used to verify that the client has received the second (assumed to be last) TLS handshake message. Does the OpenSSL API provide a method?
After installing IBM System i Accesss for windows V6R1M0 i have application pooling which can't start
and i get the above errors:
A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 48. The Windows SChannel error state is 552.
The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate.
So far, I've used openssl, sslyze, keystore utilities, and some of the standard Windows diagnostics commands to try and characterize this problem. The summary is that as soon as I attempt to use a keystore that has the CA signed certificate in it, I get an immediate handshake failure 40 after the client hello. The connection never gets as far as a server hello with the CA cert in place.
On the same machine (Windows Server 2012), if I use a self signed certificate, the connection works as expected.
Openssl shows the handshake failure with the CA certificate in place.
sslyze shows all ciphers rejected with either no ciphers available or TLS / Alert handshake failure.
The fact that this is successful with a self-signed certificate tends to indicate that the "basics" are there, that the client and server have the necessary ciphers and so on to connect, and that server.xml is configured properly.
There were no error messages when importing the certificates, and everything seems to be configured correctly with the CA certs based on keytool checks. There are no error messages given during server start to indicate any problems processing the certificate.
Is there something I should be looking more closely at in regards to the keystore with the CA cert that could cause this complete rejection of the client hello? How would a different keystore or CA certs within aaffect the earliest steps of the handshake?
Thank you for information provided.
I assume that you are talking about a server side certificate and a server side key store, since the error happens at a state where no client certificates are yet involved. If the server is able to send the self-signed certificate to the client, but is not able to send the CA signed certificate to the client, then it must be something wrong with the certificate you are trying to send or that the certificate can not be used together with the ciphers offered by the client.
Since the problem is obviously on the server side you should first check all logs written on the server side for hints what the error might be. Typical problems are non-existing files, wrong files, password protected client key w/o providing a password or that the key does not belong to the certificate.
I'm getting an SSL Connection failed error when I try to connection to an HTTPS endpoint using Parse.Cloud.HTTPRequest. My guess is that the CA that issued the SSL Certificate isn't trusted by the Parse Server. Is there a way to trust that particular CA/Certificate?
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.
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.
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.