SNI mit Edge verwenden

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Server Name Indication (SNI) ermöglicht die Bereitstellung mehrerer HTTPS-Ziele über dieselbe IP-Adresse und Port, ohne dass für diese Ziele dasselbe TLS-Zertifikat verwendet werden muss. Wenn SNI aktiviert ist, übergibt der Client den Hostnamen des Zielendpunkts als Teil der TLS-Handshake. Dadurch kann der TLS-Server bestimmen, welches TLS-Zertifikat zur Validierung verwendet werden soll. der Anfrage.

Wenn das Anfrageziel beispielsweise https://example.com/request/path ist, Der TLS-Client fügt dem TLS-Handshake die Erweiterung server_name hinzu. wie unten dargestellt:

Edge unterstützt SNI für:

  • Anfragen von einer Clientanwendung an einen API-Proxy. In diesem Szenario agiert Edge als TLS Server
  • Anfragen von Edge an das Back-End. In diesem Szenario agiert Edge als TLS-Client.

Weitere Informationen zu SNI finden Sie unter:

Unterstützung von SNI für eine Anfrage an den API-Proxy auf Rand

Die SNI-Unterstützung für Anfragen an API-Proxys wird durch Host-Aliase und virtuelle Hosts.

Informationen zu virtuellen Hosts und Host-Aliasse

Bei Edge definiert ein virtueller Host die IP-Adresse und den Port oder den DNS-Namen und den Port auf der ein API-Proxy preisgegeben wird, und somit die URL, über die Apps auf einen API-Proxy zugreifen. Die IP-Adresse bzw. der DNS-Name entspricht einem Edge Router und die Portnummer ist ein offener Port auf der Router.

Wenn Sie den virtuellen Host erstellen, geben Sie auch den Host-Alias des virtuellen Hosts an. In der Regel ist dies der DNS-Name des virtuellen Hosts. Als Teil der Bestimmung des API-Proxys, verarbeitet der Router den Host-Header der eingehenden Anfrage mit dem Liste der verfügbaren Host-Aliasse, die von allen virtuellen Hosts definiert werden.

Die Kombination aus Host-Alias und Portnummer für den virtuellen Host muss für alle virtuelle Hosts in der Edge-Installation. Das bedeutet, dass mehrere virtuelle Hosts dieselbe Portnummer, wenn sie unterschiedliche Host-Aliasse haben.

Ein virtueller Host definiert auch, ob der Zugriff auf den API-Proxy über das HTTP-Protokoll oder HTTPS-Protokoll mit TLS verschlüsselt. Wenn Sie einen virtuellen Host für die Verwendung von HTTPS konfigurieren, den virtuellen Host mit einem Schlüsselspeicher verknüpfen, der das Zertifikat und den privaten Schlüssel enthält, die vom virtueller Host während des TLS-Handshakes.

Weitere Informationen zu virtuellen Hosts finden Sie unter:

Funktionsweise von SNI Host-Aliasse

Mit SNI können mehrere virtuelle Hosts am selben Port definiert werden, die jeweils unterschiedliche TLS-Zertifikate und -Schlüssel. Edge bestimmt dann den virtuellen Host und das von TLS verwendete Zertifikat/Schlüsselpaar. basierend auf server_name in der TLS-Handshakeanfrage.

Der Edge Router liest die Erweiterung server_name im TLS-Handshake und sucht dann damit nach den Host-Aliassen aller virtuellen Hosts. Erkennt der Router eine Übereinstimmung mit einem Hostalias, verwendet er das TLS-Zertifikat und den TLS-Schlüssel von den virtuellen Host, der mit dem Host-Alias verknüpft ist. Wenn keine Übereinstimmung gefunden wird, schlägt der TLS-Handshake fehl.

Anstatt den TLS-Handshake fehlschlagen zu lassen, können Sie ein Standardzertifikat/Schlüsselpaar wie folgt definieren: die in den nächsten Abschnitten beschrieben werden.

Standardzertifikat/Schlüsselpaar in Edge für die Cloud definieren

Apigee bietet ein TLS-Zertifikat und einen privaten Schlüssel zur Unterstützung von HTTPS. Viele Kunden Sie bei der Bereitstellung ein eigenes Zertifikat und einen eigenen privaten Schlüssel verwenden möchten, können Sie Ihre APIs bereitstellen. mit dem Apigee-Zertifikat und dem Apigee-Schlüssel.

Wenn der Router in Edge für die Cloud den SNI-Header nicht mit einem Host-Alias abgleichen kann, oder wenn der Client SNI nicht unterstützt, verwendet der Router das von Apigee bereitgestellte Standardzertifikat. das heißt *.apigee.net.

Standardzertifikat/Schlüsselpaar in Edge für die Private Cloud definieren

