<ph type="x-smartling-placeholder"></ph>
Vous consultez la documentation Apigee Edge.
Accédez à la page
Documentation sur Apigee X. En savoir plus
Ce document explique comment créer, modifier et supprimer des keystores et des truststores pour Edge pour le cloud et Edge pour le Private Cloud à partir de la version 4.18.01.
À propos des keystores/truststores et les hôtes virtuels pour Edge Cloud
Le processus de création de keystores/Truststores pour Edge Cloud nécessite de suivre toutes les des règles sur l’utilisation d’hôtes virtuels. Par exemple, avec des hôtes virtuels dans le cloud:
- Les hôtes virtuels doivent utiliser le protocole TLS.
- Les hôtes virtuels ne peuvent utiliser que le port 443.
- Vous devez utiliser un certificat TLS signé. L'utilisation de certificats non signés avec des hôtes virtuels dans le cloud n'est pas autorisée.
- Le nom de domaine spécifié par le certificat TLS doit correspondre à l'alias de l'hôte virtuel.
En savoir plus:
- À propos de TLS/SSL
- Utiliser TLS avec Edge
- Questions fréquentes sur la configuration des hôtes virtuels
- À propos des hôtes virtuels
L'implémentation de keystores et de truststores Périphérie
Pour configurer une fonctionnalité qui repose sur une infrastructure à clé publique, telle que TLS, vous devez : créer des keystores et des « Truststores » qui contiennent les clés et les certificats numériques nécessaires.
Dans Edge, les keystores et les truststores sont tous deux représentés par une entité keystore. contenant un ou plusieurs alias. Autrement dit, il n'existe aucune différence d'implémentation entre un keystore et un Truststore sur Edge.
La différence entre keystores et truststore est dérivée des types d'entrées qu'ils et comment ils sont utilisés dans les handshakes TLS:
- keystore : entité keystore contenant un ou plusieurs aliases, où chaque alias contient une paire certificat/clé.
- truststore : entité keystore contenant un ou plusieurs aliases, où chaque alias ne contient qu'un certificat.
Lors de la configuration de TLS pour un hôte virtuel ou un point de terminaison cible, les keystores et les Truststores fournissent
différents rôles dans le processus
de handshake TLS. Lors de la configuration d'un hôte virtuel ou d'une cible
vous spécifiez les keystores et les truststores séparément dans le <SSLInfo>
, comme indiqué ci-dessous pour un hôte virtuel:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>apiTLS.myCompany.com</HostAlias> </HostAliases> <Interfaces/> <Port>9006</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>false</ClientAuthEnabled> <KeyStore>ref://keystoreref</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> </SSLInfo> </VirtualHost>
Dans cet exemple, vous spécifiez le nom du keystore et l'alias utilisés par l'hôte virtuel pour dans son keystore TLS. Vous utilisez une référence pour spécifier le nom du keystore afin de pouvoir le modifier plus tard, lorsque le certificat expire. L'alias contient une paire certificat/clé permettant d'identifier l'hôte virtuel à un client TLS accédant à l'hôte virtuel. Dans cet exemple, il n'y a pas de magasin de confiance obligatoire.
Si un Truststore est requis, par exemple pour une configuration TLS bidirectionnelle, utilisez
<TrustStore>
pour spécifier le truststore:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>apiTLS.myCompany.com</HostAlias> </HostAliases> <Interfaces/> <Port>9006</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>ref://keystoreref</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> <TrustStore>ref://truststoreref</TrustStore> </SSLInfo> </VirtualHost>
Dans cet exemple, la balise <TrustStore>
ne fait référence qu'à un keystore,
sans spécifier d'alias spécifique. Chaque alias du keystore contient un certificat, ou chaîne de certificats, qui
est utilisé dans le cadre du processus
de handshake TLS.
Formats de certificat compatibles
Format | Importation compatible avec l'API et l'interface utilisateur | Compatible avec la direction nord | Validé |
---|---|---|---|
PEM | Oui | Oui | Oui |
* PKCS12 | Oui | Oui | Oui Remarque: Apigee convertit en interne PKCS12 en PEM. |
* DER | Non | Non | Oui |
* PKCS7 | Non | Non | Non |
* Nous vous recommandons d'utiliser le format PEM si possible.
À propos de l'implémentation d'un alias
Sur Edge, un keystore contient un ou plusieurs alias, où chaque L'alias contient:
- Certificat TLS sous forme de fichier PEM ou PKCS12/PFX : certificat signé par un certificat autorité (CA), un fichier contenant une chaîne de certificats où le dernier certificat est signé par une autorité de certification ou un certificat autosigné.
- Clé privée sous forme de fichier PEM ou PKCS12/PFX. Edge prend en charge des tailles de clé jusqu'à 2 048 bits. A votre mot de passe multiterme est facultatif.
Sur Edge, un truststore contient un ou plusieurs alias, où Chaque alias contient:
- Certificat TLS sous forme de fichier PEM : certificat signé par une autorité de certification une chaîne de certificats dans laquelle le dernier certificat est signé par une autorité de certification, ou un certificat autosigné certificat.
Edge fournit une interface utilisateur et une API que vous utilisez pour créer des keystores, créer des alias, télécharger des certificats/clés paires et des certificats de mise à jour. L'UI et l'API que vous utilisez pour créer un truststore sont les mêmes que pour créer un keystore. La différence est que lorsque vous créez un Truststore, vous créez des alias qui ne contiennent qu'un certificat.
À propos du format du certificat et de la clé fichiers
Vous pouvez représenter les certificats et les clés sous forme de fichiers PEM ou de fichiers PKCS12/PFX. Les fichiers PEM sont conformes
le format X.509. Si votre certificat ou votre clé privée n'est pas défini par un fichier PEM, vous pouvez le convertir en
un fichier PEM à l'aide d'utilitaires tels que openssl
.
Toutefois, de nombreux fichiers .crt et .key sont déjà au format PEM. Si ces fichiers sont du texte fichiers et sont inclus dans:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
ou :
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
Les fichiers sont ensuite compatibles avec le format PEM et vous pouvez les utiliser dans un keystore ou truststore sans les convertir en fichier PEM.
À propos des chaînes de certificats
Si un certificat fait partie d'une chaîne, vous le gérez différemment selon qu'il est utilisé ou non dans une keystore ou dans un truststore:
- Keystore : si un certificat fait partie d'une chaîne, vous devez créer un seul fichier contenant tous les certificats de la chaîne. Les certificats doivent être en ordre et le dernier certificat doit être un certificat racine ou un certificat intermédiaire signé par un certificat racine.
- Truststore : si un certificat fait partie d'une chaîne, vous devez créer un seul fichier contenant tous les certificats, importez ce fichier dans un alias, ou importez tous les certificats de la chaîne séparément au Truststore en utilisant un alias différent pour chaque certificat. Si vous les importez en tant que certificat unique, les certificats doivent être en ordre et le dernier certificat doit être un certificat racine ou un un certificat intermédiaire signé par un certificat racine.
- Si vous créez un seul fichier contenant plusieurs certificats, vous devez insérer une ligne vide entre chaque certificat.
Par exemple, vous pouvez combiner tous les certificats en un seul fichier PEM. Les certificats doivent être le dernier certificat doit être un certificat racine ou un certificat intermédiaire signé par certificat:
-----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-----
Si vos certificats sont représentés par des fichiers PKCS12/PFX, vous pouvez utiliser openssl
pour créer un fichier PKCS12/PFX à partir d'une chaîne de certificats, comme indiqué ci-dessous:
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Lorsque vous travaillez avec des chaînes de certificats dans un truststore, il n'est pas toujours nécessaire d'importer toutes les
de la chaîne. Par exemple, vous importez un certificat client, client_cert_1
, et
le certificat de l'émetteur du certificat client, ca_cert
.
Lors de l’authentification TLS bidirectionnelle, l’authentification du client réussit lorsque le serveur envoie
client_cert_1
au client dans le cadre du processus de handshake TLS.
Vous pouvez également disposer d'un deuxième certificat, client_cert_2
, signé par le même certificat,
ca_cert
Toutefois, vous n'importez pas client_cert_2
dans le truststore.
Le truststore ne contient toujours que client_cert_1
et ca_cert
.
Lorsque le serveur transmet client_cert_2
dans le cadre du handshake TLS, la requête
réussit. En effet, Edge autorise la validation TLS à réussir lorsque client_cert_2
n'existe pas dans le truststore, mais a été signé par un certificat qui existe dans celui-ci. Si
vous supprimez le certificat CA, ca_cert
, du truststore, puis la validation TLS
est défaillant.
Explorer la page "Keystores TLS"
Accédez à la page des keystores TLS, comme décrit ci-dessous.Edge
Pour accéder à la page des keystores TLS à l'aide de l'interface utilisateur Edge:
- Connectez-vous à https://apigee.com/edge en tant qu'administrateur de l'organisation.
- Sélectionnez votre organisation.
- Sélectionnez Admin > Environnement > Keystores TLS.
Classic Edge (cloud privé)
Pour accéder à la page des keystores TLS à l'aide de l'interface utilisateur Classic Edge:
- Connectez-vous à
http://ms-ip:9000
en tant qu'administrateur de l'organisation, où ms-ip est l'adresse IP ou le nom DNS du nœud de serveur de gestion. - Sélectionnez votre organisation.
- Sélectionnez Admin > Configuration de l'environnement > Keystores TLS.
La page "Keystores TLS" s'affiche:
Comme le montre la figure précédente, la page des keystores TLS vous permet de:
- Sélectionnez un environnement
- Créer un keystore et un alias
- Tester et supprimer des keystores
- Afficher et supprimer les alias
Afficher un alias
Pour afficher un alias:
- Accédez à la page "Keystores TLS".
- Sélectionnez l'environnement (généralement
prod
outest
). - Cliquez sur la ligne associée à l'alias que vous souhaitez afficher.
Les détails du certificat et de la clé d'alias s'affichent.
Vous pouvez consulter toutes les informations sur l'alias, y compris sa date d'expiration. - Gérez le certificat à l'aide des boutons situés en haut de la page pour:
<ph type="x-smartling-placeholder">
- </ph>
- Téléchargez le certificat sous forme de fichier PEM.
- Générez une requête de signature de certificat. Si vous avez un certificat arrivé à expiration et que vous souhaitez le renouveler, vous pouvez télécharger un Demande de signature de certificat (CSR). Vous envoyez ensuite la requête de signature de certificat à votre autorité de certification pour obtenir un nouveau certificat.
- Mettre à jour un certificat Attention: Si vous mettez à jour un certificat
actuellement utilisé par un hôte virtuel ou un serveur/point de terminaison cible, vous devez
contactez l'assistance Apigee Edge pour redémarrer les routeurs et les processeurs de messages. La méthode recommandée pour mettre à jour
est le certificat suivant:
<ph type="x-smartling-placeholder">
- </ph>
- Créez un keystore ou un truststore.
- Ajoutez le nouveau certificat au nouveau keystore ou au nouveau truststore.
- Mettez à jour la référence dans l'hôte virtuel ou serveur/point de terminaison cible vers keystore ou truststore. Voir <ph type="x-smartling-placeholder"></ph> Mettre à jour un certificat TLS pour le cloud pour plus d'informations.
- Supprimez l'alias. Remarque: Si vous supprimez un alias et qu'il est actuellement utilisé par un hôte virtuel ou un point de terminaison cible, l'hôte virtuel ou le point de terminaison cible échouera.
Créer un keystore/un Truststore et un alias
Vous pouvez créer un keystore à utiliser comme keystore TLS ou Truststore TLS. Un keystore est spécifique à un environnement de votre organisation, par exemple l'environnement de test ou de production. Ainsi, si vous souhaitez tester le keystore dans un environnement de test avant de le déployer de production, vous devez la créer dans les deux environnements.
Pour créer un keystore dans un environnement, il vous suffit de spécifier son nom. Après avoir créer un keystore nommé dans un environnement, vous pouvez ensuite créer des alias et importer une paire certificat/clé (keystore) ou importez un certificat uniquement (truststore) sur l'alias.
Pour créer un keystore:
- Accédez à la page "Keystores TLS".
- Sélectionnez l'environnement (généralement
prod
outest
). - Cliquez sur + Keystore.
- Spécifiez le nom du keystore. Le nom ne peut contenir que des caractères alphanumériques.
- Cliquez sur Add Keystore (Ajouter un keystore). Le nouveau keystore apparaît dans la liste.
- Utilisez l'une des procédures suivantes pour ajouter un alias. Voir aussi
Formats de fichiers de certificat compatibles
- Créer un alias à partir d'un certificat (Truststore uniquement)
- Création d'un alias à partir d'un fichier JAR fichier (keystore uniquement)
- Créer un alias à partir d'un certificat et d'une clé (keystore uniquement)
- Créer un alias à partir de Un fichier PKCS12/PFX (keystore uniquement)
- La création d'un alias à partir d'un certificat autosigné (keystore uniquement)
Créer un alias à partir d'un certificat (Truststore) uniquement)
Pour créer un alias à partir d'un certificat:
- Accédez à la page "Keystores TLS".
- Placez le curseur sur le keystore pour afficher le menu d'actions, puis cliquez sur +.
- Spécifiez le nom d'alias.
- Sous "Détails du certificat", sélectionnez Certificat uniquement dans la liste déroulante "Type".
- Cliquez sur Choose File (Sélectionner un fichier) à côté de Certificate File (Fichier de certificat), puis accédez à fichier PEM contenant le certificat, puis cliquez sur Ouvrir.
- Par défaut, l'API vérifie que le certificat n'a pas expiré. (Facultatif) Sélectionnez Autoriser l'expiration du certificat pour ignorer la validation.
- Sélectionnez Enregistrer pour importer le certificat et créer l'alias.
Création d'un alias à partir d'un fichier JAR (keystore uniquement)
Pour créer un alias à partir d'un fichier JAR:
- Accédez à la page "Keystores TLS".
- Placez le curseur sur le keystore pour afficher le menu d'actions, puis cliquez sur +.
- Spécifiez le nom d'alias.
- Sous "Détails du certificat", sélectionnez Fichier JAR dans la liste déroulante "Type".
- Cliquez sur Choose File (Sélectionner un fichier) à côté de JAR File (Fichier JAR), accédez au fichier JAR contenant le certificat et la clé, puis cliquez sur Open (Ouvrir).
- Si la clé a un mot de passe, spécifiez le mot de passe. si aucun élément mot de passe, laissez ce champ vide.
- Par défaut, l'API vérifie que le certificat n'a pas expiré. (Facultatif) Sélectionnez Autoriser l'expiration du certificat pour ignorer la validation.
- Sélectionnez Enregistrer pour importer la clé et le certificat, puis créer l'alias.
Créer un alias à partir d'un certificat key (keystore uniquement)
Pour créer un alias à partir d'un certificat et d'une clé:
- Accédez à la page "Keystores TLS".
- Placez le curseur sur le keystore pour afficher le menu d'actions, puis cliquez sur +.
- Spécifiez le nom d'alias.
- Sous "Détails du certificat", sélectionnez Certificat et clé dans le menu déroulant "Type".
- À côté de Fichier de certificat, cliquez sur Sélectionner un fichier, accédez au fichier PEM contenant le certificat, puis cliquez sur Ouvrir.
- Si la clé possède un mot de passe, spécifiez le Mot de passe de la clé. si aucun élément mot de passe, laissez ce champ vide.
- Cliquez sur Choose File (Sélectionner un fichier) à côté de Key File (Fichier de clé), accédez au fichier PEM contenant la clé, puis cliquez sur Open (Ouvrir).
- Par défaut, l'API vérifie que le certificat n'a pas expiré. (Facultatif) Sélectionnez Autoriser l'expiration du certificat pour ignorer la validation.
- Sélectionnez Enregistrer pour importer la clé et le certificat, puis créer l'alias.
Créer un alias à partir d'un Fichier PKCS12/PFX (keystore uniquement)
Pour créer un alias à partir d'un fichier PKCS12 contenant le certificat et la clé:
- Accédez à la page "Keystores TLS".
- Placez le curseur sur le keystore pour afficher le menu d'actions, puis cliquez sur +.
- Spécifiez le nom d'alias.
- Sous "Détails du certificat", sélectionnez PKCS12/PFX dans la liste déroulante "Type".
- Cliquez sur Choose File (Sélectionner un fichier) à côté de PKCS12/PFX, puis accédez à contenant la clé et le certificat, puis cliquez sur Ouvrir.
- Si la clé possède un mot de passe, spécifiez le mot de passe pour le fichier PKCS12/PFX. Si la clé n'a pas de mot de passe, laissez ce champ vide.
- Par défaut, l'API vérifie que le certificat n'a pas expiré. (Facultatif) Sélectionnez Autoriser l'expiration du certificat pour ignorer la validation.
- Sélectionnez Enregistrer pour importer le fichier et créer l'alias.
Créer un alias à partir d'un certificat autosigné (keystore uniquement)
Pour créer un alias qui utilise un certificat autosigné, vous devez remplir un formulaire avec les informations requises pour créer le certificat. Edge crée ensuite le certificat et une paire de clés privées et les transfère vers l'alias.
Pour créer un alias à partir d'un certificat autosigné:
- Accédez à la page "Keystores TLS".
- Placez le curseur sur le keystore pour afficher le menu d'actions, puis cliquez sur +.
- Spécifiez le nom d'alias.
- Sous "Détails du certificat", sélectionnez Certificat autosigné dans la liste déroulante "Type".
- Remplissez le formulaire à l'aide du tableau ci-dessous.
- Sélectionnez Save (Enregistrer) pour créer la paire de certificat et de clé privée, et pour les importer dans l'alias.
Dans le certificat généré, les champs supplémentaires suivants s'affichent:
- Émetteur
Entité qui a signé et émis le certificat. Pour un certificat autosigné, il s'agit du CN que vous avez spécifié lors de la création du certificat. - Validité
la période de validité du certificat représentée sous la forme de deux dates: la date à laquelle le certificat la période de validité commence et la date de fin de la période de validité du certificat. Les deux peuvent être encodées en tant que valeurs UTCTime ou GeneralizedTime.
Le tableau suivant décrit les champs du formulaire:
Champ du formulaire | Description | Par défaut | Obligatoire |
---|---|---|---|
Nom de l'alias | Nom d'alias. Ne doit pas dépasser 128 caractères | N/A | Oui |
Taille de clé | Taille de la clé, en bits. La valeur par défaut et maximale est de 2 048 bits. | 2048 | Non |
Algorithme de signature | Algorithme de signature permettant de générer une clé privée. Les valeurs valides sont "SHA512withRSA", SHA384avecRSA et "SHA256withRSA". (par défaut). | SHA256avecRSA | Non |
Validité du certificat en jours | Durée de validité du certificat, en jours. Accepte les valeurs positives non nulles. | 365 | Non |
Nom courant |
Le nom commun (CN) de l'organisation permet d'identifier le ou les noms de domaine complets
associées au certificat. Il est généralement composé d'un hôte et d'un nom de domaine.
Par exemple, api.enterprise.apigee.com, www.apigee.com, etc. La longueur maximale est de 64 caractères.
Selon le type de certificat, le CN peut être un ou plusieurs noms d'hôte appartenant au même domaine (par exemple, example.com, www.example.com), d'un nom avec des caractères génériques (comme *.example.com) ou d'une liste de domaines. À ne pas faire inclure un protocole (http:// ou https://), un numéro de port ou un chemin d'accès à la ressource. Le certificat n'est valide que si le nom d'hôte de la demande correspond à au moins un des les noms courants de certificats. |
N/A | Oui |
Adresse e-mail. Ne doit pas dépasser 255 caractères | N/A | Non | |
Nom de l'unité organisationnelle | Nom de l'équipe de l'organisation. Ne doit pas dépasser 64 caractères | N/A | Non |
Nom de l'organisation | Nom de l'organisation. Ne doit pas dépasser 64 caractères | N/A | Non |
Localité | Nom de la ville. Ne doit pas dépasser 128 caractères | N/A | Non |
État/Province | Nom de l'État/de la province Ne doit pas dépasser 128 caractères | N/A | Non |
Pays | Code pays à deux lettres. Exemple : IN pour l'Inde, US pour les États-Unis. | N/A | Non |
Autres noms |
Liste des autres noms d'hôtes. Permet de lier des identités supplémentaires au sujet
du certificat. Les options définies incluent une adresse de messagerie électronique Internet, un serveur DNS
une adresse IP et un URI (Uniform Resource Identifier).
255 caractères au maximum pour chaque valeur. Vous pouvez séparer les noms par une virgule ou en appuyant sur sur la touche Entrée après chaque nom. |
N/A | Non |
Tester un keystore ou un truststore
Vous pouvez tester votre truststore et votre keystore dans l'interface utilisateur Edge pour vérifier qu'ils sont configurés correctement. L'interface utilisateur de test valide une requête TLS envoyée par Edge à un service de backend. Le service de backend peuvent être configurés pour prendre en charge le protocole TLS unidirectionnel ou bidirectionnel.
Pour tester le protocole TLS unidirectionnel:
- Accédez à la page "Keystores TLS".
- Sélectionnez l'environnement (généralement
prod
outest
). - Placez votre curseur sur le keystore TLS que vous souhaitez tester pour afficher le menu d'actions, puis cliquez sur Test. La boîte de dialogue suivante
La boîte de dialogue qui s'affiche indique le nom du truststore:
- Saisissez le nom d'hôte du service de backend.
- Saisissez le numéro de port TLS (généralement 443).
- Vous pouvez également spécifier des protocoles ou des algorithmes de chiffrement.
- Sélectionnez Tester.
Pour tester le protocole TLS bidirectionnel:
- Pour le truststore souhaité, sélectionnez le bouton Test (Tester).
- Dans la boîte de dialogue, sélectionnez Two Way (Deux voies) pour SSL Test Type (Type de test SSL).
La boîte de dialogue suivante s'affiche:
- Spécifiez le nom du keystore utilisé dans TLS bidirectionnel.
- Spécifiez le nom de l'alias dans le keystore contenant le certificat et la clé.
- Saisissez le nom d'hôte du service de backend.
- Saisissez le numéro de port TLS (généralement 443).
- Vous pouvez également spécifier des protocoles ou des algorithmes de chiffrement.
- Sélectionnez Tester.
Ajouter un certificat à un Truststore pour TLS bidirectionnel
Lors de l'utilisation de TLS bidirectionnel pour les connexions entrantes, c'est-à-dire une requête API dans Edge, le Truststore contient un certificat ou une chaîne d’AC pour chaque client autorisé à envoyer des requêtes à Edge.
Lors de la configuration initiale du magasin de confiance, vous pouvez ajouter tous les certificats pour les clients connus. Cependant, au fil du temps, vous pouvez ajouter des certificats supplémentaires au Truststore à mesure que vous ajoutez de nouveaux clients.
Pour ajouter de nouveaux certificats à un Truststore utilisé pour TLS bidirectionnel:
- Assurez-vous d'utiliser une référence au truststore de l'hôte virtuel.
- Importez un nouveau certificat dans le truststore comme décrit ci-dessus dans Créer un alias à partir d'un certificat (truststore uniquement).
Mettez à jour la référence du truststore pour lui attribuer la même valeur. Cette mise à jour oblige Edge à recharger le truststore et le nouveau certificat.
Pour en savoir plus, consultez Modifier une référence.
Supprimer un keystore/un Truststore ou un alias
Vous devez faire preuve de prudence lorsque vous supprimez un keystore/truststore ou un alias. Si vous supprimez un keystore, magasin de confiance ou alias utilisé par un hôte virtuel, un point de terminaison cible ou un serveur cible, tous Les appels d'API via l'hôte virtuel ou le point de terminaison cible/le serveur cible échoueront.
En règle générale, le processus à utiliser pour supprimer un keystore/Truststore ou un alias est le suivant:
- Créez un keystore/truststore ou un alias comme décrit ci-dessus.
- Pour les connexions entrantes, c'est-à-dire une requête API dans Edge, mettez à jour le configuration d'hôte virtuel pour référencer le nouveau keystore et l'alias de clé.
- Pour les connexions sortantes, c'est-à-dire d'Apigee vers un serveur backend:
<ph type="x-smartling-placeholder">
- </ph>
- Mettez à jour la configuration TargetEndpoint pour tous les proxys d'API ayant référencé l'ancienne version keystore et un alias de clé pour référencer le nouveau keystore et l'alias de clé. Si votre TargetEndpoint fait référence à un TargetServer, mettez à jour la définition TargetServer pour référencer le nouveau keystore et alias de clé.
- Si le keystore et le truststore sont référencés directement à partir de TargetEndpoint vous devez redéployer le proxy. Si le point de terminaison cible fait référence à cible, qui fait référence au keystore et vous n'avez pas besoin de redéployer le proxy.
- Vérifiez que vos proxys d'API fonctionnent correctement.
- Supprimez le keystore/le Truststore ou l'alias.
Supprimer un keystore
Vous pouvez supprimer un keystore ou un truststore en plaçant votre curseur sur le keystore ou le trustore dans la liste pour afficher les actions puis cliquez sur . Si vous supprimez un keystore ou un Truststore en cours utilisés par un hôte virtuel ou un point de terminaison cible/serveur cible, tous les appels d'API via l'hôte virtuel ou le point de terminaison ou le serveur cible échouent.
Attention: Vous ne devez pas supprimer un keystore avant d'avoir converti votre des hôtes virtuels et des points de terminaison cibles/serveurs cibles pour utiliser un nouveau keystore.
Supprimer un alias
Vous pouvez supprimer un alias en plaçant votre curseur sur l'alias dans la liste pour afficher les actions puis cliquez sur . Si vous supprimez un alias utilisé par un hôte virtuel ou le point de terminaison/le serveur cible, tous les appels d'API via l'hôte virtuel ou le point de terminaison/la cible cible le serveur échouera.
Attention: Ne supprimez pas d'alias tant que vous n'avez pas converti votre des hôtes et des points de terminaison/serveurs cibles pour utiliser un nouveau keystore et un nouveau alias.