Resolving WinCC Cloud Connector Test Connection Failure

The WinCC Cloud Connector ships as an application on the Siemens Industrial Edge (IE) ecosystem and bridges a WinCC station to MQTT-based cloud platforms such as MindSphere, AWS IoT Core, and Azure IoT Hub. On WinCC V7.5 SP2 Update 13 (internal build K7.5.2.13), the configuration dialog may report "Test connection failed. Please check the settings specified." even when the same broker is reachable from MQTTX, Mosquitto, or another external client. The error does not point to a single field; it indicates that the TLS handshake, DNS resolution, or TCP path to the broker failed during the test call. This reference walks through the field-proven diagnostic sequence to isolate and resolve the failure.

Problem Description

In the Cloud Connector Configurator, the engineer enters the broker URL, port, MQTT client ID, credentials, and certificate path, then selects Test Connection. The dialog returns the message:

Test connection failed. Please check the settings specified.

The dialog does not return a numeric error code. Engineers must inspect the Windows Event Log, the Cloud Connector container log (when running in IE), or the IEM audit log to find the cause. Common collateral symptoms reported on the same install are:

• MQTTX, MQTT.fx, or mosquitto_pub can connect to the same broker without error.
• The WinCC station's browser or curl can reach the broker URL.
• The Cloud Connector service starts and stays in Running state, but no telemetry reaches the broker.
• A second instance of the Cloud Connector on the same station also fails the test, even with a different client ID.

These symptoms point the diagnosis toward certificate trust, path, or scheme, not toward credentials or topic configuration.

Affected Versions and Components

The behavior applies to the following versions and firmware baselines that the source thread and Siemens manuals document:

The WinCC V8.0 configuration manual 109818894 documents the same Cloud Connector configuration dialog and is a useful cross-reference for newer installations. The Industrial Edge Cloud Connector overview at docs.industrial-operations-x.siemens.cloud confirms the same field layout for the IE variant.

Root Cause Analysis

The "Test connection failed" text is a catch-all wrapper around four primary failure classes. Treat it as a symptom and run the diagnostic sequence in the order shown:

1. L3/L4 path failure - TCP to the broker host/port is blocked by firewall, NAT, proxy, or routing.
2. DNS resolution failure - the WinCC station or IED cannot resolve the broker hostname.
3. TLS handshake failure - the certificate chain is invalid, expired, untrusted, or the cipher/ALPN does not match.
4. MQTT credential failure - client ID, username, password, or client certificate does not match broker policy.

Steps 1-3 are the most frequent causes on K7.5.2.13. Step 4 is rarer because WinCC shows a more specific CONNACK reason code when the broker rejects a session with valid TLS. The remainder of this article provides a diagnostic and remediation path for each class.

Network Prerequisites and Firewall Configuration

The Cloud Connector establishes an outbound TLS session from the IE Device (or from the WinCC host in non-IE installs) to the broker. The following default ports must be allowed in the corporate firewall and the Windows Defender Firewall on the WinCC station:

Open the ports in the perimeter firewall and create a Windows Firewall rule on the WinCC host:

netsh advfirewall firewall add rule name="WinCC Cloud Connector 8883" dir=out action=allow protocol=TCP localport=any remoteport=8883 remoteip=<broker-ip>
netsh advfirewall firewall add rule name="WinCC Cloud Connector 443"  dir=out action=allow protocol=TCP localport=any remoteport=443  remoteip=<broker-ip>
netsh advfirewall firewall add rule name="WinCC Cloud Connector 8443" dir=out action=allow protocol=TCP localport=any remoteport=8443 remoteip=<broker-ip>

Verifying TCP reachability with telnet

Confirm the L4 path before touching TLS settings. Open an elevated command prompt on the WinCC station (or on the IED that hosts the Cloud Connector container):

telnet <broker-host> 8883
telnet <broker-host> 443
telnet <broker-host> 8443

A successful connection shows a blank screen with a cursor (or a TLS handshake prompt on port 443). A "Connecting to ... Could not open connection" response indicates a blocked path. The same command works against localhost when the broker runs on the same machine, which is useful for separating network issues from TLS issues.

DNS resolution

If telnet returns "Could not resolve host", the WinCC station cannot reach a working DNS server. Validate with:

nslookup <broker-host>
nslookup <broker-host> <dns-server>
Resolve-DnsName <broker-host> -Type A

Set a stable DNS server in the adapter properties or in /etc/resolv.conf on the IED if the DHCP-supplied DNS is blocked by the firewall. A Cloud Connector container inside Docker uses the DNS server from the host; an IED with NetworkManager-managed DNS will pick up the new value after a daemon restart.

