- Newest
- Most votes
- Most comments
Sorry for the long no response, the issue was that the network configuration was the root cause
What version of Greengrass are you using? What is your configured TLS policy in IoT Core? https://docs.aws.amazon.com/iot/latest/developerguide/iot-endpoints-tls-config.html
Your device uses tls 1.3 by default and maybe you have selected a policy that doesn't support 1.3.
Do you have the amazon root CA in rootCaPath?
Based on the information provided, it appears you're experiencing SSL/TLS handshake issues during the Greengrass deployment process. This is likely related to network or security configuration problems. Here are some potential causes and solutions to consider:
-
Certificate issues: Ensure that your device's system time is accurate and synchronized. Incorrect system time can cause certificate validation failures.
-
Firewall or proxy interference: Check if there's any firewall or proxy in your network that might be intercepting or blocking the SSL/TLS connections. Try temporarily disabling any such security measures to see if it resolves the issue.
-
TLS version mismatch: Verify that your device supports the TLS version required by AWS IoT. You may need to update your device's SSL/TLS libraries or configure it to use a compatible TLS version.
-
Network instability: Intermittent network issues can cause handshake failures. Try connecting to a different network or use a wired connection if possible to rule out Wi-Fi related problems.
-
DNS resolution: Although you mentioned that nslookup is returning the same IP addresses as other working devices, double-check that your device is consistently resolving AWS endpoints correctly.
-
IoT policy: Review your AWS IoT policy to ensure it grants the necessary permissions for your device to connect and perform required operations.
-
Credentials: Verify that the device certificate and private key are correctly installed and accessible to the Greengrass core.
-
Endpoint configuration: Double-check that you're using the correct ATS endpoint for your region in the Greengrass configuration.
If none of these solutions work, you may need to enable more verbose logging for the Greengrass core to get additional diagnostic information. You can also try using network analysis tools like Wireshark to capture and analyze the SSL/TLS handshake process for more detailed insights into where the failure is occurring.
Sources
AWS Greengrass Manual Provisioning is failing because of error=TLS (SSL) negotiation failed | AWS re:Post
I want to IoT device connect AWS cloud by greengrass. | AWS re:Post
Greengrass Mqtt5 SESSION_TAKEN_OVER | AWS re:Post
Relevant content
- asked 4 years ago

Nucleus version is 2.12.2, TLS policy in IoT Core is IoTSecurityPolicy_TLS12_1_0_2015_01, my device supports TLS 1.2 and 1.3, there is a log in greengrass.log {"thread":"pool-3-thread-3","level":"DEBUG","eventType":null,"message":"socket.getSupportedProtocols(): [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3, SSLv2Hello], socket.getEnabledProtocols(): [TLSv1.3, TLSv1.2]","contexts":{},"loggerName":"software.amazon.awssdk.http.apache.internal.conn.SdkTlsSocketFactory","timestamp":1737612820072,"cause":null} But I also confirmed executing openssl s_client -connect <DEVICE_ID>:443 -tls1_2 and -tls1_3 Yes, I have amazon root CA in rootCaPath and the certificate exists and is the same as in other devices.
Can you try changing your IoT Core TLS policy to IoTSecurityPolicy_TLS13_1_2_2022_10
I have thousands of devices working on that policy, I don't want to risk environment stability just for one broken device
I understand your situation.
The error 'Remote host terminated the handshake' suggests there's an SSL/TLS connection issue between your device and AWS IoT Core. Your MQTT connection works fine but HTTP doesn't. Since MQTT is working, we can confirm your certificates are valid. This likely means the issue is related to either TLS protocol settings or cipher suite compatibility.
To further troubleshoot, please restart Greengrass with -Djava.security.debug=all and check the logs from stdout (via journalctl if using systemd) for any SSL/TLS-related errors. Maybe search for "fatal" or "error"