Property-Referenz für virtuelle Hosts

Gibt den Namen des virtuellen Hosts an. Mit diesem Namen verweisen Sie beim Konfigurieren eines API-Proxys auf den virtuellen Host.

Folgende Zeichen sind im Attribut „name“ zulässig: A–Z, 0–9, ._\-$%.

Gibt die vom virtuellen Host verwendete Portnummer an. Der Port muss am Edge-Router geöffnet sein.

Wenn Sie in einem hostalias-Element einen Port angeben, muss die mit <Port> angegebene Portnummer mit dieser übereinstimmen.

In der Cloud: Sie müssen beim Erstellen eines virtuellen Hosts den Port 443 angeben. Wenn Sie den Port weglassen, wird standardmäßig 443 verwendet. Wenn Sie einen vorhandenen virtuellen Host haben, der einen anderen Port als 443 verwendet, können Sie den Port nicht ändern.

Für Private Cloud-Releases 4.16.01 bis 4.17.05:Wenn Sie einen virtuellen Host erstellen, geben Sie den Routerport an, der vom virtuellen Host verwendet wird. Beispiel: Port 9001. Standardmäßig wird der Router als Nutzer „apigee“ ausgeführt, der keinen Zugriff auf privilegierte Ports hat, in der Regel Ports 1024 und niedriger. Wenn Sie einen virtuellen Host erstellen möchten, der den Router an einen geschützten Port bindet, müssen Sie den Router so konfigurieren, dass er als Nutzer mit Zugriff auf diese Ports ausgeführt wird. Weitere Informationen finden Sie unter Virtuellen Host einrichten.

Bei Private Cloud-Releases vor 4.16.01:Ein Router kann nur eine HTTPS-Verbindung pro virtuellem Host, an einem bestimmten Port und mit dem angegebenen Zertifikat überwachen. Daher können mehrere virtuelle Hosts nicht dieselbe Portnummer verwenden, wenn die TLS-Beendigung am Router am angegebenen Port erfolgt.

