Lektion 2.3 IoT-Nodes und Netzwerkprotokolle - Von NB-IoT bis BLE

LoRaWAN ist der gängigste Gerätetyp in modernen Langstrecken-IoT-Netzwerken. Wir haben behandelt, wie man sie hinzufügt und verwaltet, in Lektion 1.1: Neue LoRaWAN-Geräte hinzufügen.

In dieser Lektion untersuchen wir, wie man verschiedene Arten von Geräten zum System hinzufügt, kategorisiert nach dem Transportprotokoll, das sie verwenden. Die meisten davon werden über das Gerät Generic hinzugefügt. Wir heben auch die zugrunde liegenden physikalischen oder Netzwerktechnologien hervor, die typischerweise mit jedem Protokoll verbunden sind, um zu verstehen, welche Geräte über MQTT, HTTP, TCP, UDP, CoAP und andere gängige Schnittstellen kommunizieren.

Der IoT-Stack - Netzwerktechnologie

Gängige physikalische Protokolle und ihre Transportprotokolle

Die folgende Tabelle ordnet die physikalischen/Netzwerkprotokolle den Transportprotokollen zu, die sie typischerweise verwenden.

Physikalisches/Netzwerkprotokoll	Typisches Transportprotokoll	Beispielgeräte
NB-IoT	MQTT, CoAP, UDP	Smart Meter, Asset-Tracker, Umweltsensoren
LTE Cat-M1 (Cat-M)	MQTT, CoAP, UDP	Wearables, Flotten-Tracker, Industriesensoren
LoRaWAN	MQTT	Gateways, Umweltsensoren, Smart Meter
WLAN	HTTP, MQTT, TCP	Smart-Home-Geräte, Kameras, Smart Plugs, Thermostate
Ethernet	HTTP, MQTT, TCP	Industrielle Steuerungen, SPS, Gateways
BLE / Bluetooth	Gateway zu MQTT/HTTP/CoAP	Wearables, Beacons, Smart Locks, Medizingeräte
Zigbee, Zwave, Matter	Gateway zu MQTT	Hausautomation
CoAP	UDP, CoAP	Ressourcenbeschränkte Sensoren und Aktuatoren, Smart Meter, Smart-Building-Geräte
Raw TCP	TCP	Industrielle Geräte, Gateways, Kameras, benutzerdefinierte IoT-Geräte

Einige Geräte verwenden leichtgewichtige oder ressourcenbeschränkte Protokolle wie CoAP über UDP oder BLE, die oft ein Gateway benötigen, um ihre Nachrichten in MQTT, HTTP oder TCP für die Integration mit der Plattform zu übersetzen. Dies stellt sicher, dass auch stromsparende oder Kurzstreckengeräte zuverlässig mit Cloud-Systemen oder anderen vernetzten Diensten kommunizieren können.

Ähnlich werden Protokolle wie LwM2M - Lightweight Machine-to-Machine typischerweise auf NB-IoT- oder Cat-M1-Geräten implementiert und verwenden CoAP über UDP zur Kommunikation, wobei oft ein LwM2M-Server erforderlich ist, um Geräteregistrierung, Datenberichte und Fernverwaltung zu handhaben. Die IoT-Plattform enthält einen LWM2M-Server, ist derzeit aber nur auf besondere Anfrage verfügbar.

Horizontale IoT-Integration

Die Plattform - Horizontale IoT-Integration
↑
├─ LwM2M (Gerätemanagement & Telemetrie)
↑
Anwendungsprotokolle
├─ HTTP (REST API)
├─ MQTT (Pub/Sub)
├─ CoAP (REST für ressourcenbeschränkte Geräte)
Transport
├─ TCP ← HTTP, MQTT, Raw TCP, LwM2M (über TCP)
└─ UDP ← CoAP, rohes UDP, LwM2M (über UDP/CoAP)
Netzwerk
└─ IP Internet Protocol, zuständig für Adressierung und Routing von Datenpaketen unabhängig vom Medium
Link-/Physical-Medium
├─ Ethernet
├─ WLAN
├─ LTE/NB-IoT/LTE-M/5G
├─ LoRaWAN
└─ Bluetooth / BLE / Z-Wave / ZigBee

Das obige Diagramm veranschaulicht die horizontale Integration von IoT-Geräten in der IoT-Plattform.

