Optionen für die TLS-Konfiguration

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen.

In diesem Abschnitt wird gezeigt, wie Sie TLS für Traffic von einem Proxy zu einem Ziel konfigurieren.

Informationen zum Festlegen von TLS-Optionen in einem Zielendpunkt oder Zielserver

Ein Ziel kann durch ein XML-Objekt wie das folgende dargestellt werden:

<HTTPTargetConnection>
    <Properties/>
    <URL>https:myTargetAddress</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <Enforce>true</Enforce>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <Protocols>myProtocols</Protocols>
        <Ciphers>myCipher</Ciphers>
    </SSLInfo>
</HTTPTargetConnection>

Der Bereich der Zielendpunktkonfiguration, die Sie ändern, um TLS zu konfigurieren, wird durch das Tag <SSLInfo> definiert. Verwenden Sie dasselbe <SSLInfo>-Tag, um einen Zielendpunkt oder einen Zielserver zu konfigurieren.

Informationen zu den untergeordneten Elementen von <SSLInfo> finden Sie unter TLS/SSL-TargetEndpoint-Konfiguration.

In der folgenden Tabelle werden die TLS-Konfigurationselemente beschrieben, die vom Tag <SSLInfo> verwendet werden:

Element Beschreibung
<Enabled> Der <SSLInfo>-Block kann sowohl für uni- als auch für bidirektionale TLS/SSL verwendet werden.

Wenn true festgelegt ist, gibt <Enabled> an, dass der Block <SSLInfo> verwendet werden soll. Wenn false festgelegt ist, wird der Block <SSLInfo> ignoriert.

Der Standardwert von <Enabled> ist true, wenn <URL> das HTTPS-Protokoll angibt, und falsewenn <URL> HTTP festlegt.
<Enforce>

Erzwingt strenges SSL zwischen Apigee und dem Ziel-Backend.

Wenn dieser Wert auf true gesetzt ist, schlagen Verbindungen bei Zielen mit ungültigen Zertifikaten, abgelaufenen Zertifikaten, selbst signierten Zertifikaten, Zertifikaten mit nicht übereinstimmenden Hostnamen sowie Zertifikaten mit einer nicht vertrauenswürdigen Stammzertifizierungsstelle fehl. Der Fehlercode 4xx oder 5xx wird zurückgegeben.

Wenn kein Wert festgelegt oder auf false festgelegt ist, hängt das Ergebnis von Verbindungen zu Ziel-Back-Ends mit problematischen Zertifikaten von der Einstellung von <IgnoreValidationErrors> ab (siehe unten). Eine Erfolgsantwort (2xx) kann unter bestimmten Bedingungen auftreten, wenn <IgnoreValidationErrors> auf true gesetzt ist.
<ClientAuthEnabled>

Aktiviert die Zwei-Wege-TLS (auch gegenseitige TLS oder mTLS genannt) zwischen Apigee und dem API-Client oder zwischen Apigee und dem Ziel-Backend.

Für die Aktivierung der bidirektionalen TLS müssen Sie normalerweise einen Truststore auf Apigee und einen Truststore einrichten.
<KeyStore> Einen Schlüsselspeicher, der private Schlüssel für die ausgehende Clientauthentifizierung verwendet
<KeyAlias> Der Alias, der beim Hochladen eines Zertifikats und eines privaten Schlüssels in den Schlüsselspeicher angegeben wurde.
<TrustStore> Einen Schlüsselspeicher mit vertrauenswürdigen Serverzertifikaten.
<IgnoreValidationErrors>

Gibt an, ob Validierungsfehler ignoriert werden. Wenn das Backend-System SNI nutzt und ein Zertifikat mit einem Subjekt-DN (Subject Distinguished Name) zurückgibt, der nicht mit dem Hostnamen übereinstimmt, kann der Fehler nicht ignoriert werden und die Verbindung schlägt fehl.

Hinweis: Wenn <Enforce> auf true gesetzt ist, wird der Wert von <IgnoreValidationErrors> ignoriert.
<Ciphers>

Unterstützte Chiffren für ausgehende TLS/SSL. 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_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
<Protocols>

Unterstützte Protokolle für ausgehendes TLS/SSL. Wenn keine Protokolle angegeben sind, sind alle für die JVM verfügbaren Protokolle zulässig.

Wenn Sie Protokolle einschränken möchten, geben Sie sie explizit an. So lassen Sie beispielsweise nur TLS v1.2 oder TLS v1.3 zu:

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

Informationen zum Festlegen der Elemente <KeyStore> und <TrustStore>

Im obigen Beispiel werden der Schlüsselspeicher und Truststore durch Verweise im folgenden Form angegeben:

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

In diesem Fall gilt Folgendes:

  • myKeystoreRef ist eine Referenz, die den Namen des Schlüsselspeichers enthält. In diesem Beispiel lautet der Name des Schlüsselspeichers myKeystore.
  • myTruststoreRef ist eine Referenz, die den Namen des Truststore enthält. In diesem Beispiel lautet der Name des Truststore myTruststore.

Läuft ein Zertifikat ab, müssen Sie den Zielendpunkt/Zielserver aktualisieren, um den Schlüsselspeicher oder Truststore mit dem neuen Zertifikat anzugeben. Wenn Sie jedoch Verweise verwenden, können Sie den Wert der Verweise ändern, um die neuen Namen des Schlüsselspeichers oder Truststore widerzuspiegeln, anstatt den Zielendpunkt/Zielserver zu ändern. Sie müssen sich nicht an Google Cloud Customer Care wenden, um den Wert des Verweises zu ändern.

