Usa SNI con Edge

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

La indicación de nombre de servidor (SNI) permite que se entreguen varios destinos HTTPS desde la misma dirección IP y el mismo puerto sin que esos destinos deban usar 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. Eso permite que el servidor TLS determine qué certificado TLS se debe usar para validar la solicitud.

Por ejemplo, si el objetivo de la solicitud es https://example.com/request/path, el cliente TLS agrega la extensión server_name a la solicitud 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 TLS.

Para obtener más información sobre SNI, consulta los siguientes vínculos:

• https://en.wikipedia.org/wiki/Server_Name_Indication
• http://blog.layershift.com/sni-ssl-production-ready/

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

La compatibilidad con SNI para solicitudes a proxies de API está controlada por alias de host y hosts virtuales.

Acerca de los alias de host y los hosts virtuales

Con Edge, un host virtual define la dirección IP y el puerto, o el nombre y el 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 de borde, y el número de puerto es un puerto abierto en el router.

Cuando creas el host virtual, también especificas el alias del host virtual. 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 que definen todos los hosts virtuales.

La combinación de alias de host y número de puerto del host virtual debe ser única para todos los hosts virtuales de la instalación de Edge. Eso 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 usar HTTPS, asócialo 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 los siguientes recursos:

• Información acerca de los hosts virtuales
• Cómo configurar el acceso a TLS a una API para la nube privada
• Almacenes de claves y truststores

Cómo funciona SNI con alias de host

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

El router de perímetro lee la extensión server_name en la solicitud de protocolo de enlace TLS y, luego, la usa para realizar una búsqueda en 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 de TLS del host virtual asociado con el alias de host. Si no se encuentra ninguna coincidencia, fallará el protocolo de enlace TLS.

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

Cómo definir un par de claves o certificados predeterminados en Edge para la nube

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 for the 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 claves o certificados predeterminados en Edge para la nube privada

En Edge para la nube privada, si no se encuentra una 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, 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 org 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 antes de example_prod_test en orden alfabético.

Para habilitar el host virtual predeterminado, haz lo siguiente:

1. En el primer nodo Router, edita /opt/apigee/customer/application/router.properties. Si ese archivo no existe, créalo.
2. Agrega la siguiente propiedad al archivo para poder 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 la clave o el certificado del host virtual predeterminado, puedes definir de forma explícita la clave o el certificado predeterminados en el router. Usa el siguiente procedimiento para definir un par de certificado/clave predeterminado y explícito:

1. En el primer nodo de router, copia el certificado y la clave privada en una ubicación del nodo de router a la que el usuario de apigee pueda acceder. Por ejemplo, /opt/apigee/customer/application.
2. Cambia la propiedad de los archivos al usuario "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 poder 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. Establece las siguientes propiedades en router.properties para especificar la ubicación de la certificación 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 desde Message Processors para apuntar a extremos en Apigee Edge para la nube y para implementaciones de la nube privada. De forma predeterminada, el SNI está habilitado en los procesadores de mensajes perimetrales para la nube y, además, inhabilitado en la nube privada.

Usa SNI en el backend de Edge para la nube privada

Para que Edge para la nube privada sea retrocompatible 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 verdadero en system.properties:

   jsse.enableSNIExtension=true

3. Reinicia los Message Processors:

   /opt/apigee4/bin/apigee-service message-processor restart

4. Repite estos pasos en todos los procesadores de mensajes restantes.

Habilita SNI entre el perímetro 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 procesador de mensajes, 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.