OPC-UA-Verbindungsfehler beheben: Endpunkt, Security Policy, Zertifikate

Wenn eine OPC-UA-Verbindung fehlschlägt, sitzt der Fehler fast immer in einer von sechs Schichten: Netzwerk, Endpunkt-Discovery, Security Policy, Zertifikatsvertrauen, Benutzer-Login oder Namespace. Dieser Artikel führt von unten nach oben durch diese Schichten – mit den StatusCodes aus der OPC-UA-Spezifikation, der wahrscheinlichen Ursache und dem Handgriff, der den OPC-UA-Verbindungsfehler behebt. Und er erklärt, warum der in Foren verbreitete Rat, die Security Policy auf None zu stellen, keine Lösung ist, sondern eine Schwachstelle.

Die Reihenfolge der Prüfung: sechs Schichten von unten nach oben

Ein OPC-UA-Verbindungsaufbau besteht aus aufeinander aufbauenden Schritten, und jeder Schritt kann nur scheitern, wenn der darunter gelungen ist. Ein fester Diagnosebaum verhindert deshalb, dass Sie an Zertifikaten drehen, während die Firewall den Port blockt. Die sechs Schichten entsprechen den Diensten aus OPC 10000-4: Transportverbindung, Discovery, OpenSecureChannel mit Zertifikatsprüfung, CreateSession und ActivateSession, schließlich Browse, Read und Subscriptions.

1. 01

   Schicht 1 – Erreichbarkeit

   Antwortet der Zielport? Ohne TCP-Verbindung ist alles Weitere gegenstandslos.

2. 02

   Schicht 2 – Endpunkt-Discovery

   Liefert GetEndpoints eine Endpunktliste, und sind deren Adressen aus Sicht des Clients auflösbar?

3. 03

   Schicht 3 – Security Policy und Message Security Mode

   Fragt der Client eine Kombination an, die der Server tatsächlich anbietet?

4. 04

   Schicht 4 – Zertifikatsvertrauen

   Vertrauen sich beide Application Instance Certificates, und bestehen sie alle Prüfschritte (Gültigkeit, Hostname, ApplicationUri, Sperrliste)?

5. 05

   Schicht 5 – Benutzerauthentifizierung

   Akzeptiert der Server das Identity Token, und hat der Benutzer die Rechte für Browse, Read oder Write?

6. 06

   Schicht 6 – Session und Namespace

   Die Verbindung steht, aber Werte fehlen: NodeIds, Namespace-Index, Freigaben, Subscription-Parameter.

In der Praxis liegen die meisten Fehlschläge in Schicht 3 und 4: Netzwerk und Login beherrschen Instandhaltung und IT seit Jahren, die beidseitige Zertifikatspflege ist ein OPC-UA-spezifisches Konzept. Ein nützlicher Nebeneffekt der Reihenfolge: Laut BSI-Sicherheitsanalyse müssen alle Applikationen FindServers und GetEndpoints unabhängig vom Security Mode auch unverschlüsselt und unsigniert unterstützen. Bekommen Sie eine Endpunktliste, sind Schicht 1 und 2 erledigt.

Schicht 1 und 2: Erreichbarkeit und Endpunkt-Discovery

Ein OPC-UA-Endpunkt ist nicht erreichbar, wenn entweder der TCP-Port nicht antwortet oder die Discovery eine Adresse zurückgibt, die der Client nicht auflösen kann. Der Standardport ist 4840; die IANA führt ihn als opcua-tcp (OPC UA Connection Protocol) auf TCP und als opcua-udp für Multicast auf UDP, registriert durch die OPC Foundation. Viele Server und praktisch alle Gateways lassen sich auf andere Ports konfigurieren – prüfen Sie den konfigurierten Port, nicht den vermuteten.

