TLS negotiation error

[k-hay413]

Describe the bug

When trying to connect to MQTT, TLS fails with SECURITY_STATUS -2146893816 on tls-handler and raise error code 1029.

Here are the relevant logs:

[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: writing message of size 251
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: queueing write of 251 bytes
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: detected more scheduled tasks with the next occurring at 87775958323168, using timeout of 9871.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: waiting for a maximum of 9871 ms
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: wake up with 1 events to process.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: invoking handler.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: Write Completion callback triggered
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: Write of size 251 completed
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - static: write of size 251, completed on channel 0000025E35D02B10
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: running scheduled tasks.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: detected more scheduled tasks with the next occurring at 87775958323168, using timeout of 9871.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: waiting for a maximum of 9871 ms
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: wake up with 1 events to process.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: invoking handler.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: socket readable event triggered
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: socket on-readable with error code 0(AWS_ERROR_SUCCESS)
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: invoking read. Downstream window 18446744073709551615, max_to_read 16384
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: acquired message 0000025E3FE3A0A0 of capacity 16384 from pool 0000025E3FC1D240. Requested size was 16384
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: reading from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: read 100 bytes from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: read 100 from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: sending read message of size 100, from slot 0000025E3FCF6BD0 to slot 0000025E3FED9F90 with handler 0000025E3FE3E140.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: processing incoming message of size 100
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: running step 2 of client-side negotiation (cipher change, key exchange etc...)
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: acquired message 0000025E3FE3A0A0 of capacity 16284 from pool 0000025E3FC1D240. Requested size was 16284
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: reading from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: read 1460 bytes from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: read 1460 from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: sending read message of size 1460, from slot 0000025E3FCF6BD0 to slot 0000025E3FED9F90 with handler 0000025E3FE3E140.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: processing incoming message of size 1460
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: running step 2 of client-side negotiation (cipher change, key exchange etc...)
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: Incomplete buffer recieved. Incomplete size is 3562. Waiting for more data.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: acquired message 0000025E3FE3A0A0 of capacity 14824 from pool 0000025E3FC1D240. Requested size was 14824
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: reading from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: read would block, scheduling 0 byte read and returning
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: total read on this tick 1560
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: out of data to read on socket. Waiting on event-loop notification.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: running scheduled tasks.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: detected more scheduled tasks with the next occurring at 87775958323168, using timeout of 9787.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: waiting for a maximum of 9787 ms
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: wake up with 1 events to process.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [event-loop] - id=0000025E3FC820A0: invoking handler.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: socket readable event triggered
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: socket on-readable with error code 0(AWS_ERROR_SUCCESS)
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: invoking read. Downstream window 18446744073709551615, max_to_read 16384
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: acquired message 0000025E3FE3A0A0 of capacity 16384 from pool 0000025E3FC1D240. Requested size was 16384
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: reading from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: read 1460 bytes from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: read 1460 from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: sending read message of size 1460, from slot 0000025E3FCF6BD0 to slot 0000025E3FED9F90 with handler 0000025E3FE3E140.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: processing incoming message of size 1460
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: running step 2 of client-side negotiation (cipher change, key exchange etc...)
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: Incomplete buffer recieved. Incomplete size is 2102. Waiting for more data.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: acquired message 0000025E3FE3A0A0 of capacity 14924 from pool 0000025E3FC1D240. Requested size was 14924
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: reading from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: read 2486 bytes from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [socket-handler] - id=0000025E35C6FE20: read 2486 from socket
[TRACE] [2024-12-20T04:21:24Z] [00002848] [channel] - id=0000025E35D02B10: sending read message of size 2486, from slot 0000025E3FCF6BD0 to slot 0000025E3FED9F90 with handler 0000025E3FE3E140.
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: processing incoming message of size 2486
[TRACE] [2024-12-20T04:21:24Z] [00002848] [tls-handler] - id=0000025E3FE3E140: running step 2 of client-side negotiation (cipher change, key exchange etc...)
[ERROR] [2024-12-20T04:21:25Z] [00002848] [tls-handler] - id=0000025E3FE3E140: Error during negotiation. SECURITY_STATUS is -2146893816
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel-bootstrap] - id=0000025E35D34C60: tls negotiation result 1029 on channel 0000025E35D02B10
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: channel shutdown task is scheduled
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: scheduling task with wrapper task id 0000025E35D02CF0.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: scheduling task 0000025E35D02CF0 in-thread for timestamp 0
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35D02CF0: Scheduling channel_shutdown task for immediate execution
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: Channel shutdown is already pending, not scheduling another.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [socket-handler] - id=0000025E35C6FE20: total read on this tick 3946
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: Channel shutdown is already pending, not scheduling another.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: running scheduled tasks.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35D02CF0: Running channel_shutdown task with <Running> status
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: beginning shutdown process
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: shutting down slot 0000025E3FCF6BD0 (the first one) in the read direction
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: shutting down slot 0000025E3FCF6BD0, with handler 0000025E35C6FE20 in read direction with error code 1029
[TRACE] [2024-12-20T04:21:25Z] [00002848] [socket-handler] - id=0000025E35C6FE20: shutting down read direction with error_code 1029
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: handler 0000025E35C6FE20 shutdown in read dir completed.
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: handler 0000025E3FE3E140 shutdown in read dir completed.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: scheduling task 0000025E35D02B38 in-thread for timestamp 0
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35D02B38: Scheduling (null) task for immediate execution
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: detected more scheduled tasks with the next occurring at 0, using timeout of 0.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: waiting for a maximum of 0 ms
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: running scheduled tasks.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35D02B38: Running (null) task with <Running> status
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [tls-handler] - id=0000025E3FE3E140: Shutting down the write direction
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: acquired message 0000025E3FD50AF0 of capacity 7 from pool 0000025E3FC1D240. Requested size was 7
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: sending write message of size 7, from slot 0000025E3FED9F90 to slot 0000025E3FCF6BD0 with handler 0000025E35C6FE20.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [socket-handler] - id=0000025E35C6FE20: writing message of size 7
[TRACE] [2024-12-20T04:21:25Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: queueing write of 7 bytes
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: handler 0000025E3FE3E140 shutdown in write dir completed.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [socket-handler] - id=0000025E35C6FE20: shutting down write direction with error_code 1029
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [socket] - id=0000025E3FCD1730 handle=0000000000000250: closing
[TRACE] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: scheduling task with wrapper task id 0000025E35C6FEC0.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: scheduling task 0000025E35C6FEC0 in-thread for timestamp 0
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35C6FEC0: Scheduling socket_handler_close task for immediate execution
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: detected more scheduled tasks with the next occurring at 0, using timeout of 0.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: waiting for a maximum of 0 ms
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: wake up with 1 events to process.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: invoking handler.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [socket-handler] - static: write of size 7, completed on channel 0000025E35D02B10
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: running scheduled tasks.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35C6FEC0: Running socket_handler_close task with <Running> status
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: handler 0000025E35C6FE20 shutdown in write dir completed.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: scheduling task 0000025E35D02B38 in-thread for timestamp 0
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35D02B38: Scheduling (null) task for immediate execution
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: detected more scheduled tasks with the next occurring at 0, using timeout of 0.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: waiting for a maximum of 0 ms
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: running scheduled tasks.
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E35D02B38: Running (null) task with <Running> status
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel] - id=0000025E35D02B10: during shutdown, canceling task 0000025E3FE3E170
[TRACE] [2024-12-20T04:21:25Z] [00002848] [event-loop] - id=0000025E3FC820A0: cancelling task 0000025E3FE3E170
[TRACE] [2024-12-20T04:21:25Z] [00002848] [task-scheduler] - id=0000025E3FE3E170: Running tls_timeout task with <Canceled> status
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [channel-bootstrap] - id=0000025E35D34C60: channel 0000025E35D02B10 shutdown with error 1029.
[INFO] [2024-12-20T04:21:25Z] [00002848] [mqtt5-client] - id=0000025E3FCF84A0: emitting connection failure lifecycle event with error code 1029(aws-c-io: AWS_IO_TLS_ERROR_NEGOTIATION_FAILURE, TLS (SSL) negotiation failed)
[INFO] [2024-12-20T04:21:25Z] [00002848] [mqtt5-client] - id=0000025E3FCF84A0: channel tore down with error code 1029(aws-c-io: AWS_IO_TLS_ERROR_NEGOTIATION_FAILURE, TLS (SSL) negotiation failed)
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [mqtt5-client] - id=0000025E3FCF84A0: switching current state from CONNECTING to PENDING_RECONNECT
[DEBUG] [2024-12-20T04:21:25Z] [00002848] [mqtt5-client] - id=0000025E3FCF84A0: next connection attempt in 925 milliseconds