Wenn in Edge für die Private Cloud keine Übereinstimmung zwischen der Erweiterung server_name und den Host-Aliassen gefunden wird oder wenn der anfordernde Client SNI nicht unterstützt, Router, der das Zertifikat bzw. den Schlüssel von einem virtuellen Standardhost am Port verwendet. Der standardmäßige virtuelle Host ist definiert durch eine Kombination aus Organisationsname, Umgebungsname und virtuellem Hostnamen im Formular:

orgName_envName_vhName

Der Router verwendet das Zertifikat bzw. den Schlüssel aus der Kombination von orgName_envName_vhName, die in alphabetischer Reihenfolge an erster Stelle. Beispiel: Die Anfrage geht über Port 443 ein und es gibt zwei virtuelle Hosts, die für die Organisation example in der Umgebung prod definiert sind:

  • virtueller Hostname = default
  • virtueller Hostname = test

In diesem Beispiel verwendet der Router das Zertifikat bzw. den Schlüssel vom virtuellen Host mit dem Namen default. weil example_prod_default alphabetisch vor example_prod_test liegt.

So aktivieren Sie den virtuellen Standardhost:

  1. Bearbeiten Sie auf dem ersten Routerknoten /opt/apigee/customer/application/router.properties. Sollte die Datei nicht vorhanden sein, erstellen Sie sie.
  2. Fügen Sie der Datei die folgende Eigenschaft hinzu, damit Sie einen virtuellen Standardhost definieren können: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Starten Sie den Router neu: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Wiederholen Sie diese Schritte auf allen verbleibenden Routern.

Anstatt das Zertifikat bzw. den Schlüssel vom standardmäßigen virtuellen Host zu verwenden, können Sie den Standardzertifikat bzw. Standardschlüssel auf dem Router. Verwenden Sie das folgende Verfahren, um einen expliziten Standard zu definieren Zertifikat/Schlüsselpaar:

  1. Kopieren Sie auf dem ersten Routerknoten das Zertifikat und den privaten Schlüssel an einen Speicherort auf dem Routerknoten. auf die der Apigee-Benutzer zugreifen kann. Beispiel: /opt/apigee/customer/application.
  2. Ändern Sie die Eigentümerschaft der Dateien in den Apigee. Nutzer: 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
     
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. /opt/apigee/customer/application/router.properties bearbeiten Sollte die Datei nicht vorhanden sein, erstellen Sie sie.
  4. Fügen Sie der Datei die folgenden Attribute hinzu, damit Sie das Standardzertifikat bzw. den Standardschlüssel angeben können:
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. Legen Sie die folgenden Eigenschaften in router.properties fest, um den Standort anzugeben. Zertifikat und Schlüssel: 
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. Starten Sie den Router neu: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Wiederholen Sie diese Schritte auf allen verbleibenden Routern.

Unterstützung von SNI für Anfragen von Edge an Backend

Edge unterstützt die Verwendung von SNI von Message Processor zu Zielendpunkten in Apigee Edge für Cloud- und Private Cloud-Bereitstellungen. Standardmäßig ist SNI bei Edge Message Processor aktiviert für die Cloud und deaktiviert in der privaten Cloud.

Mit SNI zum Back-End in Edge für die Private Cloud

Um für Edge für die Private Cloud abwärtskompatibel mit vorhandenen Ziel-Back-Ends zu sein, Apigee hat SNI standardmäßig deaktiviert. Wenn dein Ziel-Back-End so konfiguriert ist, dass es SNI unterstützt, kannst du Aktivieren Sie diese Funktion wie unten beschrieben für Ihre Version von Edge.

Es ist keine weitere Edge-spezifische Konfiguration erforderlich. Wenn Ihre Zielumgebung für SNI, Edge unterstützt es. Edge extrahiert den Hostnamen automatisch aus der Anfrage-URL und fügt ihn hinzu an die TLS-Handshakeanfrage übergeben.

SNI zwischen Edge und dem Backend für Edge-Version 4.15.07.0x aktivieren

Gehen Sie wie folgt vor, um SNI zu aktivieren:

  1. Öffnen Sie die Datei auf dem ersten Message Processor-Knoten. /opt/apigee4/conf/apigee/message-processor/system.properties in einem Editor.
  2. Legen Sie das folgende Attribut in system.properties auf „true“ fest: 
    jsse.enableSNIExtension=true
  3. Starten Sie die Message Processors neu: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Wiederholen Sie diese Schritte für alle verbleibenden Message Processor.

SNI zwischen Edge und dem Backend für Edge-Version 4.16.01 und höher aktivieren

Gehen Sie wie folgt vor, um SNI zu aktivieren:

  1. Bearbeiten Sie /opt/apigee/customer/application/message-processor.properties im ersten Message Processor-Knoten. Sollte die Datei nicht vorhanden sein, erstellen Sie sie.
  2. Fügen Sie der Datei die folgende Eigenschaft hinzu: 
    conf_system_jsse.enableSNIExtension=true
  3. Starten Sie den Message Processor neu: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Wiederholen Sie diese Schritte für alle verbleibenden Message Processor.