Usa SNI con Edge

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

La indicación del nombre del servidor (SNI) permite que se entreguen múltiples destinos HTTPS desde la misma IP y un puerto sin necesidad de que esos destinos usen el mismo certificado TLS. Cuando la SNI es habilitado en un cliente, este pasa el nombre de host del extremo de destino como parte del protocolo de enlace TLS. Eso permite que el servidor TLS determine qué certificado TLS se debe usar para validarlo. la solicitud.

Por ejemplo, si el destino de la solicitud es https://example.com/request/path, Luego, el cliente de TLS agrega la extensión server_name al protocolo de enlace TLS una solicitud, 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 la puerta de enlace servidor
  • 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 Perimetrales

La asistencia de SNI para solicitudes a proxies de API está controlada por alias de hosts y los hosts.

Información acerca de las hosts y alias de host

Con Edge, un host virtual define la dirección IP y el puerto, o bien el nombre y el puerto de DNS, en en la 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 del entre la VM y un Cloud 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 del proceso para determinar el proxy de API que controla la solicitud, el router compara el encabezado Host de la solicitud entrante con el una lista de los alias de host disponibles definidos por todos los hosts virtuales.

La combinación del alias del host y el número de puerto para el host virtual debe ser única para todos hosts virtuales en la instalación de Edge. Esto 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 a través del protocolo HTTP, o por el protocolo HTTPS encriptado con TLS. Cuando se configura un host virtual para usar HTTPS, asociar el host virtual con un almacén de claves que contenga el certificado y la clave privada que utiliza el durante el protocolo de enlace TLS.

Para obtener información adicional sobre los hosts virtuales, consulta:

Cómo funciona SNI con alias de host

SNI permite tener múltiples hosts virtuales definidos en el mismo puerto, cada uno con diferentes Certificados y claves TLS. Edge determina el host virtual y el par certificado/clave que usa TLS. según el server_name en la solicitud de protocolo de enlace TLS.

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

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

Define un par de certificados/claves predeterminados en Edge para la nube

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

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

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

En el perímetro de la nube privada, si no se encuentra una coincidencia entre la extensión server_name y los alias del host de todos los hosts virtuales, o si el cliente solicitante no admite SNI, puedes configurar la Router para usar el certificado/clave de un host virtual predeterminado en el puerto. El host virtual predeterminado es definido por una combinación del nombre de la organización, el nombre del entorno y el nombre del host virtual, en el formulario:

orgName_envName_vhName

El router usa el certificado/clave de la combinación de orgName_envName_vhName que aparezca 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 va antes que example_prod_test en orden alfabético.

Para habilitar el host virtual predeterminado, sigue estos pasos:

  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 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 el certificado/clave del host virtual predeterminado, puedes definir de forma explícita el el certificado/clave predeterminado en el router. Usa el siguiente procedimiento para definir un valor predeterminado explícito par de claves/certificado:

  1. En el primer nodo del router, copia el certificado y la clave privada en una ubicación del nodo del router. al que puede acceder el usuario de Apigee. Por ejemplo, /opt/apigee/customer/application.
  2. Cambiar la propiedad de los archivos al Apigee usuario: 
    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 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 en solicitudes de Edge a el backend

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

Usando SNI en el backend en Edge para la nube privada

Para que Edge para la nube privada sea retrocompatible con backends de destino existentes, Apigee inhabilitó la SNI de forma predeterminada. Si tu backend de destino está configurado para admitir SNI, puedes habilita 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 la admite. Edge extrae automáticamente el nombre de host de la URL de la solicitud y lo agrega a la solicitud del 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. Configura 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 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.