TLS Certificate Validation

The Cloud Connector performs a strict TLS handshake. If the certificate chain is broken, the test fails with no further detail. The chain consists of three artifacts:

Verify the chain from the command line before loading it into the configurator:

openssl s_client -connect <broker-host>:8883 -CAfile ca.crt -cert client.crt -key client.key -showcerts
openssl x509 -in ca.crt -noout -subject -issuer -dates
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl verify -CAfile ca.crt client.crt

The expected outputs are:

• Verify return code: 0 (ok) from openssl verify.
• Verification: OK at the end of openssl s_client.
• Certificate notAfter date later than the current date for both the CA and the client certificate.
• Subject Alternative Name (SAN) on the broker certificate that matches the broker hostname.

Loading certificates into the Cloud Connector

The Cloud Connector Configurator exposes three fields under Security:

1. CA Certificate - browse to the PEM-encoded root or intermediate.
2. Client Certificate - browse to client.crt.
3. Client Key - browse to client.key. If the key is encrypted, the configurator prompts for the passphrase.

On the IE Device, the files persist in the container volume /etc/cloudconnector/certs. The configurator applies them only after a Save & Deploy cycle, not on a simple Test Connection. On a native WinCC host, the files live at C:\ProgramData\Siemens\WinCC\CloudConnector\certs\ and the same Save & Deploy cycle applies.

WinCC Cloud Connector Configuration

Open the Cloud Connector Configurator from the IEM web UI (Industrial Edge Management) or directly from the IED local UI. The dialog documented in the WinCC V8.0 manual 109818894 uses the same field layout as K7.5.2.13.

When the WinCC station runs the Cloud Connector directly (without IE), the configurator lives at C:\Program Files\Siemens\Automation\WinCC\CloudConnector\CloudConnectorConfigurator.exe and stores the configuration in C:\ProgramData\Siemens\WinCC\CloudConnector\config.yaml. The IEM-hosted configurator mirrors the same fields to the container volume on Save & Deploy.

Field-level sanity check

• URL scheme: ssl:// for TCP+TLS, tcp:// for plaintext, ws:// / wss:// for WebSocket transport.
• Port matches scheme: ssl:// pairs with 8883, wss:// with 443.
• No trailing slash on the URL; the connector treats broker:8883/ differently from broker:8883 on some brokers.
• Client ID is unique; reusing a Client ID across two connectors disconnects the older session.
• Username/Password are not populated when mTLS is used; populating both can cause the broker to reject the connection.

Broker Reachability Diagnostics

If telnet and DNS succeed, isolate whether the broker rejects the session by running an external MQTT client from the same WinCC host with the same certificates:

mosquitto_sub -h <broker-host> -p 8883 \
  --cafile ca.crt --cert client.crt --key client.key \
  -i test-client -t '$SYS/#' -v
mosquitto_pub -h <broker-host> -p 8883 \
  --cafile ca.crt --cert client.crt --key client.key \
  -i test-client -t test/topic -m "hello" -q 1

If mosquitto_sub returns a CONNACK and mosquitto_pub writes a message, the broker is healthy and the issue is on the Cloud Connector side. Move on to the log inspection section.

If mosquitto_sub returns "SSL routines:ssl3_read_bytes:tlsv1 alert protocol version" or "certificate verify failed", the broker is rejecting the handshake. Match the broker's TLS floor (TLS 1.2 minimum for most modern brokers, TLS 1.3 supported on HiveMQ 4.x and AWS IoT Core). Adjust the Cloud Connector's tls_min_version in the configuration YAML:

mqtt:
  broker_url: ssl://broker.example.com:8883
  client_id: wincc-edge-001
  tls:
    ca_file: /etc/cloudconnector/certs/ca.crt
    cert_file: /etc/cloudconnector/certs/client.crt
    key_file: /etc/cloudconnector/certs/client.key
    min_version: TLSv1.2
    verify: true
publish:
  qos: 1
  keep_alive_seconds: 60
  topic_prefix: ""

Authentication and Topic Configuration

Cloud brokers use one of two authentication flows:

For mTLS, leave Username and Password blank. For username/password, the broker policy must include the credentials; check the broker's access log for an auth line that shows the Client ID and the rejection reason (for example, bad username or password on Mosquitto, NotAuthorized on HiveMQ).

The Topic Prefix field is required for MindSphere and follows the structure ie/m/j/<tenant>/<asset>. Generic brokers accept any topic. The Cloud Connector publishes each mapped tag as a JSON payload on the topic <prefix>/<tag-name>, with the JSON envelope containing timestamp, value, and quality code.

