Utiliser SNI avec Edge

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

L'indication du nom de serveur (SNI) permet de diffuser plusieurs cibles HTTPS à partir de la même adresse IP et du même port sans que ces cibles aient besoin d'utiliser le même certificat TLS. Lorsque SNI est activé sur un client, celui-ci transmet le nom d'hôte du point de terminaison cible lors du handshake TLS initial. Cela permet au serveur TLS de déterminer quel certificat TLS doit être utilisé pour valider la requête.

Par exemple, si la cible de la requête est https://example.com/request/path, le client TLS ajoute l'extension server_name à la requête d'établissement de la poignée TLS, comme indiqué ci-dessous:

Edge est compatible avec le SNI pour:

  • Requêtes envoyées par une application cliente à un proxy d'API. Dans ce scénario, Edge agit en tant que serveur TLS.
  • Requêtes d'Edge vers le backend. Dans ce scénario, Edge agit en tant que client TLS.

Pour en savoir plus sur le SNI, consultez les pages suivantes:

Prise en charge du SNI pour une requête envoyée à un proxy d'API sur Edge

La prise en charge du SNI pour les requêtes envoyées aux proxys d'API est contrôlée par les alias d'hôtes et les hôtes virtuels.

À propos des hôtes virtuels et des alias d'hôte

Avec Edge, un hôte virtuel définit l'adresse IP et le port, ou le nom et le port DNS, sur lesquels un proxy d'API est exposé et, par extension, l'URL que les applications utilisent pour accéder à un proxy d'API. L'adresse IP/le nom DNS correspond à un routeur Edge, et le numéro de port est un port ouvert sur le routeur.

Lorsque vous créez l'hôte virtuel, vous spécifiez également son alias d'hôte. Il s'agit généralement du nom DNS de l'hôte virtuel. Pour déterminer le proxy d'API qui gère la requête, le routeur compare l'en-tête Host de la requête entrante à la liste des alias d'hôte disponibles définis par tous les hôtes virtuels.

La combinaison de l'alias d'hôte et du numéro de port de l'hôte virtuel doit être unique pour tous les hôtes virtuels de l'installation Edge. Cela signifie que plusieurs hôtes virtuels peuvent utiliser le même numéro de port s'ils ont des alias d'hôte différents.

Un hôte virtuel définit également si l'accès au proxy d'API s'effectue à l'aide du protocole HTTP ou du protocole HTTPS chiffré à l'aide de TLS. Lorsque vous configurez un hôte virtuel pour qu'il utilise HTTPS, associez-le à un keystore contenant le certificat et la clé privée utilisés par l'hôte virtuel lors du handshake TLS.

Pour en savoir plus sur les hôtes virtuels, consultez les pages suivantes:

Fonctionnement du SNI avec les alias d'hôte

Le SNI vous permet de définir plusieurs hôtes virtuels sur le même port, chacun avec des certificats et des clés TLS différents. Edge détermine ensuite l'hôte virtuel et la paire certificat/clé utilisée par TLS, en fonction de l'extension server_name dans la requête de poignée TLS.

Le routeur Edge lit l'extension server_name dans la requête d'établissement de la liaison TLS, puis l'utilise pour rechercher les alias d'hôte de tous les hôtes virtuels. Si le routeur détecte une correspondance avec un alias d'hôte, il utilise le certificat et la clé TLS de l'hôte virtuel associé à l'alias d'hôte. En l'absence de correspondance, le handshake TLS échoue.

Plutôt que de laisser l'établissement de la poignée TLS échouer, vous pouvez définir une paire certificat/clé par défaut, comme décrit dans les sections suivantes.

Définir une paire de certificat/clé par défaut dans Edge pour le cloud

Apigee fournit un certificat TLS et une clé privée pour prendre en charge le protocole HTTPS. Bien que de nombreux clients préfèrent utiliser leur propre certificat et leur propre clé privée au moment du déploiement, vous pouvez déployer vos API à l'aide du certificat et de la clé Apigee.

Dans Edge pour le cloud, si le routeur ne peut pas faire correspondre l'en-tête SNI à un alias d'hôte ou si le client n'est pas compatible avec SNI, le routeur utilise le certificat par défaut fourni par Apigee, à savoir *.apigee.net.

Définir une paire de certificat/clé par défaut dans Edge pour le cloud privé