Expected Behavior

Able to connect to MQTT

Current Behavior

TLS negotiation failing

Reproduction Steps

const main = async () => {
  const builder =
    iot.AwsIotMqtt5ClientConfigBuilder.newDirectMqttBuilderWithMtlsFromPath(
      host,
      certPath,
      keyPath
    );
  builder.withConnectProperties({
    30,
    clientId,
  });
  builder.withCertificateAuthorityFromPath(caPath);

  const config = builder.build();

  const client = new mqtt5.Mqtt5Client(config);

  client.on("connectionSuccess",()=>{
    console.log('connectionSuccess')
  })

  client.start();
};

main();

Possible Solution

No response

Additional Information/Context

I tried with the same certificates on another machine(Windows10 22H2) and the connection was successful.
SECURITY_STATUS -2146893816(0x80090008) indicates NTE_BAD_ALGID according to error code reference.

SDK version used

1.21.1

Environment details (OS name and version, etc.)

Windows10 2016 LTSB

[sbSteveK]

Can you get the full logs from earlier than the snippet you've provided? Specifically interested in the import of the cert/key in case there's any additional info there that may help track down the issue.

Could you also provide specifics on how you generated the cert and key in use? It's possible that the LTSB version of Windows doesn't have support for something that was added to 24H2 (which seems to be Windows 11 on a cursory google search).