• Anwendungsprotokolle wie HTTP, MQTT und CoAP werden von Geräten verwendet, um mit der Plattform zu kommunizieren, abhängig von ihren Fähigkeiten und Einschränkungen.
• Transportprotokolle (TCP oder UDP) transportieren diese Nachrichten über das Netzwerk, wobei TCP für zuverlässige Verbindungen (HTTP, MQTT, LwM2M) und UDP für leichtgewichtige oder ressourcenbeschränkte Protokolle (CoAP, rohes UDP, LwM2M über UDP) verwendet wird.
• Die Netzwerkschicht (IP) übernimmt Adressierung und Routing und stellt sicher, dass Daten unabhängig vom zugrunde liegenden physikalischen Medium das richtige Ziel erreichen.
• Link-/Physical-Schicht-Technologien umfassen Ethernet, WLAN, LTE/NB-IoT/LTE-M/5G, LoRaWAN und Kurzstreckenprotokolle wie Bluetooth/BLE, Z-Wave oder ZigBee.

Diese Struktur zeigt, wie die Plattform eine breite Vielfalt an Geräten und Protokollen unterstützt und eine nahtlose Integration über heterogene IoT-Netzwerke hinweg ermöglicht.

Generic Node

Es gibt zwei Hauptkategorien von Connectors, die erforderlich sind, um Geräte basierend auf den oben genannten Protokollen zur Plattform hinzuzufügen:

• Geräte, die einen globalen generischen Connector verwenden
• Geräte, die einen spezifischen Connector benötigen

Geräte, die einen generischen Connector benötigen, können nur hinzugefügt werden, wenn Sie Zugriff auf diesen Connector haben – entweder während der Lektion bereitgestellt oder von Ihnen erstellt. Das Einrichten spezifischer Geräte-Connectors erfordert Zugriff auf das entsprechende Gerät oder entfernte System für die richtige Konfiguration. Weitere Details finden Sie unter Lektion 2.8: Connectors.

Der Gerätetyp Generic ist der flexibelste Gerätetyp in Yggio, der Daten über verschiedene Protokolltypen empfangen kann. Er ermöglicht die Integration jedes Geräts, das Daten über Transportprotokolle wie HTTP (inkl. Rest API), MQTT, CoAP, UDP oder Raw TCP übertragen kann und durch eine eindeutige Kennung identifiziert werden kann. Beispiele umfassen NB-IoT-Geräte, Cat-M-Geräte, BLE, WLAN-Geräte, TCP/IP-Geräte (wie Kameras oder Gateways) oder verschiedene Webdienste, die Daten an Yggio senden.

Der Gerätetyp Generic wird auch verwendet, um virtuelle Nodes zu erstellen, die mit Daten aus Übersetzern oder Flows befüllt werden können. Es ist eine sehr vielseitige Integration.

Unterstützte Identifikatoren

Jedes generische Gerät wird durch eine eindeutige ID identifiziert, die auf mehreren unterstützten Identifikatoren basieren kann:

Identifikatorname	Beschreibung
secret	Ein String zwischen 8 und 128 Zeichen, der nur A-Z, 0-9, -, ., _ enthält
imei	International Mobile Equipment Identity, 15-stellige Zahl
tag	Beliebiger String
serialNumber	Beliebiger String
sensorId	Beliebiger String

Schritte zum Hinzufügen eines generischen Gerätetyps

Erstellen Sie den Geräte-Node über die Device List (oder via API, gemäß Geräte zu Yggio hinzufügen):

1. Navigieren Sie zu Devices im oberen Panel.
2. Klicken Sie auf New Device in der oberen rechten Ecke.
3. Wählen Sie Single Mode.
4. Wählen Sie Generic aus dem Dropdown-Menü und klicken Sie auf Continue.
5. Geben Sie das eindeutige Secret für das Gerät ein und klicken Sie auf Continue.
6. (Optional) Weisen Sie einen Device Model Name zu, klicken Sie dann auf Continue oder Skip.
7. (Optional) Fügen Sie einen Übersetzer hinzu, indem Sie auf +Add Translator klicken, oder Skip.
8. Geben Sie einen Gerätenamen und (optional) Beschreibung, Standort oder kontextuelle Parameter an, klicken Sie dann auf Add Device.