Dans Edge pour le cloud privé, si aucune correspondance n'est trouvée entre l'extension server_name et les alias d'hôte de tous les hôtes virtuels, ou si le client à l'origine de la requête n'est pas compatible avec SNI, vous pouvez configurer le routeur pour qu'il utilise le certificat/la clé d'un hôte virtuel par défaut sur le port. L'hôte virtuel par défaut est défini par une combinaison du nom de l'organisation, du nom de l'environnement et du nom de l'hôte virtuel, sous la forme suivante:

orgName_envName_vhName

Le routeur utilise le certificat/la clé de la combinaison orgName_envName_vhName qui vient en premier par ordre alphabétique. Par exemple, la requête arrive sur le port 443, et deux hôtes virtuels sont définis pour l'organisation example dans l'environnement prod:

  • nom d'hôte virtuel = default
  • nom d'hôte virtuel = test

Dans cet exemple, le routeur utilise le certificat/la clé de l'hôte virtuel nommé default, car example_prod_default vient avant example_prod_test dans l'ordre alphabétique.

Pour activer l'hôte virtuel par défaut:

  1. Sur le premier nœud de routeur, modifiez /opt/apigee/customer/application/router.properties. Si ce fichier n'existe pas, créez-le.
  2. Ajoutez la propriété suivante au fichier pour pouvoir définir un hôte virtuel par défaut: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Redémarrez le routeur: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Répétez ces étapes sur tous les autres routeurs.

Plutôt que d'utiliser le certificat/la clé de l'hôte virtuel par défaut, vous pouvez définir explicitement le certificat/la clé par défaut sur le routeur. Pour définir une paire de certificat/clé par défaut explicite, procédez comme suit:

  1. Sur le premier nœud de routeur, copiez le certificat et la clé privée à un emplacement sur le nœud de routeur accessible par l'utilisateur apigee. Par exemple, /opt/apigee/customer/application.
  2. Attribuez la propriété des fichiers à l'utilisateur "apigee" : 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
     
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. Modifier /opt/apigee/customer/application/router.properties. Si ce fichier n'existe pas, créez-le.
  4. Ajoutez les propriétés suivantes au fichier pour pouvoir spécifier le certificat/la clé par défaut:
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. Définissez les propriétés suivantes dans router.properties pour spécifier l'emplacement du certificat et de la clé: 
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. Redémarrez le routeur: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Répétez ces étapes sur tous les autres routeurs.

Prise en charge du SNI pour les requêtes d'Edge vers le backend

Edge prend en charge l'utilisation du SNI des processeurs de messages pour cibler les points de terminaison dans Apigee Edge pour le cloud et les déploiements dans le cloud privé. Par défaut, le SNI est activé sur les processeurs de messages Edge pour le cloud et désactivé dans le cloud privé.

Utiliser SNI avec le backend dans Edge pour le cloud privé

Pour Edge pour le cloud privé, Apigee a désactivé le SNI par défaut afin d'assurer la rétrocompatibilité avec les backends cibles existants. Si votre backend cible est configuré pour prendre en charge le SNI, vous pouvez activer cette fonctionnalité comme décrit ci-dessous pour votre version d'Edge.

Aucune autre configuration spécifique à Edge n'est requise. Si votre environnement cible est configuré pour le SNI, Edge le prend en charge. Edge extrait automatiquement le nom d'hôte de l'URL de la requête et l'ajoute à la requête de poignée TLS.

Activer le SNI entre Edge et le backend pour la version 4.15.07.0x d'Edge

Pour activer le SNI, procédez comme suit:

  1. Sur le premier nœud "Message Processor", ouvrez le fichier /opt/apigee4/conf/apigee/message-processor/system.properties dans un éditeur.
  2. Définissez la propriété suivante sur "true" dans system.properties: 
    jsse.enableSNIExtension=true
  3. Redémarrez les processeurs de messages: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Répétez cette procédure pour tous les autres processeurs de messages.

Activer le SNI entre Edge et le backend pour la version 4.16.01 d'Edge et les versions ultérieures

Pour activer le SNI, procédez comme suit:

  1. Sur le premier nœud du processeur de messages, modifiez /opt/apigee/customer/application/message-processor.properties. Si ce fichier n'existe pas, créez-le.
  2. Ajoutez la propriété suivante au fichier: 
    conf_system_jsse.enableSNIExtension=true
  3. Redémarrez le processeur de messages: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Répétez cette procédure pour tous les autres processeurs de messages.