The receiving gateway shows the approved third connection with Unknown for both Gateway Name and Redundancy Role. Follow the packet from the outgoing gateway: the decisive failure occurs locally while its Java HTTP/WebSocket client prepares TLS, before a usable secure session can exchange gateway identity metadata.
Where does the Gateway Network data path stop?
The outgoing gateway initiates the request, the configured network path carries it toward the receiving gateway, and TLS must establish a secure transport before the Gateway Network protocol can complete its metadata exchange. The incoming entry proves that some connection-management traffic reached the receiver, but the Unknown fields show that enrollment did not become a complete operating session.
The outgoing gateway logged an IllegalArgumentException at 2026/09/03 15:11:25:
Unsupported CipherSuite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
at java.base/sun.security.ssl.SSLSocketImpl.setEnabledCipherSuites(...)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(...)
at com.inductiveautomation.metro.impl.protocol.websocket.WebSocketConnection$RunDownload.run(...)This is not a receiver-side certificate rejection or a normal cipher-negotiation failure. The local Java TLS implementation rejects the configured cipher-suite name when the HTTP client calls setEnabledCipherSuites. Socket layering and the WebSocket connection cannot finish, so the remote gateway cannot obtain the name and redundancy role through the completed session.
| Data-path stage | What to inspect | Decision |
|---|---|---|
| Outgoing gateway process |
wrapper.log at the connection attempt |
The unsupported-suite exception places the current stop here. |
| Host network interface | Link state, route, and local firewall | Check layer one and reachability first, but they do not explain this Java exception. |
| Intermediate network | Route, firewall, proxy, or TLS inspection path | Investigate if a basic TCP connection cannot reach the configured destination. |
| Receiving gateway listener | Configured address and port | Confirm that the outgoing definition targets the same listener used by the two working gateways. |
| TLS and WebSocket setup | Effective cipher list in the outgoing process | Remove or replace the unsupported token before expecting metadata. |
Which troubleshooting approach fits this failure?
| Approach | What it tests | Result in this installation | Use now? |
|---|---|---|---|
| Regenerate the third gateway certificate | Damaged, stale, or mismatched identity material | Did not restore the name or role | No; the exception occurs while applying a cipher list, before certificate validation decides the session. |
| Regenerate the gateway name | Stale identity metadata | Did not change the Unknown fields |
No; a new name cannot cross a TLS session that never completes. |
| Remove the Web Server cipher whitelist | Gateway web-server TLS configuration | The only listed whitelist was removed, with no improvement | Useful comparison, but it may be the wrong configuration scope or not yet effective in the running process. |
| Trace the effective outgoing TLS configuration | The value passed to the Java HTTP/WebSocket client | The log identifies the rejected token | Yes; this follows the failing call path directly. |
Focus on the effective cipher configuration used by the third gateway's outgoing connection. The two working gateways provide known-good comparison points. Compare settings and runtime state rather than repeatedly changing certificates.
What should be checked before changing TLS settings?
Layer one first. Confirm that the third host has a live interface and can establish TCP connectivity to the receiver's configured address and listener port. Read the destination from the outgoing connection definition; the evidence does not identify an IP address or port. The 8060 text inside the thread name gn-bpmignition:8060-recv-3 must not be treated as a verified network port.
| Field | Third gateway | Working gateways | Required comparison |
|---|---|---|---|
| Destination address | Read from outgoing connection | Read from each working definition | Same intended receiving gateway |
| Destination port | Read from outgoing connection | Read from working definitions | Same active listener unless the design intentionally differs |
| Connection time | Correlate with 2026/09/03 15:11:25
|
Capture a successful interval | Compare logs from the same test window |
| Operating system | Windows Server 2022 | Windows 10/11 | Treat as a configuration lead, not the root cause by itself |
| Cipher configuration | Find every source containing the rejected token | Record the effective working values | Identify the configuration difference that reaches the outgoing client |
If TCP reachability fails, repair the physical or network path before TLS work. If TCP connects and the same exception appears, continue at the outgoing process; packet capture alone will not reveal a TLS negotiation because Java rejects the suite before a valid ClientHello can be built.
Why did removing the Web Server whitelist not clear the error?
A web-server cipher whitelist controls inbound HTTPS behavior unless the product explicitly shares that setting with its outgoing client. The failing stack belongs to an Apache HTTP client creating a layered SSL socket for WebSocketConnection$RunDownload. That scope can differ from the inbound web listener.
Three recurring conditions explain an unchanged exception: another configuration source still supplies TLS_KRB5_WITH_3DES_EDE_CBC_SHA; the running Java process has not reloaded the edited value; or the connection inherited a stored value outside the visible Web Server field. Search configuration exports, service launch options, environment-based overrides, and connection-specific TLS settings for the exact token. Compare the third installation against a working gateway at the same configuration locations.
The operating-system difference may explain why only one installation has a distinct security configuration, but the Java exception already names the direct cause: the running TLS implementation will not accept that suite in its enabled list. Prove the effective process value instead of attributing the fault to Windows Server 2022 alone.
How should the outgoing TLS configuration be corrected?
- Record the third gateway's outgoing destination, approval state, and current TLS-related settings. Preserve the exact log timestamp and stack trace for comparison.
- Search every applicable gateway, service, and Java launch configuration for
TLS_KRB5_WITH_3DES_EDE_CBC_SHA. Check connection-specific settings separately from Networking > Web Server parameters. - Export or record the equivalent cipher settings from one working gateway. Compare configuration scope as well as displayed values; an empty field can mean inherited defaults rather than a literal empty enabled-suite list.
- Remove the unsupported token from the outgoing client's configured suite list. If an explicit list is required, populate it only with suite names accepted by the installed Java runtime and permitted by the receiving gateway's policy; obtain those names from the runtime and product diagnostics rather than guessing.
- Apply the change using the gateway's supported configuration workflow. If the setting is loaded only at process startup, restart the affected gateway service during an approved outage.
- Retry the outgoing connection and approve a new request only if the receiver presents one. Do not regenerate the certificate or name again unless the next log shows an identity or trust failure.
How is the repair verified end to end?
Follow the same path after the change. First confirm TCP connectivity to the configured receiver address and port. Then watch wrapper.log through a fresh connection attempt. The specific IllegalArgumentException and Unsupported CipherSuite line must not recur.
Next, verify that TLS and WebSocket setup remain established rather than entering a retry loop. On the receiving gateway, refresh Incoming Connections and confirm that the third entry reports its configured Gateway Name and Redundancy Role instead of Unknown. Finally, exercise the Gateway Network function that depends on this route and correlate both gateway logs over the same test interval.
FAQ
How do I fix an Ignition gateway that shows Unknown for Gateway Name?
Read wrapper.log on the outgoing gateway during a retry. If it reports Unsupported CipherSuite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA, remove that token from the effective outgoing HTTP/WebSocket TLS configuration, apply the change, and reconnect.
How do I know whether the certificate is causing the Unknown name?
Use the first exception in the outgoing connection path. A failure in setEnabledCipherSuites occurs before certificate validation, so regenerating the certificate does not address this error.
How do I find the correct Gateway Network port?
Read it from the outgoing connection definition and the receiving gateway's listener configuration, then compare it with the two working connections. Do not infer the port from gn-bpmignition:8060-recv-3; that text is a thread identifier in the log.
How do I verify the Gateway Network connection is fully repaired?
Trigger a fresh connection, confirm the unsupported-cipher exception does not return, and verify that the receiver displays the configured Gateway Name and Redundancy Role. Complete the check by exercising the Gateway Network function and confirming successful activity in both gateway logs during the same interval.