Hinweis: Wenn Sie einen anderen Identifikator als "secret" verwenden möchten, müssen Sie derzeit Swagger verwenden und einen PUT /iotnodes-Request auf den Node ausführen, nachdem er erstellt wurde.

HTTP-Generic-Nodes

Beginnen wir die Lektion, indem wir einen standardmäßigen generischen Node mit secret als Identifikator hinzufügen. Beachten Sie, dass dieses Secret als API-Schlüssel fungiert und vertraulich behandelt werden muss. Daten in einem HTTP-Node können durch eine HTTP-POST-Anfrage aktualisiert werden – entweder von einem IoT-Gerät, einem externen Datenanbietersystem oder direkt über Tools wie curl, Postman, Node-RED oder eine ähnliche Anwendung, die HTTP-POST-Anfragen senden kann.

curl -sS https://staging.yggio.net/http-push/generic?identifier=secret \
-H 'content-type: application/json' \
-d @- <<EOF
{
  "secret": "SUPERSECRETAPIKEY",
  "temperature": 22,
  "data": "any",
  "informationArray": [1, 2, 3],
  "anObject": {
    "nestedValue": "is allowed"
  }
}

MQTT-Generic-Nodes

MQTT-Nodes werden häufig verwendet, um Daten von verschiedenen Arten von Geräten und Systemen zu empfangen. Der Prozess zur Erstellung von MQTT-Nodes ist unkompliziert, erfordert aber etwas Vertrautheit mit der Swagger-API-UI. Melden Sie sich mit Ihrem Benutzernamen und Passwort bei Swagger an, oder verwenden Sie ein Token aus der UI.

Schritte zum Erstellen eines MQTT-Nodes

1. Ein Basic Credential Set erstellen
   Verwenden Sie den Swagger-UI-Endpunkt, um ein neues Basic Credential Set zu erstellen. Dies wird als Zugangsdaten verwendet, um MQTT-Daten zu abonnieren.

2. Ein Reserved MQTT Topic erstellen
   Verwenden Sie den Swagger-UI-Endpunkt, um ein Reserved MQTT Topic zu erstellen. Dies ist das Topic, auf dem das entfernte Gerät oder System Daten veröffentlichen soll. Wichtig: Das Topic muss mit yggio/generic/v2/ beginnen.

3. Das entfernte System konfigurieren
   Legen Sie die folgenden Parameter am entfernten Gerät oder System fest:

   • URL: mqtt.staging.yggio.net
   • Port: 8883
   • Zugangsdaten: Verwenden Sie Ihr Basic Credential Set
   • Topic: Ihr reserviertes MQTT-Topic
   • Version: 3.11 oder 5.0

Sobald Daten veröffentlicht werden, wird automatisch ein neues MQTT-Gerät mit dem Namen erstellt:
MQTT-[Ihr reserviertes MQTT-Topic].

Folgen Sie den obigen Schritten, um einen MQTT-Node zu erstellen. Verwenden Sie nach der Erstellung des MQTT-Nodes ein Tool wie MQTT Explorer oder Node-RED, um Testdaten zu veröffentlichen und zu überprüfen, ob es ordnungsgemäß funktioniert.

Hinweise

• Sie müssen keine Subtopics unter Ihrem Haupttopic reservieren.
• Wenn Sie an Subtopics veröffentlichen, werden diese automatisch als Objekt auf Ihrem Haupt-Node veröffentlicht.
• Sie können AdditionalDeviceUpdate in einem Übersetzer verwenden, um Daten an andere Nodes weiterzugeben.
• Diese Technik wird häufig verwendet, wenn Ihr Haupt-MQTT-Topic-Gerät als Gateway fungiert.

CoAP-Generic-Nodes

Das CoAP-Protokoll verwendet UDP als Transportschicht anstelle von TCP wie HTTP und MQTT, was es leichtgewichtig und gut geeignet für ressourcenbeschränkte IoT-Geräte macht. Im Gegensatz zu TCP baut UDP keine dauerhaften Verbindungen auf, daher implementiert CoAP eigene Mechanismen für Nachrichtenzuverlässigkeit, Bestätigungen und erneute Übertragungen.

Für CoAP-Nodes wird ein CoAP-Connector benötigt. Jeder Plattformserver sollte standardmäßig einen generischen CoAP-Connector enthalten. Wenn Sie keinen Zugriff darauf haben, wenden Sie sich an Ihren technischen Support-Ansprechpartner, um ihn anzufordern.