Der Wert von BaseUrl muss das Protokoll enthalten (d.h. „http://“ oder „https://“).

Ein OCSP-Client (Online Certificate Status Protocol) sendet eine Statusanfrage an einen OCSP-Responder, um zu ermitteln, ob das TLS-Zertifikat gültig ist. Die Antwort gibt an, ob das TLS-Zertifikat gültig und nicht widerrufen wurde.

Wenn diese Option aktiviert ist, ermöglicht OCSP-Stapling, dass Edge als TLS-Server für One-Way-TLS den OCSP-Antworten direkt abfragen und dann die Antwort im Cache speichern kann. Edge gibt diese Antwort dann an den TLS-Client zurück oder heftet sie im Rahmen des TLS-Handshakes. Weitere Informationen finden Sie unter OCSP-Stapeln auf dem Server aktivieren.

TLS muss aktiviert sein, damit OCSP-Stapeln möglich ist. Setzen Sie den Wert auf on, um die Funktion zu aktivieren. Der Standardwert ist off.

Der öffentlich sichtbare DNS-Name des virtuellen Hosts auf dem Router, optional einschließlich der Portnummer. Die Kombination aus Hostalias-Name und Portnummer für den virtuellen Host muss für alle virtuellen Hosts in der Edge-Installation eindeutig sein. Das bedeutet, dass mehrere virtuelle Hosts dieselbe Portnummer verwenden können, wenn sie unterschiedliche Host-Aliasse haben.

Sie müssen einen DNS-Eintrag und einen CNAME-Eintrag erstellen, der mit dem Host-Alias übereinstimmt. Der Host-Alias muss mit dem String übereinstimmen, den der Client im Host-Header übergibt.

Die Portnummer in HostAlias ist optional. Wenn Sie den Port als Teil des Hostalias angeben, müssen Sie denselben Port mithilfe des Elements <Port> angeben. Sie können auch zwei HostAlias-Elemente angeben, eines mit und eines ohne Portnummer.

Sie können mehrere HostAlias-Definitionen in derselben Definition für einen virtuellen Host haben, die mehreren DNS-Einträgen für den virtuellen Host entsprechen, aber nicht mehreren Ports. Wenn Sie mehrere Ports benötigen, erstellen Sie mehrere Definitionen für virtuelle Hosts mit unterschiedlichen Ports.

Sie können den Platzhalter „*“ in den Hostalias aufnehmen. Das Platzhalterzeichen „*“ darf nur am Anfang des Hostalias (vor dem ersten „.“) stehen und darf nicht mit anderen Zeichen kombiniert werden. Beispiel: *.example.com Das TLS-Zertifikat für den virtuellen Host muss einen übereinstimmenden Platzhalter im CN-Namen des Zertifikats haben. Beispiel: *.example.com. Mit einem Platzhalter in einem virtuellen Host-Alias können API-Proxys Aufrufe an mehrere Subdomains wie alpha.example.com, beta.example.com oder live.example.com verarbeiten. Die Verwendung eines Platzhalter-Alias hilft Ihnen auch, weniger virtuelle Hosts pro Umgebung zu verwenden, um innerhalb der Produktlimits zu bleiben, da ein virtueller Host mit einem Platzhalter nur als ein virtueller Host zählt.

Für die Cloud: Wenn Sie einen vorhandenen virtuellen Host haben, der einen anderen Port als 443 verwendet, können Sie keinen Hostalias hinzufügen oder entfernen.

Private Cloud:Wenn Sie den Hostalias mithilfe der IP-Adressen Ihrer Router und nicht mit DNS-Einträgen festlegen, fügen Sie für jeden Router einen separaten Hostalias hinzu und geben Sie die IP-Adresse jedes Routers und den Port des virtuellen Hosts an.

Gibt die Netzwerkschnittstellen an, an die port gebunden werden soll. Wenn Sie dieses Element weglassen, wird der Port auf allen Schnittstellen gebunden.

So legen Sie beispielsweise fest, dass der Port nur an en0 gebunden werden soll:

<Interfaces>
  <Interface>en0</Interface>
</Interfaces>

Ermitteln Sie die auf Ihrem System verfügbaren Schnittstellen, indem Sie den Befehl „ifconfig -a“ ausführen.

Konfigurieren Sie, wie der Router für diesen virtuellen Host reagiert, wenn der Message Processor ausfällt.

Mit <RetryOption> können Sie mehrere Werte angeben. Gültige Werte sind:

Wenn Sie mehrere Werte angeben, kombiniert der Router sie mit einem logischen OR.

Beispiel:

<RetryOptions>
  <RetryOption>http_599</RetryOption>
  <RetryOption>error</RetryOption>
  <RetryOption>timeout</RetryOption>
  <RetryOption>invalid_header</RetryOption>
</RetryOptions>

Wenn Sie einen ELB im TCP-Passthrough-Modus verwenden, um Anfragen an die Edge-Router zu verarbeiten, behandelt der Router die IP-Adresse des ELB als Client-IP anstelle der tatsächlichen Client-IP. Wenn der Router die echte Client-IP benötigt, aktivieren Sie proxy_protocol auf dem ELB, damit die Client-IP im TCP-Paket übergeben wird. Auf dem Router müssen Sie auch <ListenOption> auf dem virtuellen Host auf proxy_protocol setzen. Da sich der ELB im TCP-Passthrough-Modus befindet, wird TLS in der Regel am Router beendet. Daher konfigurieren Sie den virtuellen Host in der Regel nur dann für die Verwendung von proxy_protocol, wenn Sie ihn auch für die Verwendung von TLS konfigurieren.

Der Standardwert für <ListenOption> ist ein leerer String.

Beispiel:

<ListenOptions>
  <ListenOption>proxy_protocol</ListenOption>
</ListenOptions>

Wenn Sie <ListenOption> später wieder deaktivieren möchten, aktualisieren Sie den virtuellen Host und lassen Sie das <ListenOptions>-Tag bei der Aktualisierung weg.

Aktiviert unidirektionale TLS/SSL. Sie müssen einen Schlüsselspeicher mit dem Zertifikat und dem privaten Schlüssel definiert haben.

Für die Cloud: Sie benötigen ein von einer vertrauenswürdigen Entität wie Symantec oder VeriSign signiertes Zertifikat. Sie können keine selbst signierten Zertifikate oder untergeordnete Zertifikate verwenden, die von einer selbst signierten Zertifizierungsstelle signiert wurden.

Für die Cloud: Wenn Ihr vorhandener virtueller Host für die Verwendung eines anderen Ports als 443 konfiguriert ist, können Sie die TLS-Einstellung nicht ändern. Das bedeutet, dass Sie die TLS-Einstellung nicht von „Aktiviert“ in „Deaktiviert“ oder von „Deaktiviert“ in „Aktiviert“ ändern können.

Der Name des Schlüsselspeichers in Edge.

Apigee empfiehlt, den Namen des Schlüsselspeichers über einen Verweis anzugeben, damit Sie ihn ändern können, ohne die Router neu starten zu müssen. Weitere Informationen finden Sie unter Optionen für die TLS-Konfiguration.

Der Name des Truststores in Edge, der das Zertifikat oder die Zertifikatskette enthält, die für die bidirektionale TLS-Authentifizierung verwendet wird. Erforderlich, wenn <ClientAuthEnabled> „true“ ist.

Apigee empfiehlt, den Namen des Truststores über einen Verweis anzugeben, damit Sie ihn ändern können, ohne die Router neu starten zu müssen. Weitere Informationen finden Sie unter Optionen für die TLS-Konfiguration.

Wenn „wahr“ festgelegt ist, werden TLS-Zertifikatsfehler ignoriert. Das entspricht der Option „-k“ für cURL.

Diese Option ist gültig, wenn Sie TLS für Zielserver und Zielendpunkte und für virtuelle Hosts mit bidirektionaler TLS konfigurieren.

Wird das Back-End-System zusammen mit einem Zielendpunkt/Zielserver verwendet, kann, wenn das Back-End-System SNI nutzt und ein Zertifikat mit einem Subjekt-DN (Subject Distinguished Name) zurückgibt, der nicht mit dem Hostnamen übereinstimmt, der Fehler nicht ignoriert werden und die Verbindung schlägt fehl.

Nur für Edge für Private Cloud-Version 4.15.07 und älter.

Hiermit werden die vom virtuellen Host unterstützten Verschlüsselungen angegeben. Wenn keine Chiffren angegeben sind, sind alle für die JVM verfügbaren Chiffren erlaubt.

Fügen Sie die folgenden Elemente hinzu, um die Chiffren einzuschränken:

<Ciphers>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
</Ciphers>

Nur für Edge für Private Cloud-Version 4.15.07 und älter.

Hiermit werden die vom virtuellen Host unterstützten Protokolle angegeben. Wenn keine Protokolle angegeben sind, sind alle für die JVM verfügbaren Protokolle zulässig.

Fügen Sie die folgenden Elemente hinzu, um die Protokolle einzuschränken:

<Protocols>
  <Protocol>TLSv1</Protocol>
  <Protocol>TLSv1.2</Protocol>
  <Protocol>SSLv2Hello</Protocol>
</Protocols>

Wenn Sie ein kostenpflichtiges Edge for Cloud-Konto haben und noch kein TLS-Zertifikat und -Schlüssel haben, können Sie einen virtuellen Host erstellen, der das Apigee-Zertifikat und den Schlüssel für den kostenlosen Testzeitraum verwendet. Das bedeutet, dass Sie den virtuellen Host erstellen können, ohne zuvor einen Schlüsselspeicher zu erstellen.

Das Apigee-Zertifikat für die kostenlose Testversion ist für die Domain *.apigee.net definiert. Daher muss auch die <HostAlias> des virtuellen Hosts das Format *.apigee.net haben.

Weitere Informationen finden Sie unter Virtuellen Host mit dem Apigee Freetrial-Zertifikat und dem entsprechenden Schlüssel definieren.

Ermöglicht die Erfassung von TLS-Verbindungsinformationen durch Edge. Diese Informationen stehen dann als Flussvariablen in einem API-Proxy zur Verfügung. Weitere Informationen finden Sie unter Auf TLS-Verbindungsinformationen in einem API-Proxy zugreifen.

Aktiviert die Erfassung von Clientzertifikatdetails, die von Edge in Zwei-Wege-TLS erfasst wurden. Diese Informationen sind dann als Ablaufvariablen in einem API-Proxy verfügbar. Weitere Informationen finden Sie unter Zugreifen auf TLS-Verbindungsinformationen in einem API-Proxy.

Legt die Zeitüberschreitung in Sekunden zwischen Message Processors und dem Router fest. Der Router trennt die Verbindung und gibt eine HTTP-504-Antwort zurück, wenn er vor Ablauf dieser Dauer keine Antwort vom Message Processor erhält.

Der Wert von proxy_read_timeout sollte größer sein als der Zielzeitüberschreitungswert, der vom Message Processor verwendet wird. So wird verhindert, dass der Router ein Zeitlimit erreicht, bevor der Message Processor Zeit hatte, eine Antwort zurückzugeben. Das Standardzielzeitlimit für den Message Processor beträgt 55 Sekunden, also 55.000 Millisekunden, wie im conf_http_HTTPTransport.io.timeout.millis-Token für den Message Processor definiert.

Legt die Zeitüberschreitung in Sekunden zwischen dem Client und dem Router fest, wenn der Client eine Anfrage mit dem Keep-Alive-Header sendet. Der Router hält die Verbindung offen, bis die Dauer abgelaufen ist.

Der Router schließt die Verbindung nicht, wenn er gerade auf eine Antwort vom Nachrichtenprozessor wartet. Die Zeitüberschreitung beginnt erst, nachdem der Router die Antwort an den Client zurückgegeben hat.

Legt die vom virtuellen Host unterstützten Chiffren fest und überschreibt die Standardchiffren, die auf dem Router festgelegt sind.

Geben Sie eine durch Doppelpunkte getrennte Liste von Chiffren im folgenden Format an:

<Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;</Property>

Informationen zur Syntax und zu den zulässigen Werten dieses Tokens finden Sie unter https://www.openssl.org/docs/man1.0.2/man1/ciphers.html. Hinweis: Für dieses Token werden die OpenSSL-Chiffrennamen wie AES128-SHA256 und nicht die Java/JSSE-Chiffrennamen wie TLS_RSA_WITH_AES_128_CBC_SHA256 verwendet.

!MD5:

!DH+3DES:

!kEDH

Nur für Edge for Private Cloud verfügbar.

Legt die vom virtuellen Host unterstützten TLS-Protokolle als durch Leerzeichen getrennte Liste fest, wobei die auf dem Router festgelegten Standardprotokolle überschrieben werden.

Hinweis: Wenn zwei virtuelle Hosts denselben Port verwenden, müssen sie ssl_protocols auf dieselben Protokolle festlegen. Das bedeutet, dass virtuelle Hosts, die denselben Port verwenden, genau dieselben Protokolle unterstützen müssen.

Geben Sie eine durch Leerzeichen getrennte Liste von TLS-Protokollen im folgenden Format an:

<Property name="ssl_protocols">TLSv1 TLSv1.2</Property>

Aktiviert (on) oder deaktiviert (off) das Puffern des Anfrage-Bodys. Wenn das Puffern aktiviert ist, puffert der Router den gesamten Anfragetext, bevor er ihn an den Message Processor sendet. Wenn ein Fehler auftritt, kann der Router es mit einem anderen Message Processor versuchen.

Wenn diese Option deaktiviert ist, wird die Pufferung deaktiviert und der Anfragetext wird sofort nach Erhalt an den Nachrichtenprozessor gesendet. Bei einem Fehler wiederholt der Router die Anfrage nicht an einen anderen Message Processor.