Generieren eines selbstsignierten Azure Application Gateway-Zertifikats mit einer benutzerdefinierten Stammzertifizierungsstelle

Die Anwendungsgateway-SKU v2 führt die Verwendung vertrauenswürdiger Stammzertifikate ein, um TLS-Verbindungen mit den Back-End-Servern zuzulassen. Dieses Feature entfernt die Verwendung von Authentifizierungszertifikaten (einzelne Leaf-Zertifikate), die in der v1-SKU erforderlich waren. Das Stammzertifikat ist ein Base-64-codiertes X.509 (.CER) Format-Stammzertifikat vom Backend-Zertifikatserver. Es identifiziert die Stammzertifizierungsstelle, die das Serverzertifikat ausgestellt hat, und das Serverzertifikat wird dann für die TLS/SSL-Kommunikation verwendet.

Das Anwendungsgateway vertraut standardmäßig dem Zertifikat Ihrer Website, wenn eine bekannte Zertifizierungsstelle (z. B. GoDaddy oder DigiCert) sie signiert. Das explizite Hochladen des Stammzertifikats ist in diesem Fall nicht erforderlich. Weitere Informationen finden Sie unter Übersicht über TLS-Beendigung und End-to-End TLS mit Anwendungsgateway. Wenn Sie jedoch über eine Entwicklungs-/Testumgebung verfügen und kein überprüftes Zertifizierungsstellenzertifikat erwerben möchten, können Sie ihre eigene benutzerdefinierte Stammzertifizierungsstelle und ein blattbasiertes Zertifikat erstellen, das von dieser Stammzertifizierungsstelle signiert ist.

Note

Selbst generierte Zertifikate sind standardmäßig nicht vertrauenswürdig und können schwierig verwaltet werden. Außerdem können sie veraltete Hash- und Verschlüsselungssammlungen verwenden, die nicht stark sind. Um eine bessere Sicherheit zu erreichen, sollten Sie ein Zertifikat kaufen, das von einer bekannten Zertifizierungsstelle signiert ist.

Verwenden Sie die folgenden Optionen, um Ihr privates Zertifikat für BACK-End-TLS-Verbindungen zu generieren.

1. Verwenden Sie das Tool für den privaten Zertifikatgenerator. Mithilfe des von Ihnen bereitgestellten Domänennamens (gemeinsamer Name) führt dieses Tool die gleichen Schritte wie in diesem Artikel beschrieben aus, um Stamm- und Serverzertifikate zu generieren. Mit den generierten Zertifikatdateien können Sie die Stammzertifikatsdatei (.CER) sofort in die Back-End-Einstellungen Ihres Gateways hochladen und die entsprechende Zertifikatkette (.PFX) auf den Back-End-Server übertragen. Das Kennwort für die PFX-Datei wird auch in der heruntergeladenen ZIP-Datei angegeben.

2. Verwenden Sie OpenSSL-Befehle, um Zertifikate entsprechend Ihren Anforderungen anzupassen und zu generieren. Folgen Sie den Anweisungen in diesem Artikel weiter, wenn Sie diesen Vorgang ganz allein ausführen möchten.

In diesem Artikel erfahren Sie, wie Sie:

• Erstellen Einer eigenen benutzerdefinierten Zertifizierungsstelle
• Erstellen eines selbstsignierten Zertifikats, das von Ihrer benutzerdefinierten Zertifizierungsstelle signiert ist
• Hochladen eines selbstsignierten Stammzertifikats in ein Anwendungsgateway zum Authentifizieren des Back-End-Servers

Prerequisites

• OpenSSL auf einem Computer unter Windows oder Linux

  Während andere Tools möglicherweise für die Zertifikatverwaltung verfügbar sind, verwendet dieses Lernprogramm OpenSSL. Sie finden OpenSSL gebündelt mit vielen Linux-Distributionen wie Ubuntu.

• Ein Webserver

  Beispielsweise Apache, IIS oder NGINX, um die Zertifikate zu testen.

• Eine Application Gateway v2-SKU

  Wenn Sie nicht über ein vorhandenes Anwendungsgateway verfügen, lesen Sie die Schnellstartanleitung: Direkter Webdatenverkehr mit Azure-Anwendungsgateway – Azure-Portal.

Erstellen eines Stammzertifikats der Zertifizierungsstelle