Der klassische Discovery-Fehler: Der Client verbindet sich mit opc.tcp://192.168.10.5:4840, bekommt eine Endpunktliste, und darin steht opc.tcp://plc-halle3:4840. Diesen Namen kann er nicht auflösen, der eigentliche Aufbau endet im Timeout. OPC 10000-4 beschreibt den Mechanismus: Der Client soll bei GetEndpoints genau die URL übergeben, mit der er den Server erreicht hat, und der Server soll mit Endpunkten antworten, die über diese URL erreichbar sind. Kennt er den Hostnamen nicht, liefert er einen Standardwert – bei NAT oder fehlendem DNS-Eintrag oft unbrauchbar.

• —TCP-Port aus dem Client-Netz testen, nicht vom Engineering-PC neben der Steuerung.
• —Mit einem generischen OPC-UA-Client die Endpunktliste abrufen und die endpointUrl-Werte mit dem vergleichen, was der Client auflösen kann.
• —Hostnamen auflösbar machen (DNS oder Hosts-Eintrag) oder im Client die Endpunkt-URL nach der Discovery durch die verbundene Adresse ersetzen lassen.
• —Bei Steuerungen: Ist der Server aktiviert? Bei der S7-1500 ist er aus Sicherheitsgründen standardmäßig ausgeschaltet und setzt eine Runtime-Lizenz voraus, die nach CPU-Klasse in small, medium und large gestaffelt ist.

Notieren Sie sich aus der Endpunktliste die angebotenen Security Policies, Message Security Modes und Token-Typen – alles steht laut OPC 10000-4 in jeder EndpointDescription. Wie der Adressraum einer S7-1500 aufgebaut ist und welche Alternativen zum OPC-UA-Server es gibt, beschreibt S7-Daten auslesen: OPC-UA-Server, Snap7 und optimierte Datenbausteine.

Schicht 3: Security Policy und Message Security Mode

Security Policy und Message Security Mode sind zwei getrennte Einstellungen, und ein OPC-UA-Client verbindet nicht, wenn seine Kombination aus beiden nicht exakt in der Endpunktliste vorkommt. Der Message Security Mode sagt, was mit Nachrichten passiert: nichts, signieren oder signieren und verschlüsseln. Die Security Policy sagt, mit welchen Algorithmen und Schlüssellängen. OPC 10000-4 definiert den Mode mit den Werten None, Sign und SignAndEncrypt – und einem Standardwert Invalid, damit niemand versehentlich ohne Sicherheit landet.

Die Policies tragen Namen wie Basic128Rsa15, Basic256 und Basic256Sha256. Die beiden ersten beruhen auf SHA-1; die BSI-Sicherheitsanalyse von 2022 hält fest, dass der Vorschlag, SHA-1 einzusetzen, aus der Spezifikation entfernt wurde und die betroffenen Policies teilweise veraltet sind. Daraus entsteht der typische Aushandlungsfehler: Ein älterer Client kennt nur Basic128Rsa15, der Server bietet es nach dem Firmware-Update nicht mehr an – die Antwort ist Bad_SecurityPolicyRejected.

Der Handgriff: Endpunktliste aus Schicht 2 nehmen und im Client eine Kombination wählen, die dort steht – bevorzugt Basic256Sha256 oder neuer mit SignAndEncrypt. OPC 10000-4 formuliert es unmissverständlich: Ein Client kann sich nicht mit einem Endpunkt verbinden, dessen Security Policy er nicht kennt. Was Sie nicht tun sollten: die Policy des Servers absenken, damit ein alter Client wieder passt.

Schicht 4: Zertifikatsvertrauen ist immer beidseitig

Ein OPC-UA-Zertifikatsfehler entsteht, sobald eine der beiden Seiten das Application Instance Certificate der anderen nicht als vertrauenswürdig einstuft – und beide Seiten prüfen unabhängig voneinander. OPC 10000-4 verlangt in Abschnitt 6.1.3, dass Applikationen sich auf zwei vom Administrator gepflegte Listen stützen: eine Liste vertrauenswürdiger Zertifikate (Trust List) und eine Liste von Ausstellerzertifikaten (Issuer List), dazu Sperrlisten (CRL) für beide. Fehlt eine dieser Ablagen auf einer Seite, scheitert der Aufbau, obwohl die andere alles richtig gemacht hat.

