TLS handshake failure
Product: Agilent Connected Instrument Device (CID) for OpenLab CDS Audience: Agilent Support, IT/network administrators Support reference: Network / firewall configuration
The diagnostic procedures on this page are intended for IT administrators familiar with Linux commands. Incorrect use of the underlying tools can misconfigure the CID and render it inoperable. Proceed only if you are comfortable working in a Linux environment.
Symptom
The CID can establish a TCP connection to an external endpoint on port 443, but the HTTPS session fails immediately during the TLS handshake. The connection is terminated by a network device before any encrypted data is exchanged. This may manifest as:
- TLS / SSL errors appear in CID agent logs against external CID endpoints (for example,
SSL_ERROR_SYSCALLor a connection reset during the TLS handshake). - Before activation, the CID emits 2 beeps when it cannot contact a CID Hub registration API and retries every 30 seconds, but TCP port 443 blocked has been ruled out and TCP/443 is confirmed reachable. If activation remains blocked for five minutes, the CID restarts its network service and agent.
- In CID Hub, the Recent Activity view can show
Could not establish IoT connection with <mqtt_endpoint>. Restarting network services and agentwhen the CID reaches the IoT endpoint but cannot establish the connection.
Root cause
When TCP connectivity is confirmed but the TLS handshake fails, the most common causes are:
- Domain or SNI-based blocking. The firewall reads the Server Name Indication (SNI) field in the TLS Client Hello and drops connections to disallowed domains (for example
*.amazonaws.com). - TLS version filtering. The firewall is configured to block specific TLS versions, preventing the handshake from completing.
- Firewall policy resetting TLS traffic. A security rule resets the connection upon detection of TLS negotiation to certain destinations.
A certificate validation error presents differently: the connection returns a certificate, but the CID cannot validate it. See Certificate validation errors.
Confirm this is the right document
Use the following table to confirm that the TLS handshake is the failing layer.
| Where you came from | Next step |
|---|---|
| You ran Verify CID internet connectivity and all endpoints reported TCP/443 reachable, but the CID still fails with TLS / SSL errors | This is the correct document. Continue below. |
| You arrived from TCP port 443 blocked after confirming TCP/443 is reachable | This is the correct document. Continue below. |
You arrived from Beep codes on startup Step 2 or Step 4 with nc -zv succeeding but the beep pattern persisting | This is the correct document. Continue below. |
| TCP/443 is blocked or the connection times out | See TCP port 443 blocked instead. |
| Logs or earlier output show a certificate validation error | See Certificate validation errors instead. |
| You have not yet identified that TLS is the failing layer | Run Verify CID internet connectivity first. |
Affected services
A TLS handshake failure affects every CID service that communicates over HTTPS: activation and registration, telemetry to CID Hub, AWS IoT messaging, software downloads, and Microsoft CDN access. For the complete list of internet endpoints the CID requires, see the Internet requirements section of System requirements.
Prerequisites
- Command-line access to the CID via SSH or direct console connection.
- The connectivity tester results, or the failing endpoint hostname from logs or CID Hub Recent Activity.
- Authorization from your IT or network security team to execute network diagnostic commands, if applicable.
Diagnostic steps
Step 1. Observe where the TLS handshake terminates
Initiate a full TLS negotiation and capture detailed output to identify exactly where the connection is closed.
# Replace <hostname> with the failing endpoint identified from
# the connectivity tester results or CID Hub Recent Activity.
# Example: hub-ac-registration-api.prd-51.aws.agilent.com
openssl s_client -connect <hostname>:443 -debug 2>&1 | head -40
Healthy output: the server returns a full certificate chain, followed by session details.
Output confirming this failure mode: the connection terminates immediately after the Client Hello with no response from the server, for example:
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <hostname>:443
* Closing connection 0
| Result | Next step |
|---|---|
| Connection closes immediately after Client Hello with no server response | The firewall is dropping the TLS handshake. Continue to Step 2. |
| Server returns a certificate, but certificate validation fails | See Certificate validation errors. |
| Server returns a certificate with the expected public issuer, and the handshake completes | TLS is succeeding to this endpoint. Recheck which endpoint is actually failing. |
Collect this output for your network security team.
Step 2. Compare TLS versions
Run both commands to compare TLS connections to the failing endpoint. A difference in results does not by itself identify a firewall rule.
# Replace <hostname> with the failing endpoint identified from
# the connectivity tester results or CID Hub Recent Activity.
# Example: hub-ac-registration-api.prd-51.aws.agilent.com
curl -v --tlsv1.2 --tls-max 1.2 https://<hostname>
curl -v --tlsv1.3 https://<hostname>
| Result | Next step |
|---|---|
| One TLS version succeeds and the other fails | Share both outputs with Support and your network team to check TLS compatibility and network policy. |
| Both fail | These results do not identify the cause. Continue to Step 3 to check which endpoints fail. |
Step 3. Determine the scope of the block
Identify whether the block is limited to one endpoint or applies broadly to a class of domains. This scopes the firewall change your network team needs to make.
curl -v https://hub-ac-registration-api.prd-51.aws.agilent.com
curl -v https://a3cb4mwmdz2oep-ats.iot.us-east-1.amazonaws.com
curl -v https://agilent-aws-prd-51-ac-images.s3.amazonaws.com
curl -v https://microsoft.com
| Result | Next step |
|---|---|
| All four fail at TLS | SNI-based or broad outbound HTTPS filtering is in effect. Add SNI / domain allowlist rules for the affected service group; see Resolution. |
Only *.amazonaws.com endpoints fail | The firewall is targeting AWS endpoints by SNI. Add SNI / domain allowlist rules for the AWS service group; see Resolution. |
Only *.agilent.com endpoints fail | The firewall is targeting Agilent endpoints by SNI. Add SNI / domain allowlist rules for the Agilent service group; see Resolution. |
| Only one endpoint fails | A domain-specific SNI rule is in effect. Add that domain to the allowlist individually; see Resolution. |
| A server returns a certificate, but certificate validation fails | See Certificate validation errors. |
Share the results with your network security team. For the complete list of required hostnames, see the Internet requirements section of System requirements.
Step 4. Characterize the network path
If Step 1 showed the handshake terminating with no server response, identify where in the path the reset originates. The connectivity tester's traceroute already shows hop-by-hop progress; mtr adds per-hop packet loss.
# Replace <hostname> with the failing endpoint identified from
# the connectivity tester results or CID Hub Recent Activity.
# Example: hub-ac-registration-api.prd-51.aws.agilent.com
mtr --report --tcp --port 443 <hostname>
Provide the output to your network security team along with the Step 1 capture. A path that loses packets at an internal hop indicates the TLS reset originates from a corporate appliance rather than the destination.
| Result | Next step |
|---|---|
| Packet loss begins at an internal hop before the destination | The TLS reset originates from a corporate appliance. Investigate the dropping hop with your network team; see Resolution. |
| No loss until the destination, and the destination resets the handshake | The reset is not from an intermediate appliance. Recheck the SNI / domain scope in Step 3. |
| The server returns a certificate, but certificate validation fails | See Certificate validation errors. |
Resolution
Provide the diagnostic output from the diagnostic steps to your network security team and request the appropriate action.
| Recommended action | Applicable when |
|---|---|
| Investigate TLS compatibility and network policy with Support and your network team | One TLS version succeeded and the other failed in Step 2 |
| Add SNI / domain allowlist rules for the affected service group | Step 3 identified one or more blocked domain groups |
| Investigate the dropping hop with your network team | Step 4 identified an internal hop that resets the connection |
| Investigate the certificate validation error | The server returned a certificate that the CID could not validate; use Certificate validation errors |
Related documents
Last updated: