Usa SNI con Edge

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

La indicación del nombre del servidor (SNI) permite entregar varios objetivos HTTPS desde la misma dirección IP y puerto sin que esos destinos usen el mismo certificado TLS. Cuando la SNI está habilitada en un cliente, este pasa el nombre de host del extremo de destino como parte del protocolo de enlace TLS inicial. Esto permite que el servidor TLS determine qué certificado TLS se debe usar para validar la solicitud.

Por ejemplo, si el destino de la solicitud es https://example.com/request/path, el cliente TLS agrega la extensión server_name a la solicitud de protocolo de enlace TLS, como se muestra a continuación:

Edge admite SNI para lo siguiente:

  • Solicitudes de una app cliente a un proxy de API En esta situación, Edge actúa como el servidor de TLS
  • Solicitudes de Edge al backend. En esta situación, Edge actúa como el cliente de TLS.

Para obtener información adicional sobre SNI, consulta:

Compatibilidad con SNI para una solicitud al proxy de API en Edge

La compatibilidad de SNI para las solicitudes a los proxies de API se controla mediante alias de hosts y hosts virtuales.

Acerca de los hosts virtuales y los alias de host

Con Edge, un host virtual define la dirección IP y el puerto, o el nombre y puerto de DNS, en los que se expone un proxy de API y, por extensión, la URL que usan las apps para acceder a un proxy de API. La dirección IP o el nombre de DNS corresponden a un router perimetral y el número de puerto es un puerto abierto en el router.

Cuando creas el host virtual, también debes especificar su alias. Por lo general, es el nombre de DNS del host virtual. Como parte de determinar el proxy de API que controla la solicitud, el router compara el encabezado Host de la solicitud entrante con la lista de alias de host disponibles definidos por todos los hosts virtuales.

La combinación del alias de host y el número de puerto del host virtual debe ser única para todos los hosts virtuales en la instalación de Edge. Esto significa que varios hosts virtuales pueden usar el mismo número de puerto si tienen diferentes alias de host.

Un host virtual también define si se accede al proxy de API mediante el protocolo HTTP o el protocolo HTTPS encriptado con TLS. Cuando configures un host virtual para que use HTTPS, asócialo con un almacén de claves que contenga el certificado y la clave privada que usó el host virtual durante el protocolo de enlace TLS.

Para obtener información adicional sobre los hosts virtuales, consulta los siguientes vínculos:

Cómo funciona la SNI con los alias de host

La SNI te permite tener varios hosts virtuales definidos en el mismo puerto, cada uno con diferentes certificados y claves TLS. Luego, Edge determina el host virtual y el par certificado/clave que usa TLS, según la extensión server_name en la solicitud de protocolo de enlace TLS.

Edge Router lee la extensión server_name en la solicitud de protocolo de enlace TLS y, luego, la usa para buscar los alias de host de todos los hosts virtuales. Si el router detecta una coincidencia con un alias de host, usa el certificado y la clave TLS del host virtual asociado con el alias del host. Si no se encuentra una coincidencia, falla el protocolo de enlace TLS.

En lugar de que el protocolo de enlace TLS falle, puedes definir un par certificado/clave predeterminado, como se describe en las siguientes secciones.

Define un par certificado/clave predeterminado en Edge para Cloud

Apigee proporciona un certificado TLS y una clave privada para admitir HTTPS. Si bien muchos clientes prefieren usar su propio certificado y clave privada en el momento de la implementación, puedes implementar tus APIs con el certificado y la clave de Apigee.

En Edge para Cloud, si el router no puede hacer coincidir el encabezado de SNI con un alias de host o si el cliente no admite SNI, el router usa el certificado predeterminado que proporciona Apigee, que es *.apigee.net.

Define un par certificado/clave predeterminado en Edge para la nube privada