Sobald der Zugriff gewährt wurde, erstellen Sie einen generischen Node und verwenden Sie das Präfix generic_coap_ für Ihr secret (siehe das Node-RED-Beispiel unten). Beim Senden von Daten von einem IoT-Gerät senden Sie eine POST-Anfrage an: coap://staging.yggio.net:5683/in/generic, einschließlich des secret und seines Werts im JSON-Body. Die CoAP-Integration unterscheidet zwischen Daten ein und aus, daher muss die URL /in/generic/ enthalten.

1. Setzen Sie die Lektion fort, indem Sie ein CoAP-Gerät erstellen. Stellen Sie zunächst sicher, dass Sie Zugriff auf einen generischen CoAP-Connector haben, und erstellen Sie dann einen entsprechenden generischen Node mit einem secret.

2. Senden Sie als Nächstes Daten an den Node, entweder mit einem CoAP-fähigen Gerät oder einem geeigneten Tool, das CoAP-Anfragen generieren kann.

Hinweise:
Verschiedene Hersteller implementieren CoAP-Nachrichtenformate unterschiedlich. Wenn die CoAP-Nachricht Ihres Geräts nicht an die generische Integration angepasst werden kann, könnte eine spezifische Integration erforderlich sein. Wenden Sie sich in diesem Fall an Ihr technisches Support-Team, um den erforderlichen Arbeitsumfang zu bestimmen.

Sicherheit:

1. CoAP-Nachrichten sollten mit DTLS geschützt werden. Zertifikate müssen sowohl auf dem Gerät als auch auf der Plattform installiert sein. Wenn ein Zertifikat erforderlich ist, muss ein neuer CoAP-Connector erstellt werden, der es enthält.
2. Die Plattform unterstützt auch OSCORE (Object Security for Constrained RESTful Environments), das Ende-zu-Ende-Sicherheit auf Nachrichtenebene für CoAP bietet. OSCORE ist standardmäßig nicht aktiviert – wenn Sie es benötigen, wenden Sie sich an Ihr technisches Support-Team, um Aktivierung und Konfiguration zu besprechen.

Weitere Informationen zu DTLS-Zertifikaten finden Sie im Kapitel unten.

UDP-Generic-Nodes

Diese Nodes verwenden das UDP-Protokoll direkt. Derzeit ist die einzige verfügbare UDP-Integration für IM-Buildings-NB-IoT-Geräte, da es derzeit keine generische UDP-Integration gibt. IM-Buildings-Geräte verwenden ein herstellerspezifisches Protokoll, um übertragene Daten zu kodieren. Die Integration dekodiert die Payload, extrahiert die Sensor-ID und leitet die Daten an das entsprechende Gerät in der Plattform weiter.

So erstellen Sie ein IM-Buildings-NB-IoT-Gerät:

1. Stellen Sie sicher, dass ein IM Buildings UDP Connector auf Ihrer Plattform verfügbar ist.
2. Erstellen Sie einen generischen Node und weisen Sie ihm einen beliebigen zufälligen Wert als secret zu.
3. Fügen Sie den IM-Buildings-Übersetzer hinzu
4. Kopieren Sie die _id des neu erstellten Geräts.
5. Öffnen Sie die Swagger-UI, navigieren Sie zu PUT /iotnode/{_id} und fügen Sie ein Feld namens sensorId hinzu, das Ihrem IM-Buildings-Gerät entspricht.
6. Aktivieren Sie Ihr IM-Buildings-Gerät – es beginnt nun, UDP-Daten an die Plattform zu senden.

Additional Device Update

Additional Device Update bedeutet, dass ein Node Daten mit einem anderen Node teilt. Diese Funktion wird häufig in den folgenden Szenarien verwendet:

• Fortgeschrittene Data Flows: Daten bewegen sich zwischen Nodes in verschiedenen Konfigurationen (viele-zu-eins, eins-zu-viele oder viele-zu-viele), wobei jeder Node einen Teil der Verarbeitungslogik beiträgt. Ein häufiges Beispiel dafür ist die Berechnung von Key Performance Indicators (KPIs).