Erstellen Sie Ihr Stamm-CA-Zertifikat mithilfe von OpenSSL.

Erstellen des Stammschlüssels

1. Melden Sie sich bei Ihrem Computer an, auf dem OpenSSL installiert ist, und führen Sie den folgenden Befehl aus. Dieser Befehl erzeugt den privaten Wurzelschlüssel. Der Schlüssel ist nicht verschlüsselt und nicht durch ein Passwort geschützt, also bewahren Sie die contoso.key Datei sicher auf.

   openssl ecparam -out contoso.key -name prime256v1 -genkey
   

Erstellen eines Stammzertifikats und selbst signieren

1. Verwenden Sie den folgenden Befehl, um die Zertifikatsignaturanforderung (Certificate Signing Request, CSR) zu generieren.

   openssl req -new -sha256 -key contoso.key -out contoso.csr
   

2. Wenn du aufgefordert wirst, gib die Organisationsinformationen der benutzerdefinierten CA ein, wie Land/Region, Bundesstaat, Organisation, OU und den voll qualifizierten Domainnamen (diese Domain ist der Herausgeber). Da der Root-Schlüssel nicht passwortgeschützt ist, fragt OpenSSL dich nicht nach einem Passwort.

   

3. Verwenden Sie den folgenden Befehl, um das Stammzertifikat zu generieren.

   openssl x509 -req -sha256 -days 365 -in contoso.csr -signkey contoso.key -out contoso.crt
   

   Die vorherigen Befehle erstellen das Stammzertifikat. Sie verwenden dieses Zertifikat, um Ihr Serverzertifikat zu signieren.

Erstellen eines Serverzertifikats

Als Nächstes erstellen Sie ein Serverzertifikat mithilfe von OpenSSL.

Erstellen des Zertifikatschlüssels

Verwenden Sie den folgenden Befehl, um den Schlüssel für das Serverzertifikat zu generieren.

openssl ecparam -out fabrikam.key -name prime256v1 -genkey

CSR (Zertifikatsignierungsanforderung) erstellen

Die CSR ist ein öffentlicher Schlüssel, den Sie bei der Anforderung eines Zertifikats an eine Zertifizierungsstelle übergeben. Die Zertifizierungsstelle gibt das Zertifikat für diese bestimmte Anforderung aus.

Note

Der CN (Gemeinsamer Name) für das Serverzertifikat muss sich von der Domäne des Ausstellers unterscheiden. Zum Beispiel ist in diesem Fall der CN für den Aussteller www.contoso.com, und das CN des Serverzertifikats ist www.fabrikam.com.

1. Verwenden Sie den folgenden Befehl, um die CSR zu generieren:

   openssl req -new -sha256 -key fabrikam.key -out fabrikam.csr
   

2. Auf Nachfrage geben Sie die Organisationsinformationen für die benutzerdefinierte CA ein: Land/Region, Bundesstaat, Organisation, OU und den vollständig qualifizierten Domainnamen. Diese Domäne ist die Domäne der Website und sollte sich vom Aussteller unterscheiden. Wie beim Root-Key ist auch der Serverschlüssel nicht passwortgeschützt, sodass OpenSSL dich nicht nach einem Passwort fragt.

   

Generieren Sie das Zertifikat mit der CSR und dem Schlüssel, und signieren Sie es mit dem Stammschlüssel der Zertifizierungsstelle.

1. Verwenden Sie den folgenden Befehl, um das Zertifikat zu erstellen:

   openssl x509 -req -in fabrikam.csr -CA  contoso.crt -CAkey contoso.key -CAcreateserial -out fabrikam.crt -days 365 -sha256
   

Überprüfen des neu erstellten Zertifikats

1. Verwenden Sie den folgenden Befehl, um die Ausgabe der CRT-Datei zu drucken und deren Inhalt zu überprüfen:

   openssl x509 -in fabrikam.crt -text -noout
   

   

2. Überprüfen Sie die Dateien in Ihrem Verzeichnis, und stellen Sie sicher, dass Sie über die folgenden Dateien verfügen:

   • contoso.crt
   • contoso.key
   • fabrikam.crt
   • fabrikam.key

Konfigurieren des Zertifikats in den TLS-Einstellungen Ihres Webservers