Die Spezifikation definiert die Prüfung als Kette von Schritten mit je eigenem StatusCode – der Code sagt also, welcher Schritt gescheitert ist: Bad_CertificateUntrusted (in keiner Trust List), Bad_CertificateTimeInvalid (abgelaufen oder noch nicht gültig), Bad_CertificateHostNameInvalid (Hostname der Verbindungs-URL nicht im Server-Zertifikat; gilt nur für Server-Zertifikate), Bad_CertificateUriInvalid (ApplicationUri passt nicht zur ApplicationDescription), Bad_CertificateRevocationUnknown (keine Sperrliste verfügbar).

Die häufigste Ursache ist banal: Der Server hat das Client-Zertifikat beim ersten Versuch abgelehnt und in den Rejected-Ordner gelegt, und niemand hat es nach Trusted verschoben. Die zweithäufigste ist die ApplicationUri: Sie wird bei der Zertifikatserzeugung eingebrannt; wer danach Applikationsnamen oder Hostnamen ändert, hat ein Zertifikat, das nicht mehr zur eigenen Konfiguration passt. Dieser Prüfschritt ist laut Spezifikation nicht unterdrückbar – hier hilft nur ein neues Zertifikat. Die dritte ist die Uhrzeit: Eine Steuerung ohne gepufferte Echtzeituhr oder NTP startet mit einem Datum, zu dem das Zertifikat noch nicht gültig ist; Siemens nennt für die S7-1500 die aktuelle Systemzeit ausdrücklich als Voraussetzung für die Zertifikatsprüfung.

Ein Komfortschalter der Inbetriebnahme verdient eigene Aufmerksamkeit: Die S7-1500 kann zur Laufzeit automatisch alle Client-Zertifikate akzeptieren. Die Siemens-Dokumentation weist an, diese Option nach der Inbetriebnahme wieder zu deaktivieren – in der Praxis bleibt sie oft an, bis ein Audit sie findet.

Schicht 5: Benutzerauthentifizierung und Berechtigungen

Ein erfolgreich aufgebauter Secure Channel ist noch keine Session, deshalb kann ein Client nach fehlerfreiem Zertifikatsaustausch trotzdem scheitern. OPC 10000-4 trennt die Schritte: CreateSession legt die Session an, ActivateSession übergibt die Identität des Benutzers, und diesen Dienst muss der Client vor jedem anderen außer CloseSession aufrufen. Als Token-Typen kennt die Spezifikation Anonymous, UserName, X509 und IssuedIdentity; der Endpunkt sagt in seiner EndpointDescription, welche er akzeptiert.

Die StatusCodes unterscheiden zwei Fälle, die gern verwechselt werden. Bad_IdentityTokenInvalid: Das Token selbst ist nicht gültig, typischerweise weil der Client einen Typ sendet, den der Endpunkt nicht anbietet – etwa Anonymous gegen einen Server, der Anonymous deaktiviert hat. Bad_IdentityTokenRejected: Das Token ist formal gültig, aber der Server lehnt es ab – falsches Passwort, unbekannter Benutzer, gesperrtes Konto. Bad_UserAccessDenied kommt erst nach erfolgreichem Login und bedeutet, dass der Benutzer für genau diese Operation kein Recht hat.

Daraus folgt eine Trennung, die Sie konsequent einhalten sollten: Browse und Read auf der einen Seite, Write auf der anderen. Ein Datenerfassungs-Client braucht keine Schreibrechte; ein eigener OPC-UA-Benutzer nur mit Leserechten begrenzt den Schaden, falls dessen Zugangsdaten im falschen Netz landen. Fehlende Rechte auf Knotenebene meldet der Server als Bad_NotReadable oder Bad_NotWritable – das ist das AccessLevel des Knotens, keine Benutzerrolle.

