Использование SNI с Edge

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X.
информация

Индикация имени сервера (SNI) позволяет обслуживать несколько целей HTTPS с одного и того же IP-адреса и порта, не требуя, чтобы эти цели использовали один и тот же сертификат TLS. Когда на клиенте включен SNI, клиент передает имя хоста целевой конечной точки как часть первоначального подтверждения TLS. Это позволяет серверу TLS определить, какой сертификат TLS следует использовать для проверки запроса.

Например, если целью запроса является https:// example.com /request/path , клиент TLS добавляет расширение server_name к запросу установления связи TLS, как показано ниже:

Edge поддерживает SNI для:

  • Запросы от клиентского приложения к прокси-серверу API. В этом сценарии Edge выступает в роли сервера TLS.
  • Запросы от Edge к бэкэнду. В этом сценарии Edge выступает в роли клиента TLS.

Дополнительную информацию о SNI см.:

Поддержка SNI для запроса к API-прокси на Edge

Поддержка SNI для запросов к прокси-серверам API контролируется псевдонимами хостов и виртуальными хостами.

О виртуальных хостах и ​​псевдонимах хостов

В Edge виртуальный хост определяет IP-адрес и порт или DNS-имя и порт, на которых отображается прокси-сервер API, и, как следствие, URL-адрес, который приложения используют для доступа к прокси-серверу API. IP-адрес/DNS-имя соответствуют пограничному маршрутизатору, а номер порта — это открытый порт маршрутизатора.

Когда вы создаете виртуальный хост, вы также указываете псевдоним виртуального хоста. Обычно это DNS-имя виртуального хоста. В рамках определения прокси-сервера API, который обрабатывает запрос, маршрутизатор сравнивает заголовок Host входящего запроса со списком доступных псевдонимов хоста, определенных всеми виртуальными хостами.

Комбинация псевдонима хоста и номера порта для виртуального хоста должна быть уникальной для всех виртуальных хостов в установке Edge. Это означает , что несколько виртуальных хостов могут использовать один и тот же номер порта, если у них разные псевдонимы хоста.

Виртуальный хост также определяет, осуществляется ли доступ к прокси-серверу API по протоколу HTTP или по зашифрованному протоколу HTTPS с использованием TLS. При настройке виртуального хоста для использования HTTPS свяжите виртуальный хост с хранилищем ключей, содержащим сертификат и закрытый ключ, используемые виртуальным хостом во время установления связи TLS.

Дополнительную информацию о виртуальных хостах см.:

Как SNI работает с псевдонимами хостов

SNI позволяет вам определить несколько виртуальных хостов на одном порту, каждый с разными сертификатами и ключами TLS. Затем Edge определяет виртуальный хост и пару сертификат/ключ, используемую TLS, на основе расширения server_name в запросе установления связи TLS.

Пограничный маршрутизатор считывает расширение server_name в запросе установления связи TLS, а затем использует его для поиска псевдонимов хостов со всех виртуальных хостов. Если маршрутизатор обнаруживает совпадение с псевдонимом хоста, он использует сертификат и ключ TLS от виртуального хоста, связанного с псевдонимом хоста. Если совпадение не найдено, подтверждение связи TLS завершается неудачей.

Чтобы избежать сбоя подтверждения TLS, вы можете определить пару сертификат/ключ по умолчанию, как описано в следующих разделах.

Определение пары сертификат/ключ по умолчанию в Edge для облака

Apigee предоставляет сертификат TLS и закрытый ключ для поддержки HTTPS. Хотя многие клиенты предпочитают использовать собственный сертификат и закрытый ключ во время развертывания, вы можете развернуть свои API, используя сертификат и ключ Apigee.

В Edge для облака, если маршрутизатор не может сопоставить заголовок SNI с псевдонимом хоста или если клиент не поддерживает SNI, маршрутизатор использует сертификат по умолчанию, предоставленный Apigee, то есть *.apigee.net.

Определение пары сертификат/ключ по умолчанию в Edge для частного облака

