TLS negotiation error #538
Comments
k-hay413
added
bug
|
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! |
|
Hi, @sbSteveK
Here are the full logs. (I removed hostnames and addresses of iot-core endpoint from logs.)
The cert and key are generated on console of AWS IoT Core using AWS IoT's certificate authority.
Sorry, I wrote it wrong. The correct version is 22H2. I have corrected the comment. |
|
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. |
Sorry. The packets cannot be made public because it contains the endpoint address,etc. On Client Hello: On Server Hello: 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. |
|
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. Here are Result: |
|
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. |
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:
Expected Behavior
Able to connect to MQTT
Current Behavior
TLS negotiation failing
Reproduction Steps
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
The text was updated successfully, but these errors were encountered: