Teilen über


MQTT-Clientauthentifizierung mit Zertifikaten

MQTT Vermittler von Azure Event Grid unterstützt die Authentifizierung von Clients mit X.509-Zertifikaten. Das X.509-Zertifikat stellt die Anmeldeinformationen bereit, um einen bestimmten Client dem Mandanten zuzuordnen. In diesem Modell erfolgt die Authentifizierung in der Regel einmal während der Sitzungseinrichtung. Dann wird davon ausgegangen, dass alle zukünftigen Vorgänge, die dieselbe Sitzung verwenden, von dieser Identität stammen.

Folgende Authentifizierungsmodi werden unterstützt:

  • Von einer Zertifizierungsstelle ausgestellte Zertifikate
  • Selbstsigniertes Clientzertifikat – Fingerabdruck
  • Microsoft Entra ID-Token

Der Schwerpunkt dieses Artikels liegt auf Zertifikaten. Informationen zur Authentifizierung mit Microsoft Entra ID-Token finden Sie unter Microsoft Entra JWT-Authentifizierung und Azure RBAC-Autorisierung für das Veröffentlichen oder Abonnieren von MQTT-Nachrichten.

Von einer Zertifizierungsstelle (ZS) signierte Zertifikate:

Bei dieser Methode wird ein X.509-Stamm- oder Zwischenzertifikat bei dem Dienst registriert. Im Wesentlichen muss das Stamm- oder Zwischenzertifikat, das zum Signieren des Clientzertifikats verwendet wird, zunächst bei dem Dienst registriert werden.

Wichtig

  • Laden Sie das Stamm- oder Zwischenzertifikat hoch, das zum Signieren des Clientzertifikats verwendet wird. Es ist nicht erforderlich, die gesamte Zertifikatskette hochzuladen.
  • Wenn Sie z. B. eine Kette von Stamm-, Zwischen- und Clientzertifikaten besitzen, stellen Sie sicher, dass Sie das Zwischenzertifikat hochladen, mit dem die Clientzertifikate signiert wurden.

Screenshot: Seite der Zertifizierungsstellenzertifikate mit den Stamm- und Zwischenzertifikaten, die zum Signieren der Clientzertifikate verwendet werden

Bei der Registrierung von Clients müssen Sie das Zertifikatfeld identifizieren, das für den Authentifizierungsnamen des Clients verwendet wird. Der Dienst gleicht den Authentifizierungsnamen aus dem Zertifikat mit dem Authentifizierungsnamen des Clients in den Clientmetadaten ab, um den Client zu überprüfen. Der Dienst überprüft auch das Clientzertifikat, indem er überprüft, ob es von dem zuvor registrierten Stamm- oder Zwischenzertifikat signiert wurde.

Screenshot: Clientmetadaten mit den fünf zertifikatskettenbasierten Validierungsschemata

Selbstsigniertes Clientzertifikat – Fingerabdruck

Bei dieser Authentifizierungsmethode speichert die Clientregistrierung den genauen Fingerabdruck des Zertifikats, das der Client zur Authentifizierung verwendet. Wenn der Client versucht, eine Verbindung mit dem Dienst herzustellen, überprüft der Dienst den Client, indem er den im Clientzertifikat angezeigten Fingerabdruck mit dem in den Clientmetadaten gespeicherten Fingerabdruck vergleicht.

Screenshot: Clientmetadaten mit fingerabdruckabhängigem Authentifizierungsschema

Hinweis

  • Wir empfehlen, dass Sie den Namen der Clientauthentifizierung in das Feld „Benutzername“ des Clientverbindungspakets aufnehmen. Verwenden Sie diesen Authentifizierungsnamen zusammen mit dem Clientzertifikat, kann der Dienst den Client authentifizieren.
  • Wenn Sie den Authentifizierungsnamen nicht im Feld „Benutzername“ angeben, müssen Sie die alternativen Quellfelder für den Clientauthentifizierungsnamen im Namespacebereich konfigurieren. Der Dienst sucht nach dem Clientauthentifizierungsnamen im entsprechenden Feld des Clientzertifikats, um die Clientverbindung zu authentifizieren.

Auf der Konfigurationsseite im Namespacebereich können Sie alternative Namensquellen für die Clientauthentifizierung aktivieren und dann die Felder des Clientzertifikats auswählen, die den Namen der Clientauthentifizierung enthalten.

Screenshot: Konfigurationsseite für Namespace mit den Einstellungen für den Namen der alternativen Quelle der Clientauthentifizierung

Die Reihenfolge der Auswahl der Clientzertifikatfelder auf der Konfigurationsseite für den Namespace ist wichtig. Der Dienst sucht in den Feldern des Clientzertifikats in der gleichen Reihenfolge nach dem Namen der Clientauthentifizierung.

Wenn Sie z. B. zuerst die Option „Zertifikat-DNS“ und dann die Option „Antragstellername“ auswählen, während Sie die Clientverbindung authentifizieren,

  • überprüft der Dienst das DNS-Feld für den alternativen Antragstellernamen des Clientzertifikats zuerst auf den Clientauthentifizierungsnamen.
  • Wenn das DNS-Feld leer ist, prüft der Dienst das Feld „Antragstellername“ des Clientzertifikats.
  • Wenn der Clientauthentifizierungsname in keinem dieser beiden Felder vorhanden ist, wird die Clientverbindung verweigert.

In beiden Modi der Clientauthentifizierung erwarten wir, dass der Name der Clientauthentifizierung entweder im Feld „Benutzername“ des Verbindungspakets oder in einem der Felder des Clientzertifikats angegeben wird.

Unterstützte Clientzertifikatfelder für alternative Quelle des Clientauthentifizierungsnamens

Sie können eines der folgenden Felder verwenden, um den Clientauthentifizierungsnamen im Clientzertifikat anzugeben.

Option für Authentifizierungsnamenquelle Zertifikatfeld BESCHREIBUNG
Zertifikatsantragstellername tls_client_auth_subject_dn Der Distinguished Name des Antragstellers für das Zertifikat.
Zertifikat-DNS tls_client_auth_san_dns Der SAN-Eintrag dNSName im Zertifikat.
Zertifikat-URI tls_client_auth_san_uri Der SAN-Eintrag uniformResourceIdentifier im Zertifikat.
Zertifikat-IP-Adresse tls_client_auth_san_ip Die IPv4- oder IPv6-Adresse, die im „iPAddress SAN“-Eintrag im Zertifikat vorhanden ist.
Zertifikat-E-Mail tls_client_auth_san_email Der SAN-Eintrag rfc822Name im Zertifikat.

Nächste Schritte