Schicht 6: Verbindung steht, aber es kommen keine Daten

Wenn der OPC-UA-Client verbunden ist, aber beim Namespace-Browsen Knoten fehlen oder keine Werte kommen, liegt es fast immer an NodeIds, Freigaben oder Subscription-Parametern. Das häufigste Fehlerbild nach einem Steuerungs-Download ist Bad_NodeIdUnknown auf Variablen, die gestern noch liefen. Die Ursache steht in OPC 10000-5: Der Namespace-Index ist nur eine Position in der NamespaceArray des Servers. Die Spezifikation empfiehlt Servern, Indizes nicht zu ändern, sondern nur Einträge anzuhängen, räumt aber ein, dass das nicht immer möglich ist – und verlangt von Clients, die Indizes cachen, bei jedem Sitzungsstart zu prüfen, ob sie noch stimmen.

NamespaceArray des Servers (fiktives Beispiel):
  [0] http://opcfoundation.org/UA/
  [1] urn:SIMATIC.S7-1500.OPC-UA.Application:PLC_1
  [2] http://opcfoundation.org/UA/DI/
  [3] http://www.siemens.com/simatic-s7-opcua
  [4] http://beispiel.de/serverinterface/linie3

Fragil:  ns=4;s=Linie3.Ofen.Temperatur
Robust:  nsu=http://beispiel.de/serverinterface/linie3;s=Linie3.Ofen.Temperatur

Der Handgriff: im Client nie den numerischen Index persistieren, sondern die Namespace-URI, und den Index beim Verbinden auflösen. Ein stabiles Namensschema über alle Maschinen ist zugleich die Voraussetzung für eine Datenarchitektur, wie sie Unified Namespace: Referenzarchitektur mit ISA-95-Topic-Schema beschreibt. Zweite Ursache: Die Variable ist im Engineering-Projekt nicht für OPC UA freigegeben und steht gar nicht im Adressraum – prüfen Sie das Zugriffsattribut, bevor Sie im Client suchen.

Dritte Ursache sind Subscriptions: Ein Monitored Item hat ein Sampling Interval (die schnellste Rate, mit der der Server die Quelle abtastet) und eine Queue Size; die Subscription sendet im Publishing Interval. Hört der Client auf, Publish-Anfragen zu senden, läuft der Lifetime-Zähler ab, die Subscription wird gelöscht und der Server meldet Bad_Timeout – der typische Zustand nach einem Netzwerk-Hänger, wenn der Client wieder verbunden ist, aber keine Daten mehr bekommt. Bad_WaitingForInitialData oder Bad_NoCommunication bedeuten dagegen, dass der Server selbst noch keinen Wert von seiner Quelle hat.

Schließlich die Zeitstempel: Der SourceTimestamp ist laut OPC 10000-4 die Zeit, die die Datenquelle dem Wert gegeben hat, in UTC; der ServerTimestamp ist die Zeit, zu der der Server den Wert erhalten hat. Für Prozessauswertungen zählt der SourceTimestamp – sofern die Steuerung eine korrekte Uhr hat. Wer statt Client/Server-Abfragen ein Publish-Subscribe-Modell braucht, ist bei OPC UA PubSub oder MQTT richtig; die Abwägung steht in OPC UA oder MQTT? Entscheidungsleitfaden für die Maschinenanbindung.

Der Ratschlag aus jedem Forum: Security auf None – und warum er gefährlich ist

Der Rat ist so verbreitet, weil er funktioniert: Mit None fällt die gesamte Zertifikatsprüfung weg, der Fehler verschwindet. Die Spezifikation behandelt None jedoch als Ausnahme. OPC 10000-2 legt fest, dass der Security Mode None nur mit dem Sicherheitsprofil None verwendet werden kann und dieses Profil standardmäßig deaktiviert sein muss. Ein Server, der None anbietet, wurde also bewusst so konfiguriert – oder nie gehärtet.