Industrial Edge Integration Path

On the IE ecosystem, the Cloud Connector is installed as an app on the IED and configured from the IEM. The integration sequence is:

1. Upload the Cloud Connector app to the IEM catalog.
2. Deploy the app to the target IED.
3. Open the Cloud Connector Configurator from the IEM web UI (Apps > Cloud Connector > Configure).
4. Enter the broker settings, certificates, and tag mapping.
5. Select Test Connection; the configurator reaches the broker via the IED network stack, not via the WinCC station.
6. Select Save & Deploy; the configurator writes to the container volume and restarts the connector.

The Industrial Edge documentation Cloud Connector - Industrial Edge Data Connection describes the same flow at v1.17.1 and confirms that the configurator is hosted in the IEM rather than the IED local UI.

If the IED has been promoted to a managed device with a corporate proxy, the Cloud Connector traffic routes through the IEM proxy. The proxy must allow the same 8883/443/8443 outbound ports, and the proxy CA must be added to the IED truststore at /etc/ssl/certs. A typical enterprise setup uses an HTTPS proxy on port 8080 or 3128 and the connector must be configured with the proxy host and port before the Test Connection will succeed.

Verification and Log Analysis

After applying the fix, run a structured verification. Capture the data at each step to confirm the test connection now succeeds.

1. Network: re-run telnet <broker> 8883 from the WinCC host or IED and confirm a blank screen with cursor.
2. TLS: re-run openssl s_client and confirm Verify return code: 0 (ok).
3. Cloud Connector test: re-select Test Connection in the configurator; the dialog should display Connection successful.
4. End-to-end: subscribe with mosquitto_sub and observe a published payload from WinCC within the configured publish interval (default 1000 ms).

Where to find the logs

Search the log for the phrases "broker connection failed", "tls handshake", "auth failed", or "unknown host". Each phrase maps to a remediation:

Common Configuration Pitfalls

The following configuration errors are the most frequent causes of Test connection failed on K7.5.2.13 and should be checked first when triaging a new install.

1. Wrong URL scheme - the configurator silently accepts tcp:// when the broker requires ssl://. The handshake fails with no further detail. Always cross-check the scheme against the broker's documentation.
2. Stale ca.crt - the CA rolled over on the broker side; the IED still has the old CA. Re-export the chain from the broker and redeploy the truststore.
3. Expired client certificate - industrial certificates are typically valid for 12 months. Check notAfter with openssl x509 -noout -dates on every restart.
4. Encrypted private key with no passphrase - the configurator fails to read the key. Provide the passphrase or decrypt the key with openssl rsa -in client.key -out client.unencrypted.key.
5. Proxy in the path that is not declared in the IEM - the IED uses a corporate proxy that the IEM has not been told about. The IEM proxy settings must be mirrored on the IED at /etc/environment or in the Cloud Connector's HTTPS_PROXY variable.
6. Duplicate Client ID - two Cloud Connector instances use the same Client ID. The broker disconnects the second one with identifier rejected and the test returns a generic failure.
7. WinCC service account not allowed outbound - the WinCC runtime runs under a service account that has no outbound network privileges. The Test Connection originates from the WinCC service context, not the interactive user, so a local admin account on the desktop does not test the same path.
8. Broker hostname in URL but TLS SAN is on a different name - the certificate is issued for mqtt.example.com but the URL points to broker.example.com. The handshake fails on SAN mismatch.

Migration to WinCC Unified Cloud Connector

Projects on K7.5.2.13 that are upgrading to WinCC Unified (V18/V19) or WinCC V8.0 should validate that the Cloud Connector app on the IEM is the Unified-compatible variant. The WinCC V8.0 configuration manual 109818894 documents the same configurator dialog and accepts the same config.yaml schema, so an existing configuration can be re-deployed to the new runtime without re-keying the broker details. Update the IED firmware to the latest IE Runtime release first, then deploy the new Cloud Connector container alongside the legacy one and migrate one tag group at a time.

Use the Cloud Connector application example 109760955 as a reference for a working WinCC V7.5 SP2 to MindSphere deployment. The example includes a sample ca.crt, client.crt, and client.key and a config.yaml for a Mosquitto broker on localhost, which is a useful smoke test for isolating the configurator from the network. Stand up the Mosquitto broker in a container on the same WinCC host, point the Cloud Connector to ssl://localhost:8883, and confirm Connection successful before pointing the connector at the production broker.

FAQ