Resolving WinCC OPC UA Authentication Loop with KEPServerEX

Problem Overview

A WinCC V7.3 SCADA station configured as an OPC UA client cannot complete a session against a KEPServerEX OPC UA server the moment user authentication is enabled. The configuration exhibits the following diagnostic fingerprint:

• With Security: None and Authentication: Anonymous: tag browse and tag subscription both succeed.
• With Authentication: Username/Password enabled: tag browse succeeds, but selecting tags and committing them to the WinCC tag database yields a permanent connection failure.
• With intentionally wrong credentials: tag browse itself fails immediately, confirming that user identification is reaching the server.
• A third-party OPC UA test client (e.g. UA Expert) connects against the identical KEPServerEX endpoint using the identical credential pair without issue.
• Wireshark capture shows a repeating loop of OPC UA TCP messages on the configured port (default 49320): HEL → ACK → OPN (OpenSecureChannel) → MSG (GetEndpoints) → CLO (CloseSecureChannel). No CreateSession, no ActivateSession, no Read traffic ever appears.

The fact that the loop terminates immediately after GetEndpoints is the load-bearing diagnostic: the client receives the server's certificate in that response (or in the associated OPN handshake) and refuses to advance because the certificate is not in its trusted store.

Wireshark Trace Interpretation

OPC UA Binary Protocol message types appear in Wireshark under the dissector opcua. The relevant filter expressions are:

opcua && tcp.port == 49320
opcua.ServiceNodeId == 428 (GetEndpoints)
opcua.ServiceNodeId == 461 (CreateSession)
opcua.ServiceNodeId == 467 (ActivateSession)
opcua.ServiceNodeId == 631 (CloseSecureChannel)

NodeIds above are OPC UA namespace 0 standard service identifiers. A healthy authenticated handshake produces this sequence:

1. HEL – client proposes protocol version, receive buffer size, endpoint URL, and max message size.
2. ACK – server acknowledges with its own buffer parameters.
3. OPN – OpenSecureChannelRequest: client proposes SecurityPolicyUri and MessageSecurityMode; server returns its ServerCertificate byte string.
4. MSG – GetEndpointsRequest: client enumerates available endpoints; server returns the full endpoint description list, each containing the server certificate thumbprint.
5. MSG – CreateSessionRequest: would normally follow; never arrives in the failing case.
6. MSG – ActivateSessionRequest: would normally follow.
7. CLO – CloseSecureChannelRequest: server-side timeout teardown.

If step 5 is missing and the channel closes, the OPC UA stack has aborted because it could not validate the server certificate against its application instance certificate store. WinCC's OPC UA channel runtime moves untrusted certificates into a rejected folder rather than discarding them, which is the operational clue.

Root Cause Analysis

The OPC UA specification (OPC UA Part 4, Services, and Part 6, Mappings) requires both peers to validate the application instance certificate chain before any session-bound service may be issued. WinCC V7.3 implements this through a local PKI store with three directories:

The default WinCC OPC UA client runtime path on a 64-bit Windows host with 32-bit WinCC V7.3 is:

C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\certs
C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\rejected
C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\Issuer\certs
C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\private

When WinCC receives the KEPServerEX self-signed server certificate (or any certificate whose issuer chain it cannot verify against the local trust anchors), it writes the DER file into rejected and aborts the channel. The runtime does not log this drop through WinCC diagnostics — the failure presents purely as a connect retry storm — which is why the symptom is so easy to misdiagnose as an authentication or endpoint selection problem.

Prerequisites

Before executing the resolution procedure, confirm the following:

1. WinCC V7.3 SP3 Update 4 or newer installed. Apply the latest Hotfix collection from Siemens KB 109742642 — WinCC V7.3 Updates; several OPC UA channel bugs in early V7.3 builds produced identical symptoms.
2. KEPServerEX V6.x (V6.4 or newer recommended). The OPC UA server plugin is enabled in the project.
3. The KEPServerEX endpoint is reachable from the WinCC station. Verify with PowerShell:

   Test-NetConnection -ComputerName <kepwarehost> -Port 49320

4. A KEPServerEX user identity has been defined in Configuration → User Manager with the correct username/password and the OPC UA user group assigned.
5. The OPC UA Client Channel has been added inside the WinCC project as a separate channel — do not reuse an unsecured channel for an authenticated endpoint.

Step-by-Step Resolution

Step 1 — Stop the WinCC Runtime

Close WinCC Explorer or use the WinCC service stop sequence so the OPC UA client runtime releases its certificate store lock:

net stop "WinCC_Connectivity_Service"
net stop "CCOPCUAWrapper"

Process names vary by installation language. Confirm no CCOPCUA.exe instances remain with Task Manager.

Step 2 — Inspect the Rejected Folder

Open the rejected directory from the path above. Sort by Date modified descending. The most recent .der file is the KEPServerEX server certificate that was quarantined during the last connection attempt.