• Kontrollierter Datenzugriff: Eingehende Daten werden in mehrere Nodes aufgeteilt, um Zugriffsrechte zu verwalten. Dies ist notwendig, wenn verschiedene Teile der Daten unterschiedliche Klassifizierungsstufen haben. Zum Beispiel könnte Netzwerkkonnektivität für Netzwerkadministratoren relevant sein, während Messwerte nur für autorisiertes Personal sichtbar sein sollten.

Virtuelle Nodes

Ein logischer Node, der im Datenfluss verwendet wird, um eine Art Zustand zu halten oder indirekt ein physisches Gerät zu repräsentieren – wie einen Geofence, ein WLAN-Beacon, einen berechneten Node oder ein simuliertes Gerät.

Das obige Bild veranschaulicht Geofence-Referenz-Nodes, bei denen Assets, die Geofences betreten und verlassen, vom Übersetzer general-geofence verfolgt werden.

Sicherheit und Zertifikate

TLS/SSL-Zertifikate für MQTT- und HTTP-Verbindungen

Wenn die Plattform mit anderen Systemen (wie MQTT-Brokern, REST-APIs oder IoT-Servern) über TLS/SSL kommuniziert, muss sie in der Lage sein, die von diesen Servern präsentierten Zertifikate zu verifizieren und ihnen zu vertrauen. In den meisten Fällen verwenden Server Zertifikate, die von einer öffentlichen Zertifizierungsstelle (CA) signiert sind, denen automatisch vertraut wird. Wenn der andere Server jedoch ein privates oder selbstsigniertes Zertifikat verwendet (z. B. hinter einer Firewall oder in einem geschlossenen Unternehmensnetzwerk), ist zusätzliche Konfiguration erforderlich.

Wichtige Überlegungen für private Zertifikate

1. Dem Zertifikat vertrauen

   • Die Plattform muss dem vom externen Server präsentierten Zertifikat vertrauen können. Dies geschieht typischerweise, indem das Zertifikat des Servers oder die CA, die es ausgestellt hat, zu den vertrauenswürdigen Zertifikaten der Plattform hinzugefügt wird.

2. Servername-Abgleich (CN und SAN)

   • Das Zertifikat muss den korrekten Common Name (CN) oder Subject Alternative Name (SAN) enthalten, der mit dem Hostnamen oder der IP-Adresse des Servers übereinstimmt.
   • Der CN ist der primäre Identifikator für den Server, während SANs die Einbeziehung mehrerer Hostnamen oder IPs ermöglichen.
   • Wenn der von der Plattform zur Verbindung verwendete Hostname weder mit dem CN noch mit einem der SAN-Einträge übereinstimmt, schlägt der TLS-Handshake fehl.

3. Mutual TLS (mTLS)

   • Wenn der externe Server eine gegenseitige Authentifizierung erfordert, muss die Plattform zusätzlich zum Vertrauen des Servers ihr eigenes Zertifikat vorlegen.
   • Dies stellt sicher, dass beide Seiten sich gegenseitig verifizieren, bevor Daten ausgetauscht werden.

4. Zertifikatsablauf und -erneuerung

   • Private Zertifikate haben oft kürzere Gültigkeitsdauern. Es ist wichtig, Ablaufdaten zu überwachen und Zertifikate rechtzeitig zu erneuern, um Kommunikationsunterbrechungen zu vermeiden.

5. Konnektivität testen

   • Überprüfen Sie nach der Installation oder dem Vertrauen eines Zertifikats, ob die Plattform erfolgreich eine sichere Verbindung zum Server herstellen kann.

6. Sichere Konnektivität testen

   • Für MQTT:

     mosquitto_sub --cafile private-ca.crt -h your.mqtt.server -p 8883 -t test/topic -v

   • Für HTTPS:

     curl --cacert private-ca.crt https://your.private.api/health

DTLS-Zertifikate für CoAP- und UDP-Verbindungen

CoAP verwendet DTLS (Datagram Transport Layer Security) über UDP, um die Kommunikation zwischen IoT-Geräten und der Plattform zu schützen. DTLS bietet Verschlüsselung, Integrität und Authentifizierung – ähnlich wie TLS bei HTTPS –, ist aber für leichtgewichtigen, unzuverlässigen Transport wie UDP optimiert. DTLS unterstützt mehrere Authentifizierungsmethoden:

