Schlüsselspeicher und Truststores für die Private Cloud Version 4.17.09 und niedriger erstellen

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

In diesem Dokument wird beschrieben, wie Sie Schlüsselspeicher und Truststores für Edge erstellen, ändern und löschen. für die Private Cloud-Version 4.17.09 und niedriger.

Informationen zu Schlüsselspeichern und Truststores

Schlüsselspeicher und Truststores definieren Repositories mit Sicherheitszertifikaten, die für TLS verwendet werden Verschlüsselung. Der Hauptunterschied zwischen den beiden besteht darin, wo sie beim TLS-Handshake verwendet werden. Prozess:

  • Ein Schlüsselspeicher enthält ein TLS-Zertifikat und einen privaten Schlüssel zur Identifizierung des Entität während des TLS-Handshakes.

    Bei Einweg-TLS: Wenn ein Client eine Verbindung zum TLS-Endpunkt auf dem Server herstellt, wird der Schlüsselspeicher des Servers präsentiert dem Client das Zertifikat des Servers (öffentliches Zertifikat). Der Client überprüft dann, von einer Zertifizierungsstelle wie Symantec oder VeriSign erworben werden.

    Beim bidirektionalen TLS verwalten sowohl der Client als auch der Server einen Schlüsselspeicher mit einem eigenen Zertifikat und privaten Schlüssel für die gegenseitige Authentifizierung.
  • Ein Truststore enthält Zertifikate zur Überprüfung von Zertifikaten, die als ist Teil des TLS-Handshakes.

    Beim Einweg-TLS ist kein Truststore erforderlich, wenn das Zertifikat von einer gültigen Zertifizierungsstelle signiert ist. Wenn die ein Zertifikat, das von einem TLS-Client empfangen wird, von einer gültigen Zertifizierungsstelle signiert ist, sendet der Client eine Anfrage um das Zertifikat zu authentifizieren. Ein TLS-Client verwendet in der Regel einen Truststore zur Validierung vom TLS-Server empfangene selbstsignierte Zertifikate oder Zertifikate, die nicht von einem vertrauenswürdigen Zertifizierungsstelle. In diesem Szenario füllt der Client seinen Truststore mit Zertifikaten, Trusts. Wenn der Client dann ein Serverzertifikat empfängt, wird das eingehende Zertifikat anhand der Zertifikate im Truststore validiert werden.

    Ein TLS-Client stellt z. B. eine Verbindung zu einem TLS-Server her, bei dem der Server einen selbst signierten Zertifikat. Da es sich um ein selbst signiertes Zertifikat handelt, kann der Client es nicht mit einer Zertifizierungsstelle validieren. Stattdessen lädt der Client das selbst signierte Zertifikat des Servers vorab in seinen Truststore. Gehen Sie dann so vor: Wenn der Client versucht, eine Verbindung zum Server herzustellen, verwendet der Client seinen Truststore, Validiert das vom Server empfangene Zertifikat.

    Beim bidirektionalen TLS können sowohl der TLS-Client als auch der TLS-Server einen Truststore verwenden. Ein Truststore ist erforderlich, wenn bidirektionale TLS ausgeführt wird, wenn Edge als TLS-Server fungiert.

Die Zertifikate können von einer Zertifizierungsstelle ausgestellt oder vom den von Ihnen generierten privaten Schlüssel enthält. Wenn Sie Zugriff auf eine Zertifizierungsstelle haben, folgen Sie der Anleitung Ihres Zertifizierungsstelle zum Generieren von Schlüsseln und Ausstellen von Zertifikaten. Wenn Sie keinen Zugriff auf eine Zertifizierungsstelle haben, können Sie Generieren Sie ein selbst signiertes Zertifikat mit einem der vielen öffentlich verfügbaren kostenlosen Tools, z. B. openssl.

Die Implementierung eines Keystore und Truststore in Edge

In Edge enthält ein Schlüsselspeicher eine oder mehrere JAR-Dateien, wobei die JAR-Datei Folgendes enthält:

  • TLS-Zertifikat als PEM-Datei – entweder ein von einer Zertifizierungsstelle signiertes Zertifikat (CA), eine Zertifikatskette, bei der das letzte Zertifikat von einer Zertifizierungsstelle signiert ist, oder ein selbst signiertes Zertifikat.
  • Privater Schlüssel als PEM-Datei. Edge unterstützt Schlüsselgrößen von bis zu 2.048 Bit. Eine Passphrase ist optional.

