Resolving OPC UA BadCertificateHostnameInvalid on the Siemens SIMATIC IOT2040 with Node-RED

The SIMATIC IOT2040 (Siemens article number 6ES7647-0AA00-1YA2) and the newer IOT2050 (6ES7647-0AA00-1YA2 / 6ES7647-0AA00-2YA2) ship with Node-RED preinstalled on the Example Image SD card. When a flow uses the node-red-contrib-iiot-opcua package and exposes data through the OPC UA IIoT Flex Server node, the embedded node-opcua library creates a self-signed X.509v3 certificate the first time the node is deployed. That certificate is auto-generated with placeholder values for the ApplicationUri and a generic Subject Alternative Name (SAN) of DNS:iot2000 or DNS:iot2040. Any client that reaches the server by IP address (for example opc.tcp://192.168.200.1:48020) instead of the original hostname triggers a hostname check that the certificate cannot satisfy, and the OPC UA stack returns a status code that prevents the session from being created.

This reference explains how the OPC UA security model interacts with the Flex Server, how to diagnose the specific status codes that appear, and how to generate and install a replacement certificate that satisfies UaExpert, custom .NET / Python clients, and the Siemens TIA Portal HMI runtime.

1. Symptoms and Status Codes

The certificate problem surfaces differently depending on the client used. The three observations below all share the same root cause: a mismatch between the values inside the X.509 SAN extension of the server certificate and the endpoint URL the client resolves at runtime.

The OPC UA status codes are defined in OPC UA Part 4 – Services and Part 6 – Mappings and reproduced in the official OPC UA Specification Part 4. Treat each value as authoritative when interpreting client logs.

2. OPC UA Security Model and Certificate Requirements

OPC UA Part 6 defines a certificate-based trust model. Every server and every client must carry an X.509v3 certificate that the counter-party can validate. The following fields are mandatory for a server certificate and must be present in the Subject Alternative Name extension:

When a client opens a session, the OPC UA stack performs two independent checks against the server certificate:

1. Hostname check. The hostname or IP address the client used to open the transport channel must appear in the SAN as either dNSName or iPAddress. A mismatch raises BadCertificateHostNameInvalid.
2. ApplicationUri check. The ApplicationUri in the ServerArray of the server endpoint must match the URI in the SAN. A mismatch raises BadCertificateUriInvalid.

The auto-generated certificate of the Flex Server uses urn:opcua:server as ApplicationUri and a single dNSName entry of iot2000. As soon as a client contacts the device by IP, the hostname check fails and the session is rejected.

3. Root Cause Analysis

The node-opcua library bundled with node-red-contrib-iiot-opcua uses node-opcua-certificate-manager to produce the auto-generated certificate. The relevant call is createSelfSignedCertificate() with the following defaults:

The generated PEM file is stored in ~/.node-red/node_modules/node-opcua-certificate-manager/certificates/ on the IOT2040. The corresponding private key is stored in the same folder as *_private_key.pem. When the Flex Server starts, it loads the certificate, the key, and the issuer chain. Replacing the auto-generated files with a hand-built certificate that contains the correct SAN entries eliminates the hostname and ApplicationUri errors.

4. Prerequisites

Before generating a replacement certificate, verify the following on the IOT2040:

1. Hardware. SIMATIC IOT2040 with the Example Image V2.6.0 or later, or SIMATIC IOT2050 with Example Image V1.0.4 or later. The image is available from Siemens Support entry 109741799 (IOT2040) and 109782388 (IOT2050).
2. Node-RED. Version 1.3.x or later. Verify with node-red --version on the device after SSH login.
3. node-red-contrib-iiot-opcua package. Version 3.x or 4.x. The Flex Server, Flex Client and OPC UA IIoT nodes must be present. Install with cd ~/.node-red && npm install node-red-contrib-iiot-opcua. The package is published on the Node-RED Flow Library.
4. OPC UA clients for verification. Unified Automation UaExpert 1.7 or later, and at least one TIA Portal HMI (WinCC Unified, Comfort Panel, or KTP Mobile Panel with OPC UA licence).
5. Certificate generation tool. XCA (Cross Certifying Authority) for graphical use, or OpenSSL 1.1.1 / 3.0.x for command-line use.
6. Network parameters. Final hostname and IP address of the IOT2040, for example iot2040.local and 192.168.200.1. These values will be embedded in the SAN.

5. Generating a Compliant Self-Signed Certificate

Two methods are documented: XCA (graphical) and OpenSSL (command line). The OpenSSL procedure is faster and reproducible from a script.

5.1 OpenSSL Method (recommended for repeatable deployments)

Create a configuration file opcua-cert.cnf on the IOT2040 or on a workstation:

[req]
distinguished_name = req_dn
prompt = no
x509_extensions = v3_ca

[req_dn]
CN = iot2040
O  = Siemens
OU = Factory Automation

[v3_ca]
subjectAltName   = @alt_names
keyUsage         = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage  = serverAuth, clientAuth
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid, issuer

[alt_names]
DNS.1 = iot2040
DNS.2 = iot2040.local
IP.1  = 192.168.200.1
URI.1 = urn:siemens:iot2040:opcua:flexserver

Generate the key pair and the certificate (valid for 10 years, RSA 2048):

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout iot2040_opcua_key.pem \
  -out    iot2040_opcua_cert.pem \
  -days 3650 \
  -config opcua-cert.cnf \
  -sha256

Inspect the SAN to confirm the entries:

openssl x509 -in iot2040_opcua_cert.pem -noout -text | grep -A6 "Subject Alternative Name"

Expected output (abbreviated):

X509v3 Subject Alternative Name:
    DNS:iot2040, DNS:iot2040.local, IP Address:192.168.200.1,
    URI:urn:siemens:iot2040:opcua:flexserver

5.2 XCA Method (graphical)

1. Start XCA and create a new database. Open the Certificates tab and click New Certificate.
2. Under Source, choose Generate a new key and select RSA 2048.
3. Under Subject, set Common Name to iot2040, Organization to Siemens, and the Application URI field (inside X509v3 Extensions → subjectAltName → otherName) to urn:siemens:iot2040:opcua:flexserver.
4. Add the subjectAltName entries: dNSName=iot2040, dNSName=iot2040.local, iPAddress=192.168.200.1.
5. Set Key Usage to digitalSignature, keyEncipherment, dataEncipherment and Extended Key Usage to serverAuth, clientAuth.
6. Sign and export. Use Export → Certificate → PEM and Export → Private Key → PEM. Keep the two files separate.

Copy the resulting iot2040_opcua_cert.pem and iot2040_opcua_key.pem to the IOT2040 with scp.

6. Configuring the OPC UA IIoT Flex Server

The Flex Server node in the Security configuration tab contains a switch that, when enabled, forces the server to load the certificate and the private key from explicit file paths instead of the auto-generated ones.

1. Open the Node-RED flow that contains the OPC UA IIoT Flex Server node.
2. Double-click the Flex Server node and switch to the Security tab.
3. Enable Use individual public certificate and private key files (this option is present in node-red-contrib-iiot-opcua 3.6.0 and later).
4. Set Path to public certificate file to /home/iot2000/.node-red/certs/iot2040_opcua_cert.pem.
5. Set Path to private key file to /home/iot2000/.node-red/certs/iot2040_opcua_key.pem.
6. Set Default ApplicationUri to the same value that was added to the SAN: urn:siemens:iot2040:opcua:flexserver.
7. Disable Allow Anonymous only if you intend to push a ClientCertificate. Otherwise keep None as the lowest security policy until a full HMI connection is established.
8. Click Done and deploy the flow.

Fix the file ownership so the Node-RED process (running as user iot2000 by default on the IOT2040 image) can read the files:

sudo chown iot2000:iot2000 /home/iot2000/.node-red/certs/*.pem
sudo chmod 600 /home/iot2000/.node-red/certs/iot2040_opcua_key.pem
sudo chmod 644 /home/iot2000/.node-red/certs/iot2040_opcua_cert.pem

Restart Node-RED and observe the log:

systemctl restart node-red
journalctl -u node-red -f

The relevant log line is certificate_manager: certificate loaded from /home/iot2000/.node-red/certs/iot2040_opcua_cert.pem. If the line reads permission denied, re-run the chown/chmod steps. The node-opcua library also requires read access to the issuer chain folder (issuers/) inside the same certs directory; create it if absent and set the same ownership.

7. TIA Portal HMI Client Integration

Once the Flex Server presents a certificate that matches its IP, the Siemens HMI runtime can be configured as an OPC UA client in TIA Portal V17 / V18 / V19. The procedure assumes a Comfort Panel (TP700 / TP900 / TP1200) or a WinCC Unified Panel (MTP700 / MTP1200) with a valid OPC UA licence.

1. In the TIA Portal project tree, open Devices & Networks, select the HMI, and switch to Connections.
2. Add an OPC UA connection. Set the endpoint URL to opc.tcp://192.168.200.1:48020.
3. Under Security policy, select Basic256Sha256 for production deployments, or None for the first acceptance test.
4. Under Authentication, select Certificate-based if the Flex Server has been configured with certificate-based user identity, otherwise Anonymous.
5. Transfer the IOT2040 server certificate to the HMI runtime: copy iot2040_opcua_cert.pem to the TIA Portal project folder Certificate manager → Trusted certificates of the HMI device. TIA Portal converts the PEM to the runtime store automatically during transfer.
6. Compile and download the HMI configuration.

8. Verification and Acceptance Test

Run the following checks after deploying the new certificate:

1. SAN inspection. From a workstation, run openssl s_client -connect 192.168.200.1:48020 -showcerts (with the Flex Server temporarily set to None security so the TLS handshake completes) and confirm that the certificate presented by the server contains the expected DNS, IP and URI entries.
2. UaExpert round-trip. Start UaExpert, drag Custom Discovery, add opc.tcp://192.168.200.1:48020, and accept the server certificate. The dialog should not raise the Replaced Hostname warning. Drag a tag and confirm the value updates.
3. Security mode escalation. In UaExpert, change the security policy of the connection to Basic256Sha256 — SignAndEncrypt. The handshake must complete without BadCertificateHostNameInvalid.
4. HMI acceptance. In the TIA Portal HMI project, open Online → Diagnostics for the OPC UA connection. The status must read Connected. If the runtime still shows Connection interrupted, verify that the TIA Portal compiler included the certificate in the HMI image (check Certificate manager → Used certificates after transfer).
5. Node-RED log audit. Tail the Node-RED log for one hour of normal operation. No BadCertificateUntrusted or BadDecodingError entries must appear.

9. Security Hardening and Best Practices

• Validity period. 10 years (3650 days) is acceptable for a self-signed production certificate used inside an isolated OT network. For an internet-facing or multi-tenant deployment, drop validity to 825 days to remain compatible with current browser and major CA policies, or move to a corporate CA.
• Key length. 2048 bits is the minimum for OPC UA applications through 2030. Use 3072 or 4096 bits for new deployments where the client device supports it.
• Subject Alternative Name coverage. Include every hostname and IP address the server will be reached by. A missing entry raises BadCertificateHostNameInvalid and is the most common cause of failure after the certificate is replaced.
• ApplicationUri. Use a stable URN that embeds the device serial number, for example urn:siemens:iot2040:SVP<serial>:opcua. Changing the ApplicationUri forces every client to re-trust the server.
• Trusted client store. For two-way authentication, copy the HMI client certificate into the Flex Server's issuers/ folder and restart Node-RED.
• Operating system hardening. Restrict SSH on the IOT2040 to a dedicated maintenance VLAN. Disable Allow Anonymous in the Flex Server once the HMI has been migrated to certificate authentication.
• Firmware updates. Keep the IOT2040 Example Image current. The Siemens IOT2040 support entry lists all released images, including security patches for the underlying Yocto/Debian base.

10. Troubleshooting Matrix

11. Frequently Asked Questions