If you can get the TLS handshake packets using a packet tracer, that would also potentially be helpful.

Thanks!

[k-hay413]

Hi, @sbSteveK
Thank you for your reply.

Can you get the full logs from earlier than the snippet you've provided?

Here are the full logs. (I removed hostnames and addresses of iot-core endpoint from logs.)
log_full.txt

Could you also provide specifics on how you generated the cert and key in use?

The cert and key are generated on console of AWS IoT Core using AWS IoT's certificate authority.

It's possible that the LTSB version of Windows doesn't have support for something that was added to 24H2 (which seems to be Windows 11 on a cursory google search).

Sorry, I wrote it wrong. The correct version is 22H2. I have corrected the comment.

[sbSteveK]

Looking through the logs, it appears as though there is a TCP connection established, followed by a TLS Client Hello packet being sent, and a TLS Server Hello being received and processed. Running InitializeSecurityContextA on the Server Hello is resulting in the NTE_BAD_ALGID error.

Can you capture the Client Hello and Server Hello packets using something like Wireshark and provide them? If you use Wireshark, you should be able to use the filter 'tcp.port == 8883' to capture them.

Current theory is that Windows LTSB may not have compatible Cipher Suites AWS IoT Endpoints. Comparing the Client Hello TLS Cipher Suites and the Cipher Suite used in the Server Hello should let us see whether this is the case.

[k-hay413]

Can you capture the Client Hello and Server Hello packets using something like Wireshark and provide them?

Sorry. The packets cannot be made public because it contains the endpoint address,etc.
But I can provide cipher_suites and signature_algorithms.
If you need any other information, please let me know.

On Client Hello:

Cipher Suites (28 suites)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

Extension: signature_algorithms (len=20)
    Type: signature_algorithms (13)
    Length: 20
    Signature Hash Algorithms Length: 18
    Signature Hash Algorithms (9 algorithms)
        Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
        Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
        Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
        Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
        Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
        Signature Algorithm: ecdsa_sha1 (0x0203)
        Signature Algorithm: SHA1 DSA (0x0202)
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)

On Server Hello:

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

From these results, it seems that even though the client notifies that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) is available, the error actually occurs.

[k-hay413]

Considering the possibility that there may be a problem with Cryptographic Service Provider(CSP) on Windows, I consulted Microsoft's documentation to get some information about CSP.
However, when I ran it on LTSB and 22H2, the results were the same.
At least, there seems to be no difference in the names of the available CSPs. (I don't know the actual difference in functionality between each windows version)

Here are Result:

Listing Available Provider Types.
Provider type    Provider Type Name
_____________    _____________________________________
        1        RSA Full (Signature and Key Exchange)
        3        DSS Signature
       12        RSA SChannel
       13        DSS Signature with Diffie-Hellman Key Exchange
       18        Diffie-Hellman SChannel
       24        RSA Full and AES


Listing Available Providers.
Provider type    Provider Name
_____________    _____________________________________
        1        Microsoft Base Cryptographic Provider v1.0
       13        Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
        3        Microsoft Base DSS Cryptographic Provider
        1        Microsoft Base Smart Card Crypto Provider
       18        Microsoft DH SChannel Cryptographic Provider
        1        Microsoft Enhanced Cryptographic Provider v1.0
       13        Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
       24        Microsoft Enhanced RSA and AES Cryptographic Provider
       12        Microsoft RSA SChannel Cryptographic Provider
        1        Microsoft Strong Cryptographic Provider

The default provider name is "Microsoft Strong Cryptographic Provider"

Enumerating the supported algorithms

     Algid      Bits      Type        Name         Algorithm
                                     Length          Name
    ________________________________________________________
    00006602h    128     Encrypt       4           RC2
    00006801h    128     Encrypt       4           RC4
    00006601h    56      Encrypt       4           DES
    00006609h    112     Encrypt       13          3DES TWO KEY
    00006603h    168     Encrypt       5           3DES
    00008004h    160     Hash          6           SHA-1
    00008001h    128     Hash          4           MD2
    00008002h    128     Hash          4           MD4
    00008003h    128     Hash          4           MD5
    00008008h    288     Hash          12          SSL3 SHAMD5
    00008005h    0       Hash          4           MAC
    00002400h    1024    Signature     9           RSA_SIGN
    0000a400h    1024    Exchange      9           RSA_KEYX
    00008009h    0       Hash          5           HMAC

[sfod]

I don't see any problems in configuration you provided.

I'll try to reproduce the issue on Windows Server 2016 which has the same build version as Windows 10 2016 (see https://learn.microsoft.com/en-us/windows/release-health/release-information and https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info). But there are some differences between server and non-server versions, so it's a long shot.

Meanwhile, could you also try enabling schannel logging and examine the schannel events after TLS handshake failure? They might provide some insight.