Hallo, in diesem WAGO‑Tutorial zeigen wir, welchen Anforderungen eigene Zertifikate für eine OPC UA‑Kommunikation erfüllen müssen und wie man eigene Security‑Zertifikate in CODESYS 3.5 importiert. Ganz allgemein ist dies die Fortsetzung des Tutorials zu den von CODESYS erstellten Zertifikaten und wir verwenden hier wieder zwei PFC200 einen als Server und einen als Client. Auch das CODESYS Programm wird hier einfach fortgesetzt, wir haben lediglich die von CODESYS erstellte Zertifikate gelöscht und wollen diese durch eigene ersetzten. Daher gehen wir hier auf die grundsätzlichen Einstellungen nicht mehr ein, alles dazu findet ihr in dem Tutorial: OPC UA Security Zertifikate mit CODESYS 3.5 erstellen. Im Server lassen wir eine Integer Variable hochlaufen und wollen die Werte über eine verschlüsselte OPC UA Verbindung an den Client senden. Noch ist keine Verbindung möglich, da wir noch keine Zertifikate importiert haben, aber eine Security Policy bereits in den Gerätesicherheitseinstellungen konfiguriert ist. Hier könnten wir die Security Policy auch direkt ändern, ohne dafür ins Web Based Management zu müssen, bzw. bei manchen Controllern wie z.B. beim BC100 ist das auch nur hier möglich. Im Security Screen sind sowohl für den Server als auch für den Client keine OPC UA Zertifikate vorhanden. Es gibt mehrere Möglichkeiten Zertifikate zu kaufen oder zu erstellen. Wir zeigen hier, wie man mit dem Softwaretool XCA eigene Zertifikate erstellt, da wir so anschaulich zeigen können welche Anforderungen ein Zertifikat erfüllen muss. Da bei der Erstellung des Root CAs keine Besonderheiten für die Verwendung in CODESYS zu berücksichtigen sind, haben wir eine neue Datenbank und das Root CA ist bereits erstellt. Dieses Exportieren wir aus XCA und laden es im Server in den Ordner Vertrauenswürdige Zertifikate. Damit kennt der Server das RootCA und vertraut einem Clientzertifikat das von diesem RootCA signiert wurde. Dann starten wir mit der Erstellung des Server Zertifikats. Wir wählen das Root CA aus und klicken auf Neues Zertifikat. Im Tab Herkunft ist unser Root CA bereits als signierendes Zertifikat ausgewählt. Hier unten wählen wir das Template TLS_server aus und wollen daraus alle Einstellungen übernehmen. Im Tab Inhaber vergeben wir unter anderem einen Common Namen. Hier ist der erste Stolperstein, da der Name exakt dieses Format erfüllen muss: OPCUAServer @ und dann der Hostname. Den Hostname finden wir entweder in CODESYS in den Kommunikationseinstellungen oder im Web Based Management des Controllers. Einmal kopieren und einfügen. Dann füllen wir die restlichen Daten aus. Hier unten erstellen wir zu unserem Zertifikat den Schlüssel. Im Tab Erweiterungen wählen wir die Gültigkeitsdauer des Zertifikats aus, z.B. 2 Jahre und das Zertifikat soll z.B. um 0:00 Uhr ablaufen. Wichtig wird es jetzt beim Subject Alternative Name. Hier stellt CODESYS besondere Anforderungen an das Zertifikat. Mit Bearbeiten öffnen wir die Eingabemaske und geben zunächst die IP-Adresse des Controllers an. Dann müssen wir uns einmal Gedanken machen, wie die angegebene IP-Adresse abgeglichen wird. Im letzten Tutorial haben wir in den Security Einstellungen des Controllers festgelegt, dass alle aktiven IP-Adressen berücksichtigt werden. Wenn wir bei der Zertifikatserstellung hier aber den Haken bei Critical setzten, was aus Security Sicht unbedingt empfehlenswert ist, würde das Zertifikat abgelehnt, da es nur für genau eine IP Adresse gültig ist und nicht für alle. Wir haben da jetzt mehrere Optionen um das zu berücksichtigen. Zum einen könnten wir das Häckchen bei Critical weglassen, wodurch allerdings eine unnötige Sicherheitslücke entsteht. Die andere Option ist, die im Zertifikat angegebene IP-Adresse in den Sicherheitseinstellungen des Controllers anzugeben, statt „All“ oder wir können im Zertifikat zusätzlich die Localhost-IP-Adresse (127.0.0.1) mit angeben. Diese Option wird auch bei den durch CODESYS erstellten Zertifikaten verwendet. Dann geben wir den DNS-Namen ein, also den Hostname des Controllers. Und dann müssen wir die URI angeben. CODESYS stellt hier bestimmte Anforderungen an die URI, hier haben wir ein Beispiel. Auf den ersten Blick wirkt die URI etwas kryptisch, lässt sich aber relativ einfach zusammensetzten. Das Ganze beginnt zunächst mit ‚URI:urn:‘ dann folgt der Host oder der Gerätename, dann der Hersteller und dann der Produktname. Den exakten Produktnamen finden wir im Web Based Management Im Tab Informationen im Menü Geräte Status. Wenn wir diesen jetzt kopieren und hier einfügen, sieht das noch etwas anders aus als in dem Beispiel. Das liegt daran, dass wir den Gerätenamen im HTML Format benötigen. Im HTML Format werden unter anderem Leerzeichen, mit %20 dargestellt. In unserem Fall hier müssen wir nur die Leerzeichen durch %20 ersetzten und hätten das richtige Format. Da es aber im HTML Format auch weitere Zeichen gibt, die umgewandelt werden müssen, kann man die Gerätebeschreibung auch umwandeln lassen. Das geht z.B. mit der Microsoft PowerShell, mit dem Befehl: [System.Uri]::EscapeDataString("Mein Test Text"). Zum Schluss müssen wir noch Eingeben das es ein OPC UA Zertifikat werden soll und das es das Server Zertifikat wird. Eine gute Alternative, um an die korrekte URI zu kommen ist, sich ein Zertifikat mit CODESYS zu erstellen und da die URI herauszukopieren. Leider können wir die URI nicht in diesem Fenster einfügen, daher bestätigen wir mit Übernehmen die bisherigen Eingaben und setzten hinter den Hostname ein Komma. Jetzt können wir die URI einfach hineinkopieren. Wenn wir nochmal das Bearbeiten Fenster öffnen, ist unsere URI korrekt eingefügt. Wir setzten noch den Haken bei Critical und bestätigen mit Übernehmen. Im Tab Schlüsselverwendung müssen beide Critical Haken gesetzt sein und es ist sinnvoll noch zusätzlich bei „Schlüsselverwendung“ Non Repudiation auszuwählen. Wenn wir jetzt in den Erweitert Tab wechseln, sehen wir die Zusammenfassung unserer Einstellungen und haben soweit alles notwendige konfiguriert und bestätigen mit OK. Genauso erstellen wir das Client Zertifikat, jetzt allerdings mit dem Client Template. Wir vergeben ähnlich wie bei dem Serverzertifikat einen internen Namen, allerdings muss der „Common Name“ so lauten. Der Rest ist wie bereits am Server Zertifikaten beschrieben. Die Client URI setzt sich etwas einfacher zusammen aus: URI:urn: dann der Hostname: gefolgt von runtime.opcua.datasource.CODESYS. Hier ist nochmal zusammengefasst, welche Eingaben für die Zertifikate notwendig sind. Dieses Beispiel befindet sich auch in der Videobeschreibung. Damit sind die beiden benötigten Zertifikate erstellt und wir können sie exportieren. Beim Export wählen wir das Dateiformat pfx als Kette aus, womit wir Zertifikat und den Schlüssel in einer Datei haben. Zurück in CODESYS, loggen wir uns zunächst in beide Controller ein. Im Client sollte jetzt auch diese Zeile: Cmp OPC UA Client sein. Ist diese noch nicht vorhanden muss die OPC UA Kommunikation einmal gestartet werden, damit der Controller weiß, dass er ein Client ist. Im Security Screen ist unter dem Aktualisierungs- Button, der Button für den Upload der Zertifikate vom PC an die Controller. Erst wählen wir den Ordner eigene Zertifikate aus, dann laden wir das entsprechende Zertifikat hoch. Je nach Updatestand der CODESYS Version kann es vorkommen das trotz 100% korrekt erstellter Zertifikate die Zertifikate jetzt nicht erkannt werden, also dass das Feld hier vorne leer bleibt. Dann hat man wahrscheinlich einen zu alten Versionsstand der CODESYS Add-ons: CODESYS Communication und CODESYS Security Agent. Kontrollieren kann man das über den CODESYS Installer, das Add On: "CODESYS Communication" benötigt mind. die Version 4.7.0.0 und der "CODESYS Security Agent" die Version 1.4.0.0. Nachdem beide Zertifikate hochgeladen sind und erkannt wurden, erscheinen diese jeweils in dem Quarantäne Ordner des anderen Controllers und wir ziehen sie per Drag and Drop in den Ordner Vertrauenswürdige Zertifikate. Einen häufigen Stolperstein gibt es noch, die Certificate Revocation List, kurz CRL. Das ist die Liste mit gesperrten Zertifikaten. In den CODESYS Standardeinstellungen ist zunächst konfiguriert, dass die Liste vorhanden sein muss. Dazu gibt es zwei Optionen entweder man erstellt eine CRL was auch mit XCA geht und importiert diese oder, da diese in unserem Fall leer ist deaktiviert man die Funktion im Server in den Sicherheitseinstellungen. Unsere OPCA UA Kommunikation funktioniert wieder und die Integer Variable im Client zählt hoch. Jetzt allerdings mit selbst erstellten Zertifikaten verschlüsselt. Damit sind wir am Ende vom Tutorial, welchen Anforderungen eigene Zertifikate für eine OPC UA‑Kommunikation erfüllen müssen und wie man eigene Security‑Zertifikate in CODESYS 3.5 importiert. Hinterlasst uns gerne einen Daumen hoch, wenn euch das Video geholfen hat, abonniert den Kanal und meldet euch im WAGO Support Center, wenn ihr noch Fragen habt.