Ein Truststore ähnelt einem Schlüsselspeicher, mit der Ausnahme, dass er nur Zertifikate als PEM-Datei enthält, aber keine private Schlüssel.

Wenn das Zertifikat Teil einer Kette ist, muss der Schlüsselspeicher/Truststore alle Zertifikate im als einzelne PEM-Dateien oder als einzelne Datei. Wenn Sie eine einzelne Datei verwenden, Die Reihenfolge der Zertifikate muss angegeben werden, wobei das erste Zertifikat in der Datei das für TLS verwendete Zertifikat ist, dem der Kette von Zertifikaten zum CA-Zertifikat. Sie müssen eine leere Zeile einfügen zwischen jedes Zertifikat in der Datei.

Edge bietet eine API, mit der Sie Schlüsselspeicher und Truststores erstellen können. Die tatsächlichen APIs sind die nicht identisch sind. Der Unterschied besteht darin, dass Sie beim Erstellen eines Schlüsselspeichers eine JAR-Datei übergeben, die den Zertifikat und den privaten Schlüssel. Wenn Sie einen Truststore erstellen, übergeben Sie nur das Zertifikat als PEM-Datei.

Das Format der Zertifikat- und Schlüsseldateien

Die Beispiele in diesem Dokument zeigen das TLS-Zertifikat und den TLS-Schlüssel, definiert als PEM-Dateien, die die mit dem X.509-Format. Wenn Ihr Zertifikat oder Ihr privater Schlüssel nicht in einer PEM-Datei definiert ist, können Sie mithilfe von Dienstprogrammen wie openssl in eine PEM-Datei umwandeln.

Viele CRT- und Schlüsseldateien liegen jedoch bereits im PEM-Format vor. Wenn es sich bei diesen Dateien um Textdateien handelt -Dateien und befinden sich in:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

oder

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

Dann sind die Dateien mit dem PEM-Format kompatibel und können in einem Schlüsselspeicher oder ohne sie in eine PEM-Datei zu konvertieren.

Wenn Sie eine Zertifikatskette haben und diese in einem Schlüsselspeicher oder Truststore verwenden möchten, können Sie alle Zertifikate in einer einzigen PEM-Datei zusammenfassen. Die Zertifikate müssen in der richtigen Reihenfolge und das letzte Zertifikat ein Stammzertifikat oder ein Zwischenzertifikat sein durch ein Root-Zertifikat signiert:

-----BEGIN CERTIFICATE-----
(Your Primary TLS certificate)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
(Root certificate or intermediate certificate signed by a root certificate)
-----END CERTIFICATE-----

Details zu einem vorhandenen Schlüsselspeicher abrufen

Überprüfen Sie Ihre Umgebung mithilfe der Methode Schlüsselspeicher auflisten und Truststores:

curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Cloud-Kunden steht ein Standard-Schlüsselspeicher für kostenlose Testorganisationen im Test- und Produktionsumgebungen. Für diesen Aufruf sollten Sie die folgenden Ergebnisse für beide Umgebungen:

[ "freetrial" ]

Sie können diesen Standard-Schlüsselspeicher verwenden, um Ihre APIs zu testen und in die Produktion zu übertragen. Erstellen Sie in der Regel einen eigenen Schlüsselspeicher mit einem eigenen Zertifikat und Schlüssel, bevor Sie die Bereitstellung in der Produktion vornehmen.

Für Private Cloud-Kunden ist das zurückgegebene Array leer, bis Sie das erste erstellt haben keystore.

