TLS_SOCKET_2

Typ	Funktionsbaustein
Beschreibung	Der Funktionsbaustein öffnet und schließt einen TCP/TLS-Socket. (Das TLS-Protokoll arbeitet auf der Basis des TCP). Dieser Socket kann entweder für die Standard-TCP-Kommunikation verwendet werden, oder für die sichere IP-Kommunikation zwischen einem Server und einem Client über TLS (Transport Layer Security). Der TCP/TLS-Socket wird durch den Ausgangsparameter HANDLE repräsentiert. Dieses Handle muss an die Funktionsbausteine TLS_SEND_2 und TLS_RECEIVE_2 übergeben werden. Die FBs benötigen das Sockethandle für den (sicheren) Datenaustausch mit einem Kommunikationspartner. Wird ein Server implementiert, der mit mehreren TCP/TLS-Clients kommunizieren kann, so ist eine TLS_SOCKET_2-Instanz (mit IS_SRV = TRUE) für jeden vorhandenen Client erforderlich. In diesem Szenario verbinden sich die Clients mit der jeweiligen TLS_SOCKET_2-Instanz/HANDLE, wie an DEST_IP/DEST_PORT spezifiziert. Mit einer steigenden Flanke am Eingang ACTIVATE wird begonnen, einen TCP/TLS-Socket zu öffnen. Bei erfolgreichem Öffnen des Sockets und Verbindungsaufbau wird der Ausgang ACTIVE auf TRUE gesetzt. Solange ACTIVE = TRUE ist, kann das Sockethandle am Ausgang HANDLE für den Aufruf der Funktionsbausteine TLS_SEND_2/TLS_RECEIVE_2 verwendet werden. Eine fallende Flanke an ACTIVATE schließt den Socket. Die Verbindung wird mittels eines Drei-Wege-Handshake beendet, d.h. es werden drei Telegramme zwischen Client und Server ausgetauscht. Während des Beendungsprozesses führt eine erneute steigende Flanke zu einem Bausteinfehler. Während ACTIVE = FALSE, führt das Aufrufen von TLS_SEND_2/TLS_RECEIVE_2 mit dem Sockethandle zu einem Fehler an den Funktionsbausteinen. Solange der ACTIVATE-Eingang gesetzt ist, bleibt der Socket geöffnet. Der Ausgang BUSY wird auf TRUE gesetzt, während ACTIVATE = TRUE und der Socket noch nicht geöffnet ist. Bei einer fallenden Flanke des ACTIVATE-Eingangs wird der Socket geschlossen und der Ausgang ACTIVE auf FALSE gesetzt (siehe hierzu auch die nachfolgenden Hinweise). Sollte eine erfolgreich aufgebaute Verbindung geschlossen werden, versucht der Funktionsbaustein diese Verbindung erneut aufzubauen (sofern ACTIVATE = TRUE bleibt). Client- oder Server-Funktionalität? Der Eingang IS_SRV legt fest, ob der Funktionsbaustein eine Verbindung als TCP-Server oder TCP-Client aufbaut. Mit IS_SRV = TRUE erzeugt der Funktionsbaustein einen "horchenden" (listening) Socket (Server-Socket). Der Socket kann an einen lokalen Ethernet-Adapter (Angabe der IP-Adresse am Eingang BIND_IP) und einen Port (Eingang BIND_PORT) gebunden werden. Unter dieser IP-Adresse und Portnummer wartet anschließend der Server auf Anfragen der Clients- Falls erforderlich kann die Anzahl der akzeptierten Clients über die Eingänge DEST_IP/DEST_PORTS limitiert werden. Bei geöffnetem (Server-) Socket sind nur 1:1 Verbindungen möglich. Das bedeutet, der Listening-Socket akzeptiert nur eine eingehende TLS-Verbindung. Wird ein TCP/TLS-Server implementiert, der mit mehreren TCP/TLS-Clients kommunizieren kann, so ist eine dedizierte TLS_SOCKET_2-Instanz pro erwartetem Client erforderlich. Mit IS_SRV = FALSE wird ein Client-Socket erzeugt. In diesem Fall legen DEST_IP/DEST_PORT die IP-Adresse und den Port des Partner-Servers fest, mit dem kommuniziert werden soll. WARNUNG Unbeabsichtigter Betriebszustand des Geräts Stellen Sie sicher, dass das Ändern der Ausgangsdaten nicht zu einem ungewollten oder gefährlichen Verhalten des Gesamtsystems führen kann. TLS "on top" des TCP Der Eingang START_TLS legt fest, ob für den Datenaustausch über die Funktionsbausteine TLS_SEND_2 und TLS_RECEIVE_2 eine reine TCP-Verbindung oder eine TLS-Verbindung verwendet wird. Im typischen Anwendungsfall für den FB TLS_SOCKET_2 liegt am Eingang START_TLS der Wert TRUE an, wenn der ACTIVATE-Eingang TRUE wird. In selteneren Fällen, wie zum Beispiel bei SMTP, wird an START_TLS eine steigende Flanke angelegt, während ACTIVATE auf TRUE gesetzt ist. Wenn nach erfolgreichem Verbindungsaufbau START_TLS = FALSE ist, verwenden die Funktionsbausteine TLS_SEND_2 und TLS_RECEIVE_2 eine TCP-Verbindung, um Daten zu senden bzw. zu empfangen. Die Eingänge SEND_SECURE bzw. RECEIVE_SECURE der Funktionsbausteine müssen dem Wert an START_TLS entsprechen. Liegt nach erfolgreichem Verbindungsaufbau eine steigende Flanke an START_TLS an, wird das TLS-Protokoll initialisiert. Das bedeutet, das TLS-Protokoll wird aufsetzend auf dem TCP-Protokoll verwendet. Solange START_TLS = TRUE, erfolgt das Senden und Empfangen von Daten über eine TLS-gesicherte Verbindung. Für die Initialisierung des TLS-Protokolls werden die Daten am CONNECT_INFO-Eingang verwendet, die zum Zeitpunkt der FB-Aktivierung anlagen. Die vordefinierte Struktur am Eingang CONNECT_INFO enthält unter anderem die im Vertrauensspeicher (TrustStore) und Identitätsspeicher (IdentityStore) der Geräte enthaltenen Zertifikate für die Authentifizierung. (Eine Beschreibung der Werte am CONNECT_INFO und wie Sie Zertifikate im WBM der Steuerung verwalten und verknüpfen finden Sie weiter unten im Thema.)
Hinweise	Die Funktionsbausteine für die TCP/TLS-Kommunikation werden asynchron verarbeitet. Das bedeutet, die Funktionsbausteine erteilen Befehle und warten auf deren Verarbeitung. Das mit dem Funktionsbaustein TLS_SOCKET_2 erzeugte-Sockethandle ist nicht kompatibel mit dem Sockethandle, das mit TCP_SOCKET oder TLS_SOCKET erzeugt wird. Das TCP/TLS-Sockethandle kann nur mit den FBs TLS_SEND_2/TLS_RECEIVE_2 verwendet werden. Die Anzahl der gerade geöffneten-Sockets wird in der Systemvariablen TLS_ACTIVE_SOCKETS gespeichert (enthalten in der Datenliste des Steuerungsknotens und des 'PLC'-Knotens der ANLAGE). Bei einem Warm- oder Kaltstart oder einem Reset der Steuerung, schließt die Firmware alle Sockets, die mit der entsprechenden TLS_SOCKET_2-Instanz geöffnet wurden. Stellen Sie bei Steuerungen mit integrierter Firewall sicher, dass die Firewall nicht die für die Kommunikation benötigten Ports blockiert. Andernfalls kann keine Verbindung hergestellt werden. Alle verwendeten IP-Adressen sind IPv4-Adressen. IPv4-Adressen bestehen aus 4 Zahlen (Werte von 0 bis 255), die durch Punkte voneinander getrennt sind. Funktionsbausteine müssen instanziiert werden. Der FB-Instanzname muss in der 'Variablen'-Tabelle der POE deklariert werden, in welcher der FB verwendet werden soll. Der Instanzname muss innerhalb der POE eindeutig sein. Wenn der Socket geschlossen wird, beispielsweise vom Kommunikationspartner, während ACTIVATE TRUE bleibt, versucht der FB erneut einen Socket zu öffnen. Bei einem erfolgreichen Versuch führt der neue Socket zu einem neuen HANDLE-Wert. Der FB TLS_SOCKET_2 selbst kann keinen Verbindungsabbruch (private close) erkennen. Ein Verbindungsabbruch kann nur beim Senden oder Empfangen von Daten erkannt werden. Aus diesem Grund muss der ERROR-Ausgang der FBs TLS_SEND_2 oder TLS_RECEIVE_2 geprüft werden. Wenn ERROR TRUE ist (oft nur für einen FB-Aufruf), liefert der STATUS-Ausgang zusätzliche Informationen. (Der STATUS-Wert 16#C228 zeigt einen Verbindungsabbruch an.) Ein Verbindungsabbruch (z.B. nicht angeschlossenes Ethernet-Kabel) wird mit Hilfe des TCP-Features "keep alive" erkannt. Die Erkennung kann mehrere Sekunden dauern (bei den meisten PLCnext-Steuerungen sind dies ca. 40 Sek.,abhängig von der Einstellung im Betriebssystem der Steuerung). Gleichzeitig können bis zu 64 Sockets aktiviert werden (siehe auch Statuscode 0xC201).
Parameter	Eingänge Hinweis Die für den Aufbau der TLS-Kommunikation auf Basis (d.h."on top") der TCP-Kommunikation relevanten Parameter sind CONNECT_INFO und START_TLS. Die übrigen Eingänge spezifizieren TCP-Funktionalität. ACTIVATE Datentyp: BOOL Beschreibung: Bei einer steigenden Flanke am Eingang wird begonnen, den TCP/TLS-Socket zu öffnen. Solange der ACTIVATE-Eingang gesetzt ist, bleibt der Socket geöffnet. Bei einer fallenden Flanke wird der Socket geschlossen. Wenn der Kommunikationspartner die Verbindung schließt während der ACTIVATE-Eingang TRUE bleibt, versucht der FB eine neue Verbindung herzustellen. Da das Schließen des Sockets einige Zeit in Anspruch nimmt (Drei-Wege-Handshake zwischen Client und Server), darf die nächste steigende Flanke erst an ACTIVATE anliegen, wenn die Ausgänge ACTIVE und BUSY beide FALSE sind. Andernfalls (d.h. falls eine neue Verbindung angefordert wird, obwohl der vorherige Socket noch nicht vollständig geschlossen ist) führt dies zu einem Fehler und es wird der Fehlercode 16#C205 am STATUS-Ausgang ausgegeben. IS_SRV Datentyp: BOOL Beschreibung: Legt fest, ob der Funktionsbaustein eine Server- oder Client-Funktion realisiert. TRUE: Der Funktionsbaustein erzeugt einen "horchenden" Socket (Server-Socket). Wird ein Server implementiert, der mit mehreren TCP/TLS-Clients kommunizieren kann, muss für jede TLS_SOCKET_2-Instanz dieses Servers der Eingang IS_SRV = TRUE gesetzt werden. FALSE: Der Funktionsbaustein erzeugt einen Client-Socket. Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. BIND_IP Datentyp: STRING Beschreibung: Für IS_SRV = TRUE gilt: Dieser Parameter gibt die IP-Adresse an, auf welcher der Server auf eingehende Verbindungen hört. Für Clients, die eine Verbindung zum Server herstellen möchten, muss am DEST_IP-Eingang dieselbe IP-Adresse angegeben werden. Wird ein leerer String (Anfangswert des Parameters) oder '0.0.0.0' angegeben, hört der Server über jeden Ethernet-Adapter der Steuerung. Für IS_SRV = FALSE gilt: In diesem Fall ist der Parameter optional. Falls spezifiziert, identifiziert er den Ethernet-Adapter der Steuerung, über den die Kommunikation erfolgen soll. Andernfalls (leerer String oder Wert '0.0.0.0'), wählt die Steuerung gemäß dem Parameter DEST_IP den passenden Ethernet-Adapter aus. Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. BIND_PORT Datentyp: UINT Beschreibung: Gibt die lokale Portnummer an, an welchen der erzeugte Socket gebunden ist (notwendig zur Realisierung eines TCP/TLS-Servers). Die ausgewählte Portnummer wird vom TCP/TLS-Server für eingehende Daten verwendet. Für Clients, die eine Verbindung zum Server herstellen möchten, muss am DEST_PORT-Eingang dieselbe Portnummer angegeben werden. Ist der Wert 0 (Anfangswert des Parameters), wählt der Stack einen temporären Port aus. Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. DEST_IP Datentyp: STRING Beschreibung: Abhängig von der realisierten Funktion des FBs (Verwendung als Server oder Client; eingestellt über den Eingang IS_SRV), gilt folgendes: Mit IS_SRV = TRUE (der FB erzeugt einen horchenden Socket) werden nur Anfragen des Clients mit dieser IP-Adresse akzeptiert. Wird ein leerer String (Anfangswert des Parameters) angegeben, wird jede Client-IP-Adresse akzeptiert. Wird ein Server realisiert, der mit mehreren TCP/TLS-Clients kommunizieren kann, so ist eine TLS_SOCKET_2-Instanz (mit IS_SRV = TRUE) für jeden vorhandenen Client erforderlich. In diesem Fall adressiert DEST_IP der betreffenden FB-Instanz einen spezifischen Client. Der Ausgangsparameter SOURCE_IP des TLS_RECEIVE_2-FB liefert die IP-Adresse seines Kommunikationspartners. Mit IS_SRV = FALSE (FB erzeugt einen Client-Socket) definiert der Parameter die IP-Adresse des Partner-Servers, mit dem kommuniziert werden soll. Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. DEST_PORT Datentyp: UINT Beschreibung: Abhängig von der realisierten Funktion des FBs (Verwendung als Server oder Client; eingestellt über den Eingang IS_SRV), gilt folgendes: Mit IS_SRV = TRUE (der FB erzeugt einen horchenden Socket) werden nur Anfragen des Clients mit diesem IP-Port akzeptiert. Wird der Wert 0 (Anfangswert des Parameters) angegeben, wird jeder Client-IP-Port akzeptiert. Der Ausgangsparameter SOURCE_PORT des TLS_RECEIVE_2-FB liefert die Portnummer seines Kommunikationspartners. Mit IS_SRV = FALSE (FB erzeugt ein Client-Socket) definiert der Parameter den IP-Port des Partner-Servers, mit dem kommuniziert werden soll. Der Funktionsbaustein wertet diesen Parameter nur in dem Taskzyklus aus, in dem am ACTIVATE-Eingang eine steigende Flanke erkannt wird. CONNECT_INFO Datentyp: ConnectInfo (vordefinierte Struktur) Beschreibung: Attribute zur Initialisierung des TLS-Protokolls auf Basis ("on top") des TCP. Die Werte werden in dem Zyklus mit der steigenden Flanke am ACTIVATE-Eingang ausgelesen. Die ausgelesenen Werte werden verwendet, sobald am Eingang START_TLS der Wert TRUE anliegt. Die Struktur enthält die folgenden vordefinierten Elemente: Strukturelement Datentyp Beschreibung TrustStoreName STRING Name des Vertrauensspeichers (TrustStore). Der TrustStore wird während der Kommunikation über SSL verwendet, um das Gegenstellenzertifikat zu prüfen. Mit den Informationen aus dem TrustStore kann der Server die Identität von Clients authentifizieren, die sich mit dem Server verbinden möchten. Er validiert dazu die Echtheit des Zertifikats, das jeder Client präsentiert. Die Vertrauensspeicher (TrustStores) und die enthaltenen Zertifikate können über das Web-based Management (WBM) der Steuerung verwaltet werden. So können Sie Zertifikate auch während des laufenden Betriebs austauschen, ohne das Anwendungsprogramm ändern zu müssen. Eine Beschreibung wie Sie im WBM der Steuerung Zertifikate des IdentityStores und TrustStores verwalten und verknüpfen finden Sie im unten stehenden Abschnitt "Zusatzinformationen". Weitere Infos Weitere Informationen zu den Zertifikaten für die sichere Kommunikation der Steuerung finden Sie im PLCnext Info Center. Hintergrundinformationen Ein TrustStore ist ein (durch den TrustStore-Namen identifizierter) spezieller persistenter Speicherbereich, der Kriterien zum Verifizieren der Zertifikate enthält, mit denen sich die Kommunikationspartner authentifizieren. Das bedeutet, der Inhalt des TrustStore ermöglicht die Überprüfung der Echtheit eines Zertifikats, das ein potenzieller Kommunikationspartner vorzeigt. IdentityStoreName STRING Name des Identitätsspeichers (IdentityStore). Der IdentityStore enthält die Server-Zertifikate, zusammen mit einem privaten Schlüssel. Die Zertifikate werden zur Kommunikation über SSL zur Authentifizierung zwischen dem Server und den Clients verwendet. Wenn der Server als TLS-Server verwendet wird, muss hier ein Wert angegeben werden. Der IdentityStore-Name muss beim Aufbau einer sicheren Verbindung zwingend vom Server angegeben werden. Die Identitätsspeicher (IdentityStores), die enthaltenen Zertifikate und Schlüsselpaare können über das Web-based Management (WBM) der Steuerung verwaltet werden. So können Sie Zertifikate auch während des laufenden Betriebs austauschen, ohne das Anwendungsprogramm ändern zu müssen. Eine Beschreibung wie Sie im WBM der Steuerung Zertifikate des IdentityStores und TrustStores verwalten und verknüpfen finden Sie im unten stehenden Abschnitt "Zusatzinformationen". Weitere Infos Weitere Informationen zu den Zertifikaten für die sichere Kommunikation der Steuerung finden Sie im PLCnext Info Center. Hintergrundinformationen Ein IdentityStore ist ein (durch den IdentityStore-Namen identifizierter) spezieller persistenter Speicherbereich, der z.T. streng geheime Daten enthält, mit denen sich ein Gerät bei seinen Kommunikationspartnern identifizieren kann.   Die Daten beinhalten ein asymmetrisches Schlüsselpaar (bestehend aus dem öffentlichen und dem privaten Schlüssel). Dieses Schlüsselpaar geht einher mit einem entsprechenden Zertifikat zum öffentlichen Schlüssel (gem. dem Standard X.509) und optional auch mit Ausstellerzertifikaten bis hinauf zum Trusted Anchor (Wurzelzertifikat oder Anker für Vertrauensstellung).   Zur Authentifizierung nutzt das Gerät sein asymmetrisches Schlüsselpaar. Entweder betrachtet der Kommunikationspartner den öffentlichen Schlüssel als vertrauenswürdig (weil er dessen Identität kennt) oder das Gerät übermittelt zusätzlich sein Zertifikat (das seine Identität ausweist), welches der Kommunikationspartner dann verifiziert. In hierarchischen Zertifizierungsstrukturen muss das Gerät auch die in seinem IdentityStore hinterlegten Ausstellerzertifikate senden, damit der Kommunikationspartner den gesamten Zertifizierungspfad validieren kann. CipherList STRING Chiffrekombinationen, die für den Aufbau der sicheren TLS-Verbindung verwendet werden sollen. Ab Firmware-Version 2019.6 der Steuerung, verwendet der Funktionsbaustein die in der openSSL-Bibliothek implementierte Default Cipher Liste, wenn keine Cipher Liste angegeben wird. Bei älteren Firmware-Versionen müssen Sie eine nicht leere Cipher Liste angeben, da ansonsten keine TLS-Verbindung aufgebaut wird, wenn der FB ausgeführt wird. Hintergrundinformationen Ein Chiffre ist ein kryptographischer Algorithmus zum Ver- und Entschlüsseln von Informationen. Chiffren sind in Chiffrensammlungen (Cipher Suites) zusammengefasst. Die Cipher Suite bestimmt, welcher Algorithmus für den Aufbau der sicheren Verbindung verwendet werden soll. Das TLS-Protokoll unterstützt eine Vielzahl von Cipher Suites zur gegenseitigen Authentifizierung von Server und Client. Im Rahmen der sicheren Verbindung einigen sich Server und Client über die zu verwendende Cipher Suite, je nachdem, welche Chiffren dem Client und dem Server jeweils für den Datenaustausch zur Verfügung stehen. HostName STRING Name der Gegenstelle; wird mit dem Namen des Gegenstellenzertifikats verglichen. Der HostName wird für Clients verwendet und ist optional. Er erhöht die Sicherheit bei der Authentizitätsprüfung. START_TLS Datentyp: BOOL Beschreibung: Legt fest, ob die Kommunikation über TCP oder TLS stattfindet. Nach einem erfolgreichen Verbindungsaufbau gilt folgendes: Bei START_TLS = FALSE verwenden die Funktionsbausteine TLS_SEND_2 und TLS_RECEIVE_2 eine reine TCP-Verbindung, um Daten zu senden bzw. zu empfangen. Bei START_TLS = TRUE wird das TLS-Protokoll initialisiert und die bestehende TCP-Verbindung wird durch eine TLS-Verbindung ersetzt. Das Senden und Empfangen von Daten erfolgt über eine TLS-gesicherte Verbindung. Für die Initialisierung des TLS-Protokolls werden die zum Zeitpunkt der FB-Aktivierung am Eingang CONNECT_INFO anliegenden Daten verwendet (siehe oben). Das Wechseln von START_TLS auf FALSE bei geöffnetem TLS-Socket führt zu einem Fehler (Ausgang ERROR = TRUE), der am Ausgang STATUS mit dem Fehlercode 16#C151 angezeigt wird. Hinweis Der Wert für START_TLS wird mit dem Wert verglichen, der an den Eingängen SEND_SECURE bzw. RECEIVE_SECURE der Funktionsbausteine TLS_SEND_2 bzw. TLS_RECEIVE_2 anliegt. Werden Inkonsistenzen zwischen den Eingangswerten festgestellt, zum Beispiel bei SEND_SECURE = TRUE (IEC-Anwendung erfordert sichere Datenübertragung) und START_TLS = FALSE (TLS-Protokoll noch nicht initialisiert), geben die FBs TLS_SEND_2 und TLS_RECEIVE_2 einen Fehler aus (Ausgang ERROR = TRUE und Fehlercode 16#C150 am Ausgang STATUS). Hinweis Das Zurücksetzen von START_TLS auf FALSE kann nicht zum Deaktivieren des TLS-Protokolls und Reaktivieren des TCP-Protokolls verwendet werden. Dies wird vom Baustein nicht unterstützt. Ausgänge HANDLE Datentyp: DWORD Beschreibung: Das erzeugte Handle des TCP/TLS-Sockets. Das Sockethandle wird als Eingangswert für die Funktionsbausteine TLS_RECEIVE_2 und TLS_SEND_2 benötigt, um bspw. Daten an einen TLS-Server zu senden bzw. von diesem zu empfangen. Das Sockethandle kann nur für einen Aufruf der Funktionsbausteine TLS_SEND_2 und TLS_RECEIVE_2 verwendet werden, solange ACTIVE = TRUE ist. Das Aufrufen eines TLS_*-Funktionsbausteins während ACTIVE = FALSE ist, führt zu einem Fehler (eine entsprechende Fehlermeldung wird am Ausgang STATUS der TLS_*-Funktionsbausteine ausgegeben). Hinweis Der HANDLE-Wert kann sich ändern, wenn der Ausgang ACTIVE auf FALSE und später wieder zurück auf TRUE wechselt. ACTIVE Datentyp: BOOL Beschreibung: Zeigt an, ob ein Socket geöffnet ist. TRUE: Die Verbindung wurde erfolgreich aufgebaut und der Socket ist geöffnet. Solange ACTIVE = TRUE ist, kann das erzeugte Sockethandle (HANDLE-Eingang) von den Funktionsbausteinen TLS_SEND_2 und TLS_RECEIVE_2 verwendet werden, um Daten zu senden bzw. zu empfangen. Hinweis Ein Handle, das mit einer Instanz der älteren Implementierung des Funktionsbausteins TCP_SOCKET oder TLS_SOCKET erzeugt wurde, darf nicht mit den neuen Funktionsbausteinen TLS_SEND_2/TLS_RECEIVE_2 verwendet werden und umgekehrt. Verwenden Sie Handles nur innerhalb derselben "FB-Generation". FALSE: Der Socket ist geschlossen. Während ACTIVE = FALSE ist, führt das Aufrufen von TLS_SEND_2/TLS_RECEIVE_2 mit dem Sockethandle zu einem Fehler an den Funktionsbausteinen. BUSY Datentyp: BOOL Beschreibung: Wird auf TRUE gesetzt, wenn ACTIVATE = TRUE ist, der Socket aber noch nicht geöffnet ist. Nach erfolgreichem Öffnen des Sockets wird BUSY auf FALSE gesetzt und bleibt FALSE, solange ACTIVE = TRUE ist. Wenn ACTIVATE = FALSE wird (fallende Flanke), wird der Ausgang BUSY auf TRUE gesetzt, solange der Prozess des Beendens nicht abgeschlossen ist. ERROR Datentyp: BOOL Beschreibung: Bei einem Fehler wird der Ausgang ERROR auf TRUE gesetzt. Der zugehörige Fehlercode kann am Ausgang STATUS ausgelesen werden, solange ERROR = TRUE ist. Siehe Fehlercodes / Statuscodes für TLS*-Funktionsbausteine . STATUS Datentyp: WORD Beschreibung: Liefert den Fehlercode im Fehlerfall (ERROR = TRUE) oder den aktuellen Status des Funktionsbausteins (ERROR = FALSE). Fehlercodes beginnen mit 16#Cxxx und Statuscodes mit 16#8xxx. Solange der ACTIVATE-Eingang auf TRUE gesetzt ist, versucht die FB-Instanz einen Socket zu öffnen. Tritt ein Fehler auf, steuert die FB-Instanz den Ausgang ERROR auf TRUE. Gleichzeitig liefert der STATUS-Ausgang Informationen zur Fehlerursache. Die Ausgänge ERROR und STATUS werden nur für einen Zyklus gesetzt. Beim nächsten Aufruf wird erneut versucht, diesen Socket zu öffnen. Die Versuche werden solange wiederholt, wie ACTIVATE TRUE bleibt. Siehe Fehlercodes / Statuscodes für TLS*-Funktionsbausteine . USED_PORT Datentyp: UINT Beschreibung: Zeigt den Port an, der für die Erzeugung des Sockets verwendet wird (entweder automatisch vergeben oder die am Eingang BIND_PORT angegebene Portnummer). Der Ausgang kann bei Bedarf für Diagnosezwecke verwendet werden.
Zusätzliche Informationen	Verwalten und Verknüpfen von Zertifikaten im TrustStore und IdentityStore Die Zertifikate des IdentityStores und TrustStores für die sichere Kommunikation der Steuerung werden im WBM der Steuerung verwaltet. Im Bereich 'Security' auf der Seite 'Zertifikatauthentifizierung' können Sie verschiedene TrustStores und IdentityStores anlegen und Zertifikate hinzufügen. Um eine gesicherte TLS-Kommunikation zwischen Server und Client bei Verwendung des Funktionsbausteins TLS_SOCKET_2 zu gewährleisten, müssen der TrustStore und IdentityStore, die auf der Seite 'Zertifikatauthentifizierung' hinzugefügt wurden, den Elementen TrustStoreName und IdentityStoreName der Struktur CONNECT_INFO (siehe oben) zugewiesen werden. Um einen TrustStore und IdentityStore im WBM der Steuerung anzulegen und ein Zertifikat dem TrustStore und IdentityStore hinzuzufügen, gehen Sie wie folgt vor: TrustStore und zugehöriges Zertifikat hinzufügen: Öffnen Sie im WBM der Steuerung im Bereich 'Security' die Seite 'Zertifikatauthentifizierung'. Klicken Sie auf der Registerkarte 'TrustStores' auf die Schaltfläche '+' am Ende der TrustStores-Tabelle. Geben Sie im sich öffnenden Dialog einen Namen in das Eingabefeld 'Bezeichnung' ein (z.B. 'ServerTrustStore') und klicken Sie anschließend auf die Schaltfläche 'Hinzufügen'. Hinweis Der hier eingegebene TrustStore-Name (in unserem Beispiel 'ServerTrustStore') muss mit dem Element TrustStoreName der Struktur CONNECT_INFO verknüpft werden. Klicken Sie auf die Schaltfläche '+' unter der Tabelle 'Zertifikate' des neu hinzugefügten TrustStore. Der Dialog 'Zertifikat hinzufügen' wird geöffnet Wählen Sie im Dialog 'Zertifikat hinzufügen' die Einstellungen wie im folgenden Bild gezeigt und klicken Sie anschließend auf die 'Durchsuchen'-Schaltfläche. Wählen Sie im sich öffnenden Datei-Explorer das Zertifikat (im .pem-Format) und klicken Sie anschließend auf 'Hinzufügen'. IdentityStore und zugehöriges Zertifikat hinzufügen: Öffnen Sie im WBM der Steuerung im Bereich 'Security' die Seite 'Zertifikatauthentifizierung'. Klicken Sie auf der Registerkarte 'IdentityStores' auf die Schaltfläche '+' am Ende der IdentityStores-Tabelle. Geben Sie im sich öffnenden Dialog einen Namen in das Eingabefeld 'Bezeichnung' ein (z.B. 'Client') und klicken Sie anschließend auf die Schaltfläche 'Hinzufügen'. Hinweis Der hier eingegebene IdentityStore-Name (in unserem Beispiel 'Client') muss mit dem Element IdentityStoreName der Struktur CONNECT_INFO verknüpft werden. Klicken Sie auf die Schaltfläche '+' unter der Tabelle 'Zertifikate' des neu hinzugefügten IdentityStore. Der Dialog 'IdentityStore hinzufügen' wird geöffnet. Wählen Sie im Dialog 'IdentityStore hinzufügen' die Einstellungen wie im folgenden Bild gezeigt und klicken Sie anschließend auf die 'Durchsuchen'-Schaltfläche. Wählen Sie im sich öffnenden Datei-Explorer das Schlüsselpaar (im .pem-Format) und klicken Sie anschließend auf 'Hinzufügen'. Im letzten Schritt müssen Sie das 'Client'-Zertifikat hinzufügen. Klicken Sie dazu auf die Schaltfläche rechts neben der 'Zertifikate'-Zeile in der IdentityStore-Tabelle. Der Dialog 'Schlüsselzertifikat setzen' wird geöffnet. Wählen Sie im Dialog 'Schlüsselzertifikat setzen' die Optionen wie im vorigen Schritt gezeigt. Wählen Sie anschließend das Schlüsselpaar und klicken dann auf 'Hinzufügen'.