Konfigurieren Sie in Ihrem Webserver TLS mithilfe der Dateien fabrikam.crt und fabrikam.key. Wenn Ihr Webserver keine zwei Dateien aufnehmen kann, können Sie sie mithilfe von OpenSSL-Befehlen in einer einzelnen PEM- oder PFX-Datei kombinieren.

IIS

Anweisungen zum Importieren und Hochladen von Zertifikaten als Serverzertifikat auf IIS finden Sie unter HOW TO: Install Imported Certificates on a Web Server in Windows Server 2003.

Anweisungen zur TLS-Bindung finden Sie unter Einrichten von SSL unter IIS 7.

Apache

Die folgende Konfiguration ist ein Beispiel für einen virtuellen Host, der für SSL in Apache konfiguriert ist:

<VirtualHost www.fabrikam:443>
      DocumentRoot /var/www/fabrikam
      ServerName www.fabrikam.com
      SSLEngine on
      SSLCertificateFile /home/user/fabrikam.crt
      SSLCertificateKeyFile /home/user/fabrikam.key
</VirtualHost>

NGINX

Die folgende Konfiguration ist ein Beispiel für einen NGINX-Serverblock mit TLS-Konfiguration:

Zugreifen auf den Server mit dem selbstsignierten Zertifikat

1. Fügen Sie das Stammzertifikat zum vertrauenswürdigen Stammspeicher Ihres Computers hinzu. Stellen Sie beim Zugriff auf die Website sicher, dass die gesamte Zertifikatkette im Browser angezeigt wird.

   

   Note

   DNS sollte so konfiguriert werden, www.fabrikam.comdass der Webservername (in diesem Beispiel) auf die IP-Adresse Ihres Webservers verweist. Wenn nicht, können Sie die Hostdatei bearbeiten, um den Namen aufzulösen.

2. Navigieren Sie zu Ihrer Website, und klicken Sie auf das Sperrsymbol im Adressfeld Ihres Browsers, um die Website- und Zertifikatinformationen zu überprüfen.

Überprüfen der Konfiguration mit OpenSSL

Sie können auch OpenSSL verwenden, um das Zertifikat zu überprüfen.

openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts

Laden Sie das Root-Zertifikat in die Backend-Einstellungen von Application Gateway hoch

Application Gateway akzeptiert ein vertrauenswürdiges Root-Zertifikat nur als Base-64-codiertes X.509-Zertifikat, das die Dateiendung .cer verwendet. Die Base64-codierte X.509-Darstellung ist eine Textkodierung, und genau diese Kodierung hat der openssl x509-Befehl bereits weiter oben in diesem Artikel für die Datei contoso.crt erzeugt.

Da contoso.crt bereits den öffentlichen Schlüssel im Base-64-kodierten Format enthält, benennen Sie die Dateiendung von .crt in .cer. Diese Umbenennung ändert nur die Dateiendung. Die Kodierung des Zertifikats wird nicht umgewandelt, und hier ist keine Konvertierung erforderlich. Ein Zertifikat, das nicht bereits mit Base-64 codiert ist, erfordert eine tatsächliche Kodierungskonvertierung statt einer Umbenennung.

Azure portal

Um das vertrauenswürdige Stammzertifikat aus dem Portal hochzuladen, wählen Sie die Back-End-Einstellungen und https im Back-End-Protokoll aus.

Azure PowerShell

Oder verwenden Sie Azure CLI oder Azure PowerShell, um das Stammzertifikat hochzuladen. Die folgenden Azure PowerShell-Schritte fügen dem Anwendungsgateway ein vertrauenswürdiges Root-Zertifikat hinzu, erstellen eine Gesundheitsprobe, erstellen eine Backend-Einstellung, fügen eine Routing-Regel hinzu und wenden die Änderungen dann am Gateway an.

Note

Diese Schritte gehen davon aus, dass das Anwendungs-Gateway appgwv2 in der Ressourcengruppe rgOne, der Backend-Pool testbackendpool und der Listener basichttps bereits existieren. Führe die Schritte der Reihe nach in derselben PowerShell-Sitzung aus, da jeder Schritt das $gw Objekt verwendet, das der erste Schritt abruft.

Schritt 1: Fügen Sie das vertrauenswürdige Root-Zertifikat hinzu

