On 24/01/2019 15:33, Matt Caswell wrote: > > > 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. Another thought - are connections successful if client auth is NOT used? Matt > > 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