Überprüfen Sie den Inhalt des Schlüsselspeichers mithilfe der Methode Rufen Sie eine Keystore oder Truststore API ab. Cloud-Kunden sollten ein TLS-Protokoll für einen einzelnen Server sehen. Zertifikat - das Standardzertifikat, das Apigee Edge für kostenlose Testkonten bereitstellt.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Die Antwort sollte wie folgt aussehen:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Sie können diese Informationen auch in der Edge-Verwaltungsbenutzeroberfläche anzeigen:

  1. Melden Sie sich bei der Edge-Verwaltungsbenutzeroberfläche unter https://enterprise.apigee.com (Cloud) oder http://<ms-ip>:9000 (lokal) an. Dabei ist <ms-ip> die IP-Adresse. Adresse des Verwaltungsserverknotens.
  2. Wählen Sie im Menü der Edge-Verwaltungsoberfläche Admin > TLS-Zertifikate.

Details zum TLS-Zertifikat abrufen

Sie können die Methode Rufen Sie Zertifikatdetails aus einem Schlüsselspeicher oder einer Truststore API ab, um Details zu TLS-Zertifikaten in Schlüsselspeicher, wie Ablaufdatum und Aussteller. Ermitteln Sie zuerst den Namen des Zertifikats in die Sie interessieren. Dieses Beispiel ruft Informationen für den Schlüsselspeicher namens „kostenloser Testzeitraum“.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Beispielantwort:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Verwenden Sie dann den Wert des Attributs „certs“, um die Zertifikatsdetails abzurufen:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password

Beispielantwort:

{
 "certInfo" : [ {
   "expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
   "isValid" : "Yes",
   "issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O=&quot;GoDaddy.com, Inc.&quot;, L=Scottsdale, ST=Arizona, C=US",
   "subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
   "subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
   "validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
   "version" : 3
 } ],
 "name" : "example.apigee.net.crt"
}

Sie können diese Informationen auch in der Edge-Verwaltungsbenutzeroberfläche anzeigen:

  1. Melden Sie sich bei der Edge-Verwaltungsbenutzeroberfläche unter https://enterprise.apigee.com (Cloud) an. oder http://<ms-ip>:9000 (lokal), Dabei ist <ms-ip> die IP-Adresse. Adresse des Verwaltungsserverknotens.
  2. Wählen Sie im Menü der Edge-Verwaltungsoberfläche Admin > TLS Zertifikate.

In der Edge-Benutzeroberfläche können Sie angeben, wie weit im Voraus Edge anzeigt, dass ein Zertifikat verfällt. Standardmäßig werden in der Benutzeroberfläche alle Zertifikate hervorgehoben, die in den nächsten 10 Tagen ablaufen. Tage.

Schlüsselspeicher erstellen

Ein Schlüsselspeicher ist für eine Umgebung in Ihrer Organisation spezifisch, z. B. „test“ oder „prod“. zu verbessern. Wenn Sie den Schlüsselspeicher also vor der Bereitstellung in einer Testumgebung testen möchten, müssen Sie sie in beiden Umgebungen erstellen.

Das Erstellen eines Schlüsselspeichers erfolgt in zwei Schritten:

  1. Erstellen Sie eine JAR-Datei, die Ihr Zertifikat und Ihren privaten Schlüssel enthält.
  2. Erstellen Sie den Schlüsselspeicher und laden Sie die JAR-Datei hoch.

JAR-Datei erstellen mit Ihrem Zertifikat und Ihrem privaten Schlüssel

Erstellen Sie eine JAR-Datei mit Ihrem privaten Schlüssel, Zertifikat und einem Manifest. Die JAR-Datei muss die folgenden Dateien und Verzeichnisse enthalten:

/META-INF/descriptor.properties
myCert.pem
myKey.pem
<ph type="x-smartling-placeholder">

Erstellen Sie in dem Verzeichnis, das Ihr Schlüsselpaar und Ihr Zertifikat enthält, ein Verzeichnis namens /META-INF Erstellen Sie dann eine Datei namens descriptor.properties in /META-INF durch Folgendes Inhalt:

certFile={myCertificate}.pem
keyFile={myKey}.pem

Generieren Sie die JAR-Datei, die Ihr Schlüsselpaar und Ihr Zertifikat enthält:

jar -cf myKeystore.jar myCert.pem myKey.pem

Fügen Sie descriptor.properties zu Ihrer JAR-Datei hinzu:

jar -uf myKeystore.jar META-INF/descriptor.properties