Dieser Schritt setzt voraus, dass das Anwendungsgateway appgwv2 bereits in der Ressourcengruppe rgOne existiert. Es ruft das Gateway ab und speichert es in der Variablen $gw, die in allen späteren Schritten verwendet wird, und lädt die Datei contoso.cer hoch, die Sie zuvor umbenannt haben.

## Add the trusted root certificate to the Application Gateway

$gw=Get-AzApplicationGateway -Name appgwv2 -ResourceGroupName rgOne

Add-AzApplicationGatewayTrustedRootCertificate `
   -ApplicationGateway $gw `
   -Name CustomCARoot `
   -CertificateFile "C:\Users\surmb\Downloads\contoso.cer"

$trustedroot = Get-AzApplicationGatewayTrustedRootCertificate `
   -Name CustomCARoot `
   -ApplicationGateway $gw

Schritt 2: Erstellen Sie die Gesundheitssonde

Dieser Schritt setzt voraus, dass du die Variable $gw aus Schritt 1 hast. Es erstellt eine HTTPS-Probe für www.fabrikam.com und speichert sie in der Variable $probe .

Add-AzApplicationGatewayProbeConfig `
  -ApplicationGateway $gw `
  -Name testprobe `
  -Protocol Https `
  -HostName "www.fabrikam.com" `
  -Path "/" `
  -Interval 15 `
  -Timeout 20 `
  -UnhealthyThreshold 3

$probe = Get-AzApplicationGatewayProbeConfig `
  -Name testprobe `
  -ApplicationGateway $gw

Schritt 3: Erstellen Sie die Backend-Einstellung

Dieser Schritt setzt voraus, dass Sie die $gw, $trustedroot, und $probe Variablen aus den vorherigen Schritten haben. Es erstellt die Backend-Einstellung, die das vertrauenswürdige Root-Zertifikat und die Probe verwendet.

## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
## to the domain name of the server certificate as this will be set as the SNI header and
## will be used to verify the backend server's certificate. Note that TLS handshake will
## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes

Add-AzApplicationGatewayBackendHttpSettings `
  -ApplicationGateway $gw `
  -Name testbackend `
  -Port 443 `
  -Protocol Https `
  -Probe $probe `
  -TrustedRootCertificate $trustedroot `
  -CookieBasedAffinity Disabled `
  -RequestTimeout 20 `
  -HostName www.fabrikam.com

$backendhttp = Get-AzApplicationGatewayBackendHttpSettings `
  -Name testbackend `
  -ApplicationGateway $gw

Schritt 4: Erstellen Sie die Routing-Regel

Dieser Schritt setzt voraus, dass du die $gw Variable aus Schritt 1 und die $backendhttp Variable aus Schritt 3 hast und dass der Listener Basichttps sowie der Backend-Pool testbackendpool bereits auf dem Gateway existieren.

$listener = Get-AzApplicationGatewayHttpListener `
   -Name basichttps `
   -ApplicationGateway $gw

$bepool = Get-AzApplicationGatewayBackendAddressPool `
  -Name testbackendpool `
  -ApplicationGateway $gw

Add-AzApplicationGatewayRequestRoutingRule `
  -ApplicationGateway $gw `
  -Name testrule `
  -RuleType Basic `
  -BackendHttpSettings $backendhttp `
  -HttpListener $listener `
  -BackendAddressPool $bepool

Schritt 5: Aktualisieren Sie das Anwendungsgateway

Die vorherigen Schritte ändern nur das $gw Objekt im Speicher. Dieser Schritt setzt voraus, dass Sie über die Variable $gw aus Schritt 1 verfügen, auf die alle vorherigen Änderungen angewendet wurden, und überträgt diese Änderungen auf das Gateway in Azure.

Set-AzApplicationGateway -ApplicationGateway $gw

Überprüfen Sie den Backend-Zustand des Anwendungsgateways

1. Wählen Sie die Ansicht Backend-Status Ihres Application Gateways, um zu überprüfen, ob die Probes intakt ist.
2. Sie sollten sehen, dass der Status für die HTTPS-Probe fehlerfrei ist.

Nächste Schritte

Weitere Informationen zu SSL\TLS im Anwendungsgateway finden Sie in einer Übersicht über TLS-Termination und End-to-End-TLS mit dem Anwendungsgateway.