Was dabei verloren geht, hat das BSI in seiner 2022 aktualisierten Sicherheitsanalyse OPC UA auf Parameterebene ausgewertet: Im Security Mode None findet keine Verschlüsselung statt, und gegen das Erzeugen und Verändern von Nachrichten – etwa bei einem Man-in-the-Middle-Angriff – schützt None wegen der fehlenden Applikationsauthentifizierung überhaupt nicht. Dieselbe Studie folgert aus Untersuchungen öffentlich erreichbarer OPC-UA-Anwendungen, dass Security beim Einsatz von OPC UA oft weiterhin nicht hinreichend betrachtet wird. Eine Steuerung mit None-Endpunkt ist genau dieser Fall.

Der sichere Weg kostet eine halbe Stunde mehr als der Klick auf None und ist danach dokumentiert:

1. 01Einmalige, dokumentierte Zertifikatsfreigabe: Client-Zertifikat in die Trust List des Servers, Server-Zertifikat in die Trust List des Clients, Fingerprints und Ablaufdaten im Anlagendossier.
2. 02Eigener OPC-UA-Benutzer je Client-Anwendung, nur mit Leserechten, kein Anonymous im Betrieb; Schreibrechte nur für Anwendungen, die nachweislich schreiben müssen.
3. 03Verbindung ausschließlich innerhalb des OT-Segments oder über einen kontrollierten Übergang; ein OPC-UA-Endpunkt gehört nie an ein Netz, aus dem beliebige Clients Discovery ausführen können.
4. 04None nur temporär im Testaufbau, mit Ticket, Verantwortlichem und Datum der Rücknahme – und einer Kontrolle, dass der Endpunkt danach nicht mehr in der Endpunktliste auftaucht.

Fehlerbild-Tabelle zum Nachschlagen

Die Tabellen ordnen die häufigsten StatusCodes ihrer Schicht, der wahrscheinlichen Ursache und dem ersten Handgriff zu. Die StatusCodes und ihre Definitionen stammen aus OPC 10000-4; die Klartextmeldungen daneben sind typische Formulierungen, wie Clients sie anzeigen, kein exakter Wortlaut eines bestimmten Produkts.

Was Sie protokollieren sollten, damit der nächste Ausfall schneller geht

Die zweite Fehlersuche an derselben Verbindung ist nur dann kürzer als die erste, wenn die Konfiguration dokumentiert wurde: welcher Endpunkt, welche Policy, welches Zertifikat mit welchem Ablaufdatum, welcher Benutzer. Ein OPC-UA-Zertifikat läuft an einem Datum ab, das niemand im Kalender hat, und die Verbindung stirbt dann nachts mit Bad_CertificateTimeInvalid. Das ist vermeidbar.

Fazit

Ein OPC-UA-Verbindungsfehler ist selten mysteriös. Die Spezifikation liefert für jeden Prüfschritt einen eigenen StatusCode, und wer die sechs Schichten von unten nach oben abarbeitet, landet bei einer konkreten Ursache: einem Hostnamen, den der Client nicht auflöst, einer Policy, die der Server nicht mehr anbietet, einem Zertifikat im Rejected-Ordner oder einem verschobenen Namespace-Index. Die Abkürzung über Security None spart diese Suche und kostet dafür die Applikationsauthentifizierung der Steuerung.

Der nächste Schritt ist derselbe wie bei jeder anderen Anlagenkomponente: Konfiguration dokumentieren, Ablaufdaten in die Wartungsplanung, Session statt Ping überwachen. Wenn Sie Maschinendaten über OPC UA in Dashboards, Kennzahlen oder eine Datenplattform bringen möchten und dafür eine belastbare Anbindung statt einer Testaufbau-Verbindung brauchen, zeigen die Lösungen von ralwo, wie so eine Strecke aufgebaut wird.