dir "C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\rejected" /O:D

Inspect the certificate with certutil to confirm subject and thumbprint:

certutil -reject <filename.der

The subject CN must match the KEPServerEX endpoint host name. If it does not, you have the wrong endpoint configured in the WinCC OPC UA channel — fix that first.

Step 3 — Trust the Server Certificate

Move the DER file from rejected to certs. Do not copy with Windows Explorer while the OPC UA runtime is running; use an elevated command prompt:

move "C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\rejected\*.der" "C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\certs\"

Step 4 — Confirm the WinCC Client Certificate Exists

WinCC auto-generates its own application instance certificate on first OPC UA channel start. Verify it is present:

dir "C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\certs" /S

If a WinCC client certificate does not exist, start and stop the WinCC runtime once with an unauthenticated channel — the runtime creates the .der and matching .pfx on first use.

Step 5 — Trust the WinCC Client Certificate on KEPServerEX

KEPServerEX must explicitly trust the WinCC client certificate. KEPServerEX rejects unknown client certificates by default, which would surface as a different failure (server-side BadCertificateUnknown); however, the configuration is still required for production operation:

1. Copy the WinCC client DER from C:\Program Files (x86)\Siemens\Automation\WinCC\opc2\OpcUaClient\PKI\CA\certs to the KEPServerEX host.
2. Open the KEPServerEX Configuration Tool, expand Project → OPC UA → Trusted Clients.
3. Right-click Trusted Clients and select Import Certificate from File; select the DER.
4. Restart the KEPServerEX runtime service.

Step 6 — Configure the WinCC OPC UA Channel

In the WinCC Explorer, open the OPC UA channel connection properties and confirm the following:

The WinCC documentation page Creating a connection to an OPC UA server (RT Professional) shows the equivalent TIA Portal-based configuration for the newer runtime; the certificate trust procedure is identical.

Step 7 — Restart WinCC Runtime

Start the WinCC runtime and observe the OPC UA channel diagnostics. The connection should transition through Establishing connection → Connected within five seconds.

KEPServerEX OPC UA Server-Side Configuration

Verify that the server side is configured to allow the authentication mode you selected on the WinCC side. Open KEPServerEX Configuration → Project Properties → OPC UA:

If Trust All Client Certificates is checked as a quick test and the connection now succeeds, the fault is in the client certificate trust chain on the KEPServerEX host — return to Step 5 and import the WinCC certificate properly.

Verification Procedure

1. Open the WinCC tag management; the OPC UA channel status indicator should display a green connected state.
2. Right-click the OPC UA connection and select Properties → Test Connection. A successful response indicates that ActivateSession has completed.
3. Open the KEPServerEX Event Log. A line similar to Session activated: User=<username>, Endpoint=<wincc-host> confirms the server received and accepted the WinCC credentials.
4. Re-capture with Wireshark and verify that CreateSession (NodeId 461) and ActivateSession (NodeId 467) now appear in the trace, followed by periodic Read (NodeId 631) or subscription Publish (NodeId 826) traffic.
5. Force a value change in KEPServerEX and confirm the corresponding WinCC tag updates within the configured update rate (default 1000 ms).

Troubleshooting Matrix

Security Policy and Identity Token Compatibility

The endpoint selected in WinCC must match an entry returned by the server's GetEndpoints response. Verify the matrix below when configuring WinCC:

Identity token types advertised per endpoint must include UserName; some KEPServerEX templates only advertise Anonymous until a username/password authentication mode is enabled at the server project level.

Common Field Pitfalls

• Re-installing the WinCC certificate into Trusted People of the Windows certificate store. WinCC's OPC UA runtime does not consult the Windows store; it uses its dedicated PKI folder exclusively.
• Copying the certificate while the runtime holds a handle. The file moves but is not re-read; the runtime continues to use the cached rejected entry until fully restarted.
• Using the IP address in the endpoint URL when the certificate CN is the hostname. OPC UA Part 4 requires the certificate to be valid for the endpoint URL hostname. Use the FQDN.
• Mixing Security: None with User Authentication: Username. Some KEPServerEX versions will not advertise a UserName token on the None endpoint; verify with a third-party UA client first.
• Ignoring WinCC update level. Several V7.3 pre-SP3 builds shipped with broken OPC UA channel retry logic; applying the updates referenced in Siemens KB 109742642 is a prerequisite, not an optional step.

Related Authentication Use Cases

The same certificate trust procedure applies for WinCC authenticating against any OPC UA server, including third-party gateways such as Ignition when configured with the WinCC connectivity pack. The official Siemens guidance is documented at Setting up authentication via certificates (RT Professional): the OPC UA client can only connect to the OPC UA server if the server identifies the client certificate as trustworthy, and conversely the client must trust the server certificate — which is precisely the requirement that the rejected-folder move restores.