Alternativ können Sie den Schlüsselspeicher- und den Truststore-Namen direkt angeben:

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore>

Wenn Sie den Namen des Schlüsselspeichers oder Truststore direkt angeben, müssen Sie sich an den Google Cloud-Support wenden.

Als dritte Option ist die Verwendung von Ablaufvariablen vorgesehen:

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore>

Sie können Ablaufvariablen verwenden, um einen Schlüsselspeicher oder Truststore dynamisch anzugeben. Dies hat einen ähnlichen Effekt wie die Verwendung eines Verweises. Weitere Informationen finden Sie unter Ablaufvariablen zur dynamischen Festlegung von TLS/SSL-Werten verwenden.

Informationen zur TLS-Konfiguration

Alle Apigee-Kunden, sowohl zahlende als auch solche in der Probephase, haben die vollständige Kontrolle über die Konfiguration der Zielendpunkte/Zielserver. Darüber hinaus haben zahlende Apigee-Kunden die vollständige Kontrolle über TLS-Attribute.

Umgang mit abgelaufenen Zertifikaten

Wenn ein TLS-Zertifikat abläuft oder Ihre Systemkonfiguration so geändert wird, dass das Zertifikat nicht mehr gültig ist, muss das Zertifikat aktualisiert werden. Wenn Sie TLS für einen Zielendpunkt/Zielserver konfigurieren, sollten Sie vor der Konfiguration entscheiden, wie Sie dieses Update durchführen.

Vorgehensweise bei abgelaufenem Zertifikat

In Edge werden Zertifikate an einem von zwei Orten gespeichert:

  • Schlüsselspeicher: Enthält das TLS-Zertifikat und den privaten Schlüssel, um die Entität während des TLS-Handshakes zu identifizieren.
  • Truststore: Enthält vertrauenswürdige Zertifikate auf einem TLS-Client, mit denen das dem Client dargestellte Zertifikat eines TLS-Servers validiert wird. Diese Zertifikate sind normalerweise selbst signierte Zertifikate, von einer vertrauenswürdigen Zertifizierungsstelle signierte Zertifikate oder Zertifikate, die im Rahmen von bidirektionaler TLS-Authentifizierung (auch gegenseitige TLS oder mTLS genannt) verwendet werden.

Die Methode, mit der Sie den Schlüsselspeicher und Truststore im Zielendpunkt oder Zielserver angeben, bestimmt, wie Sie das Zertifikat aktualisieren. Sie können Verweise, direkte Namen oder Ablaufvariablen verwenden. Jede Methode hat unterschiedliche Auswirkungen auf den Aktualisierungsprozess, wie in der folgenden Tabelle beschrieben:

Konfigurationstyp Zertifikat aktualisieren/ersetzen Verwendung / Auswirkungen
Referenz (empfohlen)

Schlüsselspeicher: Erstellen Sie einen neuen Schlüsselspeicher mit einem neuen Namen und einem Alias mit demselben Namen wie dem des alten Alias.

Truststore:Erstellen Sie einen Truststore mit einem neuen Namen. Der Aliasname spielt dabei keine Rolle.

 Aktualisieren Sie den Verweis, um auf den neuen Speicher zu verweisen.

Sie müssen den Apigee-Support nicht kontaktieren. Keine Ausfallzeiten.
Ablaufvariable

Schlüsselspeicher:Erstellen Sie einen neuen Schlüsselspeicher mit einem neuen Namen und einem Alias mit demselben oder einem neuen Namen.

Truststore:Erstellen Sie einen Truststore mit einem neuen Namen.

 Übergeben Sie die aktualisierte Ablaufvariable bei jeder Anfrage mit dem Namen des neuen Speichers.

Sie müssen den Apigee-Support nicht kontaktieren. Keine Ausfallzeiten.
Direkt

Methode 1: Neuen Speicher erstellen (empfohlen, um Ausfallzeiten zu vermeiden)

Erstellen Sie einen neuen Schlüsselspeicher oder Truststore mit einem neuen Namen und laden Sie das neue Zertifikat hoch (und den privaten Schlüssel, wenn Sie einen Schlüsselspeicher erstellen).

 Aktualisieren Sie die Konfiguration des Zielendpunkts oder Zielservers, um den neuen Speichernamen direkt anzugeben, und stellen Sie den API-Proxy noch einmal bereit.

Sie müssen den Apigee-Support nicht kontaktieren.
Direkt

Methode 2a: In-Place-Update (Löschen und neu erstellen)

Löschen Sie den Schlüsselspeicher oder Truststore und erstellen Sie ihn noch einmal mit demselben Namen.

API-Anfragen schlagen während des Lösch- und Neuerstellungszeitraums fehl.

Da Message Processors direkt angegebene Speicher im Cache speichern, erkennen sie das aktualisierte Zertifikat nicht automatisch. Sie müssen sich an den Google Cloud Customer Care wenden, um die Message Processors neu zu starten.
Direkt

Methode 2b: In-Place-Update (Truststore-Upload)

Laden Sie nur für Truststores ein neues Zertifikat direkt in den vorhandenen Truststore hoch.

Da Message Processors direkt angegebene Speicher im Cache speichern, erkennen sie das neue Zertifikat nicht automatisch. Sie müssen sich an den Google Cloud Customer Care wenden, um die Message Processors neu zu starten.