Diese Seite wurde von der Cloud Translation API übersetzt.

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

Sie sehen sich die Dokumentation zu Apigee Edge an.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

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

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, mit denen die Entität während des TLS-Handshakes identifiziert wird.

Bei einer Einweg-TLS-Verbindung stellt der Schlüsselspeicher des Servers dem Client das Zertifikat des Servers (öffentliches Zertifikat) zur Verfügung, wenn ein Client eine Verbindung zum TLS-Endpunkt des Servers herstellt. 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, mit denen Zertifikate überprüft werden, die im Rahmen des TLS-Handshakes empfangen wurden.

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, um selbst signierte Zertifikate zu validieren, die vom TLS-Server empfangen wurden, oder Zertifikate, die nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurden. 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 in seinen Truststore vor. 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-Verbindungen verwendet werden und Edge als TLS-Server fungiert.

Zertifikate können von einer Zertifizierungsstelle ausgestellt oder selbst signiert werden, indem Sie den privaten Schlüssel generieren. Wenn Sie Zugriff auf eine Zertifizierungsstelle haben, folgen Sie der Anleitung der Zertifizierungsstelle zum Generieren von Schlüsseln und Ausstellen von Zertifikaten. Wenn Sie keinen Zugriff auf eine Zertifizierungsstelle haben, können Sie Sie können ein selbst signiertes Zertifikat mit einem der vielen öffentlich verfügbaren kostenlosen Tools erstellen, z. B. openssl.

Die Implementierung eines Keystore und Truststore in Edge

In Edge enthält ein Keystore eine oder mehrere JAR-Dateien, die Folgendes enthalten:

TLS-Zertifikat als PEM-Datei – entweder ein von einer Zertifizierungsstelle signiertes Zertifikat, eine Zertifikatskette, deren letztes Zertifikat von einer Zertifizierungsstelle signiert ist, oder ein selbst signiertes Zertifikat.
Privater Schlüssel als PEM-Datei. Edge unterstützt Schlüsselgrößen bis zu 2.048 Bit. Eine Passphrase ist optional.

Ein Truststore ähnelt einem Schlüsselspeicher, enthält aber nur Zertifikate als PEM-Datei, keine privaten Schlüssel.

Wenn das Zertifikat Teil einer Kette ist, muss der Schlüsselspeicher/Truststore alle Zertifikate in der Kette enthalten, entweder als einzelne PEM-Dateien oder als einzelne Datei. Wenn Sie eine einzelne Datei verwenden, müssen die Zertifikate in der richtigen Reihenfolge sein. Das erste Zertifikat in der Datei ist das für TLS verwendete Zertifikat, gefolgt von der Zertifikatskette bis zum CA-Zertifikat. Zwischen den einzelnen Zertifikaten in der Datei muss eine leere Zeile eingefügt werden.

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

Informationen zum 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 .key-Dateien liegen jedoch bereits im PEM-Format vor. Wenn diese Dateien Textdateien sind und in Folgendes eingebettet sind:

-----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

Prüfen Sie mit der List Keystores and Truststores API, ob in Ihrer Umgebung bereits Schlüsselspeicher vorhanden sind:

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 in beiden Umgebungen die folgenden Ergebnisse sehen:

[ "freetrial" ]

Sie können diesen Standard-Keystore verwenden, um Ihre APIs zu testen und in die Produktion zu verschieben. Normalerweise erstellen Sie jedoch vor dem Produktionsbereitstellen einen eigenen Keystore mit Ihrem eigenen Zertifikat und Schlüssel.

Bei Kunden mit Private Cloud ist das zurückgegebene Array leer, bis Sie Ihren ersten Schlüsselspeicher erstellen.

Prüfen Sie den Inhalt des Keystores mit der API „Get a Keystore or Truststore“. 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 so aussehen:

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

Sie können diese Informationen auch in der Edge-Verwaltungsoberfläche aufrufen:

Melden Sie sich unter https://enterprise.apigee.com (Cloud) oder http://<ms-ip>:9000 (On-Premises) an der Edge-Verwaltungsoberfläche an. Dabei ist <ms-ip> die IP-Adresse des Management Server-Knotens.
Wählen Sie im Menü der Edge-Verwaltungsoberfläche Verwaltung > TLS-Zertifikate aus.

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 der Property „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-Verwaltungsoberfläche aufrufen:

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

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

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:

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

JAR-Datei mit Zertifikat und privatem Schlüssel erstellen

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

/META-INF/descriptor.properties
myCert.pem
myKey.pem

Erstellen Sie im Verzeichnis mit Ihrem Schlüsselpaar und Zertifikat ein Verzeichnis mit dem Namen /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 mit Ihrem Schlüsselpaar und Zertifikat:

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

Fügen Sie der JAR-Datei descriptor.properties 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, die ein Zertifikat und einen privaten Schlüssel enthalten, mit der API JAR-Datei in einen Schlüsselspeicher hochladen hochladen:

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 den Pfad zur JAR-Datei an.

In diesem Aufruf geben Sie zwei Abfrageparameter an:

alias – Identifiziert das Zertifikat und den 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 der Schlüsselspeicher richtig 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 dieselben 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 Teil einer Kette ist, müssen Sie entweder alle Zertifikate in der Kette separat in den Truststore hochladen oder eine einzelne Datei mit allen Zertifikaten erstellen. Fügen Sie zwischen den einzelnen Zertifikaten in der Datei eine neue Zeile ein. Das endgültige Zertifikat wird in der Regel vom Aussteller des Zertifikats signiert. Für Beispiel: Sie laden im Truststore das Clientzertifikat client_cert_1 und das Clientzertifikat hoch Das Zertifikat des Ausstellers, ca_cert.

Bei der TLS-Zwei-Wege-Authentifizierung ist die Clientauthentifizierung erfolgreich, wenn der Server im Rahmen des TLS-Handshake-Prozesses client_cert_1 an den Client sendet.

Alternativ haben Sie ein zweites Zertifikat, client_cert_2, das mit demselben Zertifikat signiert wurde. ca_cert. Sie laden client_cert_2 jedoch nicht in den Truststore hoch. 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 das CA-Zertifikat ca_cert aus dem Truststore entfernen, schlägt die TLS-Überprüfung fehl.

Erstellen Sie einen leeren Truststore in der Umgebung. Verwenden Sie dazu Erstellen 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 den Pfad zur PEM-Datei an.

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 Zielendpunkt/Ziel/Server verwendet wird, schlagen alle API-Aufrufe über den virtuellen Host oder Zielendpunkt/Zielserver fehl.