• X.509-Zertifikate (am gebräuchlichsten und sichersten)
• Pre-Shared Keys (PSK)
• Raw Public Keys (RPK)

Bei Verwendung von X.509-Zertifikaten müssen sowohl das CoAP-Gerät als auch die Plattform übereinstimmende und vertrauenswürdige Zertifikate installiert haben.

🔧 Installationshinweise

1. Zertifikatsformat

   • Verwenden Sie Zertifikate im PEM- oder DER-Format (.pem, .crt oder .der).
   • Stellen Sie sicher, dass die Zertifikatskette (Gerät, Zwischen- und Root-CA) korrekt konfiguriert ist, falls zutreffend.

2. Schutz des privaten Schlüssels

   • Der zum Zertifikat gehörende private Schlüssel darf niemals geteilt oder offengelegt werden.
   • Speichern Sie ihn sicher auf dem Gerät (z. B. in einem sicheren Element oder verschlüsseltem Speicher).

3. Zertifikatsabgleich

   • Das Feld Common Name (CN) oder Subject Alternative Name (SAN) im Zertifikat sollte mit der von der Plattform erwarteten Geräte-ID oder Domain übereinstimmen.
   • Nicht übereinstimmende Identifikatoren können zu DTLS-Handshake-Fehlern führen.

4. Plattforminstallation

   • Importieren Sie das CA-Zertifikat (oder das Gerätezertifikat, falls selbstsigniert) in die CoAP-Connector-Konfiguration der Plattform.
   • Einige Plattformen erfordern einen Neustart des Connectors, nachdem neue Zertifikate hinzugefügt wurden.

5. Zertifikatsablauf und -erneuerung

   • Überwachen Sie Ablaufdaten von Zertifikaten und richten Sie einen automatisierten Erneuerungs- oder Update-Prozess ein, um Ausfallzeiten zu vermeiden.

6. Testen und Verifizierung

   • Überprüfen Sie nach der Installation die Konnektivität mit DTLS-Testtools (z. B. coap-client mit --dtls-Optionen).
   • Prüfen Sie Logs auf erfolgreiche Handshakes und bestätigen Sie verschlüsselten Datenverkehr.

coap-client -m get coaps://SERVER_HOST:5684/RESOURCE \
  --cert client-cert.pem \
  --key client-key.pem \
  --cacert ca-cert.pem

--cert → Client-Zertifikat (falls Mutual TLS erforderlich ist) --key → zugehöriger privater Schlüssel --cacert → CA-Zertifikat zur Verifizierung des Servers

Erfolgsindikator:

• Verify return code: 0 (ok)
• DTLS-Handshake wird erfolgreich abgeschlossen
• Nachrichten können sicher über UDP ausgetauscht werden

Häufige Probleme

1. CN/SAN-Mismatch → DTLS-Handshake schlägt fehl, wenn das Zertifikat nicht mit dem Server-Hostnamen oder der IP übereinstimmt.
2. Nicht vertrauenswürdige CA → DTLS-Handshake schlägt fehl, wenn das Server-Zertifikat nicht von einer vertrauenswürdigen CA signiert ist.
3. Abgelaufenes Zertifikat → DTLS-Handshake schlägt fehl.
4. UDP-Firewalls → Stellen Sie sicher, dass der DTLS-Port (üblicherweise 5683/5684 für CoAPS) geöffnet ist.

Zusammenfassung

Wenn ein Server oder Gerät private oder selbstsignierte Zertifikate verwendet, muss die Plattform so konfiguriert werden, dass sie diesen Zertifikaten vertraut, um eine sichere Kommunikation aufrechtzuerhalten. Zertifikate müssen den korrekten CN oder SAN aufweisen, der mit dem Server-Hostnamen übereinstimmt, und ordnungsgemäße Zertifikatsverwaltung – einschließlich Mutual TLS, falls erforderlich, und rechtzeitiger Erneuerung – ist für zuverlässigen und sicheren Betrieb unerlässlich.

• Verwenden Sie einen DTLS-fähigen CoAP-Client oder OpenSSL, um Verbindungen zu testen.
• Stellen Sie die richtigen CA- und Client-Zertifikate bereit.
• Überprüfen Sie, ob der Handshake erfolgreich ist und Zertifikate korrekt validiert werden.
• Prüfen Sie Logs auf CN/SAN-Validierung und etwaige Handshake-Fehler.