Utiliser SNI avec Edge

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

L'indication du nom du serveur (SNI, Server Name Indication) permet de diffuser plusieurs cibles HTTPS à partir de la même adresse IP et du même port, sans exiger que ces cibles utilisent le même certificat TLS. Lorsque l'extension SNI est activée 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 à la requête de handshake TLS, comme indiqué ci-dessous:

Edge prend en charge la SNI pour:

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

Pour plus d'informations sur la SNI, voir:

Prise en charge de la SNI pour une requête adressée au proxy d'API sur Edge

La compatibilité SNI pour les requêtes adressé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. 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 est effectué via le protocole HTTP ou via le protocole HTTPS chiffré via 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 plus d'informations sur les hôtes virtuels, voir:

Fonctionnement de la SNI avec les alias d'hôte

L'extension 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 handshake TLS.

Le routeur Edge lit l'extension server_name dans la requête de handshake TLS, puis l'utilise pour rechercher les alias d'hôte à partir 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 d'entraîner l'échec du handshake TLS, 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 assurer l'assistance 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 for the Cloud, si le routeur ne peut pas faire correspondre l'en-tête SNI à un alias d'hôte ou si le client ne prend pas en charge SNI, le routeur 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 à l'origine de la demande n'est pas compatible avec la 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 la combinaison du nom de l'organisation, du nom de l'environnement et du nom de l'hôte virtuel, sous la forme:

orgName_envName_vhName

Le routeur utilise le certificat/la clé de la combinaison de orgName_envName_vhName, qui apparaît en premier dans l'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 de l'hôte virtuel = default
  • nom de l'hôte virtuel = test

Dans cet exemple, le routeur utilise le certificat ou la clé de l'hôte virtuel nommé default, car example_prod_default précède example_prod_test par 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 cette procédure sur tous les autres routeurs.

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

  1. Sur le premier nœud de routeur, copiez le certificat et la clé privée dans un emplacement du nœud de routeur qui est accessible par l'utilisateur Apigee. Par exemple, /opt/apigee/customer/application.
  2. Remplacez la propriété des fichiers par "apigee. user" : 
    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 cette procédure sur tous les autres routeurs.

Prise en charge de la SNI pour les requêtes en provenance de Edge vers le backend

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

Utilisation de SNI vers le backend dans Edge pour le cloud privé

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

Activer l'extension SNI entre Edge et le backend pour Edge version 4.15.07.0x

Pour activer l'extension SNI, procédez comme suit:

  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 l'extension SNI entre Edge et le backend pour Edge version 4.16.01 et ultérieure

Pour activer l'extension SNI, procédez comme suit:

  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.