Thanks for your answer, Matt. Obviously the issue is caused by the server. Currently I have two servers: 1. The legacy server running IIS 2. The new server running HAProxy I also have two clients: 1. the actual hardware client equipped with a hardware security module 2. curl using a client certificate that I have created according to the procedure that is used for the hardware device above Now the picture is: both clients work with the legacy server but none of them work with the new HAProxy server. BTW: if you have a detailed look at my provided pcap you will notice that the client certificate is expired. I've fixed this - without change in the outcom. Regards, Carsten On 24/01/2019 09:19, Scharfenberg, Carsten wrote: > Hello everybody, > > I've just joined this group because I hope you guys can help me with my problem. > > I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2 > connections with client authentication. > The TLS handshake runs through fine. But then the server answers with a Decrypt > Error Alert to the Finish message sent by the client. What is the client? Is this also OpenSSL (and if so which version), or is it something else? > How would I debug this error? > Is it possible that something is wrong with my certificates? That seems unlikely. If there was something wrong with the certificates I would have expected the handshake to fail before the point that it gets to. > > I've had a look into the source code. Unfortunately it's not so easy to read. It > seems to me the alert is generated here: > ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the > comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails. > Unfortunately I currently do not know what this means. As each endpoint sends and receives handshake messages they both digest the contents of those messages. The last step in the process is for each endpoint to compare the digests that they created. They should be the same. If they are different then that indicates that something has changed between one endpoint sending one of those messages and its peer receiving it. This could in theory be an active attacker. More likely though it could be due to some form of corruption taking place somewhere. Some ideas as to the source of a possible corruption: - client application bug - server application bug - client TLS library bug - server TLS library bug - network "middlebox" corruption I'd start by trying to isolate whether the problem is on the client side, the server side, or the network. e.g. if the client is on the same host as the server does the issue occur? Can you connect from a different client (different application and/or different library or library version). Can the client connect to other servers successfully. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
