Establishing TLS connection fails when client authentication and TLS version 1.3 is used.

[laurglia]

Describe the bug
When trying to establish a connection with Apple Business Chat service (mspgw.push.apple.com) and using client authentication, TLS alert is received after the TLS handshake finishes.

Some scenarios I tested where the bug did not occur:

• When establishing a connection without client authentication. For example, the following works fine: ssl:connect("mspgw.push.apple.com", 443, []).
• When establishing a connection with TLS v1.2. The following code establishes a connection without any issues: ssl:connect("mspgw.push.apple.com", 443, [{certfile, <<"cert.pem">>}, {keyfile, <<"key.pem">>}, {versions, ['tlsv1.2']}]).
• When establishing a connection with some other service besides Apple Business Chat. For example, one can start a TLS server with OpenSSL: openssl s_server -accept 4444 -Verify 3 -key server.pem -cert server_cert.pem and then connect to it with the following code: ssl:connect("localhost", 4444, [{certfile, <<"cert.pem">>}, {keyfile, <<"key.pem">>}]).
• When connecting to Apple Business Chat service using some other TLS client. With OpenSSL s_client, the connection can be established: openssl s_client -connect mspgw.push.apple.com:443 -key key.pem -cert cert.pem.

To Reproduce

1. Generate a private key and certificate for it. Can be done with the following OpenSSL command: openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout key.pem -out cert.pem
2. Start Erlang Shell in the same directory where the key and certificate are.
3. Start SSL application with ssl:start().
4. Try to establish a connection with Apple Business Chat server: ssl:connect("mspgw.push.apple.com", 443, [{certfile, <<"cert.pem">>}, {keyfile, <<"key.pem">>}]).
5. Observe that the following TLS alert is sent from the server: TLS client: In state connection received SERVER ALERT: Fatal - Decrypt Error

Expected behavior
The TLS connection should start without receiving the Decrypt Error alert from the server.

Affected versions
I tested and was able to reproduce the bug with OTP 23.2 and OTP 24 RC1. Most likely any OTP version that supports TLS v1.3.

[IngelaAndin]

I am able to reproduce the scenario. And I can confirm it is a bug in how the client chooses the signature algorithm for its certificateverify message. Will be working on a fix.