В Edge для частного облака, если не найдено совпадения между расширением server_name и псевдонимами хостов со всех виртуальных хостов или если запрашивающий клиент не поддерживает SNI, вы можете настроить маршрутизатор на использование сертификата/ключа из виртуального хоста по умолчанию. хост в порту. Виртуальный хост по умолчанию определяется комбинацией имени организации, имени среды и имени виртуального хоста в форме:

orgName_envName_vhName

Маршрутизатор использует сертификат/ключ из комбинации orgName_envName_vhName , которая идет первой в алфавитном порядке. Например, запрос поступает на порт 443, и для example org в среде prod определены два виртуальных хоста:

  • имя виртуального хоста = default
  • имя виртуального хоста = test

В этом примере маршрутизатор использует сертификат/ключ виртуального хоста с именем default , поскольку example_prod_default идет в алфавитном порядке перед example_prod_test .

Чтобы включить виртуальный хост по умолчанию:

  1. На первом узле Router отредактируйте /opt/apigee/customer/application/router.properties . Если этот файл не существует, создайте его.
  2. Добавьте в файл следующее свойство, чтобы можно было определить виртуальный хост по умолчанию:
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Перезагрузите маршрутизатор:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Повторите эти шаги на всех остальных маршрутизаторах.

Вместо использования сертификата/ключа виртуального хоста по умолчанию вы можете явно определить сертификат/ключ по умолчанию на маршрутизаторе. Используйте следующую процедуру, чтобы определить явную пару сертификат/ключ по умолчанию:

  1. На первом узле маршрутизатора скопируйте сертификат и закрытый ключ в место на узле маршрутизатора, доступное пользователю apigee. Например, /opt/apigee/customer/application .
  2. Измените владельца файлов на «apigee. пользователь:
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. Отредактируйте /opt/apigee/customer/application/router.properties . Если этот файл не существует, создайте его.
  4. Добавьте в файл следующие свойства, чтобы можно было указать сертификат/ключ по умолчанию:
    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. Установите следующие свойства в router.properties , чтобы указать расположение сертификата и ключа:
    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. Перезагрузите маршрутизатор:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Повторите эти шаги на всех остальных маршрутизаторах.

Поддержка SNI для запросов от Edge к бэкэнду

Edge поддерживает использование SNI от процессоров сообщений для целевых конечных точек в Apigee Edge для развертываний в облаке и частном облаке. По умолчанию SNI включен на пограничных процессорах сообщений для облака и отключен в частном облаке.

Использование SNI для серверной части Edge в частном облаке

Для Edge для частного облака, чтобы обеспечить обратную совместимость с существующими целевыми серверными модулями, Apigee по умолчанию отключил SNI. Если ваш целевой сервер настроен на поддержку SNI, вы можете включить эту функцию, как описано ниже, для вашей версии Edge.

Никакой другой конфигурации для Edge не требуется. Если ваша целевая среда настроена для SNI, Edge поддерживает его. Edge автоматически извлекает имя хоста из URL-адреса запроса и добавляет его в запрос на подтверждение TLS.

Включите SNI между Edge и серверной частью для Edge версии 4.15.07.0x.

Используйте следующую процедуру, чтобы включить SNI:

  1. На первом узле процессора сообщений откройте файл /opt/apigee4/conf/apigee/message-processor/system.properties в редакторе.
  2. Установите для следующего свойства значение true в system.properties :
    jsse.enableSNIExtension=true
  3. Перезапустите процессоры сообщений:
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Повторите эти шаги на всех остальных процессорах сообщений.

Включите SNI между Edge и серверной частью для Edge версии 4.16.01 и более поздних версий.

Используйте следующую процедуру, чтобы включить SNI:

  1. На первом узле процессора сообщений отредактируйте /opt/apigee/customer/application/message-processor.properties . Если этот файл не существует, создайте его.
  2. Добавьте в файл следующее свойство:
    conf_system_jsse.enableSNIExtension=true
  3. Перезапустите процессор сообщений:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Повторите эти шаги на всех остальных процессорах сообщений.