Utiliser SNI avec Edge

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

L'indication de nom de serveur (Server Name Indication, 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 dans le cadre du handshake TLS initial. Cela permet au serveur TLS de déterminer le certificat TLS à utiliser 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 au handshake TLS requête, comme indiqué ci-dessous :

Edge est compatible avec SNI pour les éléments suivants :

  • Requêtes d'une application cliente vers un proxy d'API. Dans ce scénario, Edge fait office de serveur TLS .
  • Requêtes d'Edge vers le backend. Dans ce scénario, Edge fait office de client TLS.

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

Compatibilité avec SNI pour une requête adressée à un proxy d'API sur Edge

La compatibilité avec SNI pour les requêtes adressées aux proxys d'API est contrôlée par les alias d'hôte 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 DNS et le port, 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 le proxy d'API est accessible à l'aide du protocole HTTP ou par le 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 de SNI avec les alias d'hôte

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_namedans la requête de handshake TLS.

Le routeur Edge lit l'extension server_name dans la requête de handshake TLS, puis l'utilise pour effectuer une recherche dans 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. Si aucune correspondance n'est trouvée, le handshake TLS échoue.

Plutôt que de laisser le handshake TLS échouer, vous pouvez définir une paire certificat/clé par défaut, comme décrit dans les sections suivantes.

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

Apigee fournit un certificat TLS et une clé privée pour prendre en charge 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, il utilise le certificat par défaut fourni par Apigee, à savoir *.apigee.net.

Définir une paire 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 demandeur 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, au format suivant :

orgName_envName_vhName

Le routeur utilise le certificat/la clé de la combinaison orgName_envName_vhName qui apparaît en premier dans l'ordre alphabétique. Par exemple, la requête arrive sur le port 443, et il y a deux hôtes virtuels 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 apparaît 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 routeurs restants.

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. Procédez comme suit pour définir une paire certificat/clé par défaut explicite :

  1. Sur le premier nœud de routeur, copiez le certificat et la clé privée dans un emplacement du nœud de routeur accessible par l'utilisateur apigee. Par exemple, /opt/apigee/customer/application.
  2. Modifiez le propriétaire des fichiers en utilisateur "apigee" : 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
     
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. Modifiez /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 routeurs restants.

Compatibilité avec SNI pour les requêtes d'Edge vers le backend

Edge est compatible avec l'utilisation de SNI à partir des processeurs de messages vers les points de terminaison cibles dans les déploiements Apigee Edge pour le cloud et pour le cloud privé. Par défaut, SNI est activé sur les processeurs de messages Edge pour le cloud et désactivé dans le cloud privé.

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

Pour Edge pour le cloud privé, afin d'assurer la rétrocompatibilité avec les backends cibles existants, Apigee a désactivé SNI par défaut. Si votre backend cible est configuré pour prendre en charge 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 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 handshake TLS.

Activer SNI entre Edge et le backend pour Edge version 4.15.07.0x

Procédez comme suit pour activer SNI :

  1. Sur le premier nœud de processeur de messages, 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 ces étapes sur tous les processeurs de messages restants.

Activer SNI entre Edge et le backend pour Edge version 4.16.01 et ultérieures

Procédez comme suit pour activer SNI :

  1. Sur le premier nœud de 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 ces étapes sur tous les processeurs de messages restants.