Mettre à jour un certificat TLS pour le cloud privé

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X.
En savoir plus

La méthode que vous utilisez pour spécifier le nom du keystore et du truststore dans l'hôte virtuel ou le point de terminaison/serveur cible détermine la manière dont vous effectuez la mise à jour du certificat. Vous pouvez spécifier nom du keystore et du truststore à l'aide de la commande suivante:

  • Références (de préférence)
  • Noms directs
  • Variables de flux

Chacune de ces méthodes a des répercussions différentes sur le processus de mise à jour des certificats, comme décrit dans dans le tableau suivant.

Type de configuration Mettre à jour/remplacer un certificat Mettre à jour l'hôte virtuel, le point de terminaison cible/le serveur cible
Référence (recommandée) Pour un keystore, créez un nouveau keystore avec un nouveau nom et un alias avec le même nom que l'ancien alias.

Pour un truststore, créez un truststore avec un nouveau nom.

Mettez à jour la référence dans le keystore ou le truststore.

Aucun redémarrage du routeur ou du processeur de messages n'est nécessaire.

Variables de flux (point de terminaison cible uniquement) Pour un keystore, créez un nouveau keystore avec un nouveau nom et un alias avec le même nom ou un nouveau nom.

Pour un truststore, créez un truststore avec un nouveau nom.

Transmettez la variable de flux mise à jour sur chaque requête avec le nom du nouveau keystore, alias ou truststore.

Aucun redémarrage du routeur ou du processeur de messages n'est nécessaire.

Direct Créez un nouveau keystore, un alias et un truststore. Mettez à jour l'hôte virtuel et redémarrez les routeurs.

Si le truststore est utilisé par un point de terminaison cible/serveur cible, redéployez le proxy.

Accès direct Supprimez le keystore ou le truststore et recréez-le avec le même nom. Aucune mise à jour de l'hôte virtuel n'est requise, aucun redémarrage du routeur n'est nécessaire. Toutefois, les requêtes API échouent jusqu'à ce que le nouveau keystore et l'alias soient définis.

Si le keystore est utilisé pour le protocole TLS bidirectionnel entre Edge et le service de backend, redémarrez les processeurs de messages.

Direct Pour le truststore uniquement, importez un nouveau certificat dans le truststore. Si le truststore est utilisé par un hôte virtuel, redémarrez les routeurs.

Si le truststore est utilisé par un point de terminaison cible/serveur cible, redémarrez les processeurs de message.

Tester le certificat avant et après le mettre à jour

Exécutez les commandes openssl suivantes pour tester le certificat actuel avant de le mettre à jour comme suit:

echo | openssl s_client -servername hostAlias -connect hostAlias.apigee.net:443 2>/dev/null | openssl x509 -noout -dates -subject

hostAlias est l'alias de l'hôte virtuel ou de l'adresse IP. Exemple :

echo | openssl s_client -servername api.myCompany.com -connect api.myCompany.com:443 2>/dev/null | openssl x509 -noout -dates -subject

Le résultat doit s'afficher au format suivant :

notBefore=Dec 30 22:11:38 2015 GMT
notAfter=Dec 30 22:11:38 2016 GMT
subject= /OU=Domain Control Validated/CN=*.apigee.net

Exécutez la même commande après avoir mis à jour le certificat pour le tester.

Mettre à jour un certificat TLS dans un keystore

Pour un déploiement Edge sur site:

  1. Créez un keystore et importez un certificat et une clé comme décrit à l'adresse Keystores et Truststores. Dans le nouveau keystore, assurez-vous d'utiliser le même nom pour l'alias de clé que celui utilisé dans keystore existant.

    Remarque: Vous pouvez supprimer le keystore actuel et en créer un autre avec le même son nom et son alias. Aucun redémarrage du routeur n'est nécessaire. Toutefois, les requêtes API échouent jusqu'à ce que le nouveau keystore et l'alias sont définis.
  2. Pour un hôte virtuel utilisé par des connexions entrantes, c'est-à-dire une requête API dans Edge: <ph type="x-smartling-placeholder">
      </ph>
    1. Si votre hôte virtuel utilise une référence au keystore, mettez à jour la référence comme décrites dans la section Fonctionnement avec des références.
    2. Si votre hôte virtuel utilise un nom direct pour le keystore: <ph type="x-smartling-placeholder">
        </ph>
      1. Mettez à jour tous les hôtes virtuels faisant référence à l'ancien keystore et à l'ancien alias de clé pour référencer le nouveau keystore et l'alias de clé.
      2. Redémarrez les routeurs un par un. Notez que si vous avez supprimé l'ancien keystore créé un keystore portant le même nom, aucun redémarrage du routeur n'est nécessaire.

        Aucun redéploiement du proxy n'est requis.
  3. Pour un point de terminaison ou un serveur cible utilisés par des connexions sortantes, ce qui signifie d'Apigee vers un serveur backend: <ph type="x-smartling-placeholder">
      </ph>
    1. Si le point de terminaison ou le serveur cible utilise des références au keystore, mettez à jour le comme décrit dans la section Utiliser des références. Aucun redéploiement de proxy n'est nécessaire.
    2. Si le point de terminaison ou le serveur cible utilisent une variable de flux, mettez-la à jour. Non un redéploiement du proxy est nécessaire.
    3. Si le point de terminaison ou le serveur cible utilisent un nom direct du keystore: <ph type="x-smartling-placeholder">
        </ph>
      1. Mettez à jour la configuration du point de terminaison/du serveur cible pour tous les proxys d'API qui ont référencé l'ancien keystore et l'ancien alias de clé pour référencer le nouveau keystore et la nouvelle clé. un alias.
      2. Pour tous les proxys d'API qui référencent le keystore à partir d'une définition TargetEndpoint, vous devez redéployer le proxy.

        Si le TargetEndpoint fait référence à une définition TargetServer et que le TargetServer fait référence au keystore, aucun redéploiement de proxy n'est nécessaire.
      3. Si le keystore est utilisé pour le protocole TLS bidirectionnel entre Edge et le service de backend, et vous avez supprimé/recréé le keystore portant le même nom, vous devez redémarrer l'Edge Processeurs de messages.
  4. Après avoir vérifié que votre nouveau keystore fonctionne correctement, supprimez l'ancien keystore avec le certificat et la clé expirés, comme décrit ci-dessus.

Mettre à jour un certificat TLS dans un truststore

Si vous utilisez des références au truststore, le processus de mise à jour d'un certificat dans un truststore est la même que pour un keystore, comme indiqué ci-dessus. Les seules différences sont les suivantes :

  • Lorsque vous importez le nouveau certificat dans le nouveau truststore, le nom de l'alias n'a pas d'importance pour Truststores.
  • Si un certificat fait partie d'une chaîne, vous devez soit créer un seul fichier contenant tous les de certificats certifiés, puis importez ce fichier vers un seul alias, ou importez tous les certificats de la chaîne séparément dans le magasin de confiance en utilisant un alias différent pour chaque certificat.

Si vous utilisez des noms directs de vos keystores et de vos Truststores:

  1. Importez un nouveau certificat dans le truststore, comme décrit dans la section Keystores et Truststores. Il n'est pas nécessaire de supprimer l'ancien certificat.
  2. Pour un hôte virtuel utilisé par des connexions entrantes, c'est-à-dire une requête API dans Edge, redémarrez les routeurs un par un.
  3. Pour un point de terminaison ou un serveur cible utilisés par des connexions sortantes : c'est-à-dire d'Apigee vers un serveur backend, redémarrez les processeurs de messages Edge un par un en temps réel.
  4. Vérifiez que votre nouveau truststore fonctionne correctement.