En Edge para la nube privada, si no se encuentra ninguna coincidencia entre la extensión server_name y los alias de host de todos los hosts virtuales, o si el cliente solicitante no admite SNI, puedes configurar el router para que use el certificado o la clave de un host virtual predeterminado en el puerto. El host virtual predeterminado se define mediante una combinación del nombre de la organización, el nombre del entorno y el nombre del host virtual de la siguiente forma:

orgName_envName_vhName

El router usa el certificado o la clave de la combinación de orgName_envName_vhName que aparece primero en orden alfabético. Por ejemplo, la solicitud llega al puerto 443, y hay dos hosts virtuales definidos para la organización example en el entorno prod:

  • nombre de host virtual = default
  • nombre de host virtual = test

En este ejemplo, el router usa el certificado/clave del host virtual llamado default porque example_prod_default aparece en orden alfabético antes de example_prod_test.

Para habilitar el host virtual predeterminado, haz lo siguiente:

  1. En el primer nodo de router, edita /opt/apigee/customer/application/router.properties. Si ese archivo no existe, créalo.
  2. Agrega la siguiente propiedad al archivo para permitirte definir un host virtual predeterminado: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Reinicia el router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Repite estos pasos en todos los routers restantes.

En lugar de usar el certificado o la clave del host virtual predeterminado, puedes definirlos de forma explícita en el router. Usa el siguiente procedimiento para definir un par certificado/clave explícito explícito:

  1. En el primer nodo del router, copia el certificado y la clave privada en una ubicación del nodo del router a la que pueda acceder el usuario de Apigee. Por ejemplo, /opt/apigee/customer/application.
  2. Cambia la propiedad de los archivos al usuario de "apigee.": 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. Editar /opt/apigee/customer/application/router.properties. Si ese archivo no existe, créalo.
  4. Agrega las siguientes propiedades al archivo para permitirte especificar el certificado o la clave predeterminados:
    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. Configura las siguientes propiedades en router.properties para especificar la ubicación del certificado y la clave: 
    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. Reinicia el router: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Repite estos pasos en todos los routers restantes.

Compatibilidad con SNI para solicitudes de Edge al backend

Edge admite el uso de SNI de Message Processor para los extremos de destino en Apigee Edge para Cloud y para implementaciones de nube privada. De forma predeterminada, la SNI está habilitada en los procesadores de mensajes perimetrales para la nube y se inhabilita en la nube privada.

Usa la SNI en el backend de Edge para la nube privada

Para que Edge de la nube privada sea retrocompatible con los backends de destino existentes, Apigee inhabilitó la SNI de forma predeterminada. Si tu backend de destino está configurado para admitir SNI, puedes habilitar esta función como se describe a continuación para tu versión de Edge.

No se requiere ninguna otra configuración específica de Edge. Si tu entorno de destino está configurado para SNI, Edge lo admite. Edge extrae de forma automática el nombre de host de la URL de la solicitud y lo agrega a la solicitud de protocolo de enlace TLS.

Habilita la SNI entre Edge y el backend para la versión 4.15.07.0x de Edge.

Usa el siguiente procedimiento para habilitar la SNI:

  1. En el primer nodo de Message Processor, abre el archivo /opt/apigee4/conf/apigee/message-processor/system.properties en un editor.
  2. Establece la siguiente propiedad como verdadera en system.properties: 
    jsse.enableSNIExtension=true
  3. Reinicia los procesadores de mensajes: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Repite estos pasos en todos los procesadores de mensajes restantes.

Habilita la SNI entre Edge y el backend para la versión 4.16.01 y posteriores de Edge.

Usa el siguiente procedimiento para habilitar la SNI:

  1. En el primer nodo de Message Processor, edita /opt/apigee/customer/application/message-processor.properties. Si ese archivo no existe, créalo.
  2. Agrega la siguiente propiedad al archivo: 
    conf_system_jsse.enableSNIExtension=true
  3. Reinicia Message Processor: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Repite estos pasos en todos los procesadores de mensajes restantes.