Usa SNI con Edge

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

La indicación del nombre del servidor (SNI) permite que se entreguen varios destinos HTTPS desde la misma dirección IP y el mismo puerto sin requerir que esos destinos usen el mismo certificado TLS. Cuando SNI está habilitado en un cliente, el cliente pasa el nombre de host del extremo de destino como parte del protocolo de enlace TLS inicial. Eso 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 este caso, Edge actúa como el servidor TLS )
  • Solicitudes de Edge al backend (en este caso, Edge actúa como el cliente TLS)

Para obtener más información sobre SNI, consulta lo siguiente:

Cómo admitir SNI para una solicitud al proxy de API en Edge

La compatibilidad con SNI para las solicitudes a los proxies de API se controla mediante los alias de host y los 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 de DNS y el puerto, 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 de Edge, y el número de puerto es un puerto abierto en el router.

Cuando creas el host virtual, también especificas su alias. Por lo general, este es el nombre de DNS del host virtual. Como parte de la determinación del 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 de alias de host y número de puerto para el host virtual debe ser única para todos los hosts virtuales en la instalación de Edge. Eso significa que varios hosts virtuales pueden usar el mismo número de puerto si tienen alias de host diferentes.

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 configuras un host virtual para usar HTTPS, asocia el host virtual con un almacén de claves que contenga el certificado y la clave privada que usa el host virtual durante el protocolo de enlace TLS.

Para obtener más información sobre los hosts virtuales, consulta lo siguiente:

Cómo funciona SNI con los alias de host

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 de certificados o claves que usa TLS, según la server_name extensión en la solicitud de protocolo de enlace TLS.

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

En lugar de que falle el protocolo de enlace TLS, puedes definir un par de certificados o claves predeterminado, como se describe en las siguientes secciones.

Cómo definir un par de certificados o claves 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 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.

Cómo definir un par de certificados o claves 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 de nombre de la organización, nombre del entorno y nombre del host virtual, en el siguiente formato:

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 del host virtual = default
  • Nombre del host virtual = test

En este ejemplo, el router usa el certificado o la clave del host virtual llamado default porque example_prod_default aparece alfabéticamente antes que example_prod_test.

Para habilitar el host virtual predeterminado, haz lo siguiente:

  1. En el primer nodo del 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 definir de forma explícita el certificado o la clave predeterminado en el router. Usa el siguiente procedimiento para definir un par de certificados o claves predeterminado explícito:

  1. En el primer nodo del router, copia el certificado y la clave privada a una ubicación en el 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. Edita /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 predeterminado:
    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. Establece 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.

Cómo admitir SNI para solicitudes de Edge a el backend

Edge admite el uso de SNI desde los procesadores de mensajes hasta los extremos de destino en Apigee Edge para Cloud y para implementaciones de la nube privada. De forma predeterminada, SNI está habilitado en los procesadores de mensajes de Edge para Cloud y está inhabilitado en la nube privada.

Usa SNI en el backend en Edge para la nube privada

En Edge para la nube privada, para que sea compatible con versiones anteriores con los backends de destino existentes, Apigee inhabilitó 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 automáticamente el nombre de host de la URL de la solicitud y lo agrega a la solicitud de protocolo de enlace TLS.

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

Usa el siguiente procedimiento para habilitar 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 en true 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 SNI entre Edge y el backend para la versión 4.16.01 de Edge y versiones posteriores

Usa el siguiente procedimiento para habilitar 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 el procesador de mensajes: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Repite estos pasos en todos los procesadores de mensajes restantes.