On 24/01/2019 11:00, Scharfenberg, Carsten wrote: > 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. Hmmm. It's possible that it is still a client issue if the negotiated extensions/ciphersuite/protocol version etc differ between the connection for the old server and the new server. You might want to experiment with different ciphersuite/group/sigalgs etc settings on the server to see if there is sensitivity there to this issue. Matt > > 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
