Yes, it works if I deactivate client auth. Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client. Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing. So I'm very confident about the cipher suite and the signature algorithm. I've just created a new certificate hierarchy. Et voila: it works. So obviously this issue is certificate-related. Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment. My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions). -----Ursprüngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] Im Auftrag von Matt Caswell Gesendet: Donnerstag, 24. Januar 2019 16:38 An: openssl-users@xxxxxxxxxxx Betreff: Re: decrypt error 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