Erstellen Sie den Schlüsselspeicher und laden Sie den JAR-Datei

Zum Erstellen eines Schlüsselspeichers in einer Umgebung müssen Sie nur den Schlüsselspeichernamen im Erstellen eine Keystore oder Truststore API. Der Name darf nur alphanumerische Zeichen enthalten:

curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password

Beispielantwort:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystore"
}

Nachdem Sie einen benannten Schlüsselspeicher in einer Umgebung erstellt haben, können Sie Ihre JAR-Dateien hochladen, die enthalten ein Zertifikat und einen privaten Schlüssel mithilfe der Laden Sie eine JAR-Datei in eine Keystore API hoch:

curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password

Dabei gibt die Option -F Pfad zur JAR-Datei.

In diesem Aufruf geben Sie zwei Abfrageparameter an:

  • alias – Identifiziert das Zertifikat und Schlüssel im Schlüsselspeicher. Wenn Sie einen virtuellen Host erstellen, verweisen Sie auf den und Schlüssel nach seinem Aliasnamen.
  • password – das Passwort für den privaten Schlüssel. Lassen Sie diesen Parameter weg, wenn der private Schlüssel kein Passwort hat.

Prüfen Sie, ob Ihr Schlüsselspeicher ordnungsgemäß hochgeladen wurde:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password

Beispielantwort:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

Truststore erstellen

Die APIs, die Sie zum Erstellen eines Truststores verwenden, sind die gleichen wie zum Erstellen eines Schlüsselspeichers. Die Der einzige Unterschied besteht darin, dass Sie die Zertifikatsdatei als PEM-Datei und nicht als JAR-Datei übergeben.

Wenn das Zertifikat zu einer Kette gehört, müssen Sie entweder alle Zertifikate in der Kette separat hochladen an den Truststore senden oder eine einzelne Datei mit allen Zertifikaten erstellen, fügen Sie eine neue Zeile zwischen jedes Zertifikat in der Datei. Das endgültige Zertifikat wird normalerweise vom Zertifikatsaussteller signiert. Für Beispiel: Sie laden im Truststore das Clientzertifikat client_cert_1 und das Clientzertifikat hoch Zertifikat des Ausstellers, ca_cert.

Bei der bidirektionalen TLS-Authentifizierung ist die Clientauthentifizierung erfolgreich, wenn der Server client_cert_1 an den Kunden als Teil des TLS-Handshakes.

Alternativ haben Sie ein zweites Zertifikat, client_cert_2, das mit demselben Zertifikat signiert wurde. ca_cert. Sie müssen jedoch client_cert_2 hochladen in: Truststore. Der Truststore enthält weiterhin client_cert_1 und ca_cert.

Wenn der Server client_cert_2 im Rahmen des TLS-Handshakes übergibt, wird der -Anforderung erfolgreich war. Das liegt daran, dass Edge die TLS-Bestätigung erfolgreich zulässt, wenn client_cert_2 nicht im Truststore, wurde jedoch von einem Zertifikat signiert, das im Truststore vorhanden ist. Wenn Sie die Zertifizierungsstelle entfernen Zertifikat, ca_cert, aus dem schlägt die TLS-Bestätigung fehl.

Erstellen Sie in der Umgebung einen leeren Truststore. Verwenden Sie dazu Create a Keystore oder Truststore, dieselbe API, mit der Sie einen Schlüsselspeicher erstellen:

curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Laden Sie das Zertifikat mit der Methode als PEM-Datei in den Truststore hoch. Laden Sie ein Zertifikat in eine Truststore API hoch:

curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password

Dabei gibt die Option -F Pfad zur PEM-Datei.

Schlüsselspeicher oder Truststore löschen

Sie können einen Schlüsselspeicher oder Truststore löschen, indem Sie den Löschen Sie eine Schlüsselspeicher- oder Truststore-API:

curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password

Beispielantwort:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystoreName"
}

Wenn Sie einen Schlüsselspeicher oder Truststore löschen, der von einem virtuellen Host oder Ziel verwendet wird Endpunkt/Ziel/Server, alle API-Aufrufe über den virtuellen Host oder Zielendpunkt/Zielserver schlägt fehl...