Сбои при подтверждении TLS/SSL

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

Symptom

Сбой подтверждения TLS/SSL происходит, когда клиент и сервер не могут установить связь с помощью протокола TLS/SSL. Когда эта ошибка возникает в Apigee Edge, клиентское приложение получает статус HTTP 503 с сообщением Сервис недоступен. Эта ошибка возникает при любом вызове API, в котором происходит сбой подтверждения TLS/SSL.

Сообщения об ошибках

HTTP/1.1 503 Service Unavailable

Это сообщение об ошибке также может появиться при сбое рукопожатия TLS/SSL:

Received fatal alert: handshake_failure

Возможные причины

TLS (безопасность транспортного уровня, предшественником которого является SSL) – это стандартная технология безопасности для установления зашифрованного соединения между веб-сервером и веб-клиентом, например браузером или приложением. Рукопожатие – это процесс, который позволяет клиенту и серверу TLS/SSL установить набор секретных ключей, с помощью которых они могут обмениваться данными. В процессе обмена данными клиент и сервер:

1. Согласуйте версию протокола.
2. Выберите криптографический алгоритм.
3. Выполнять аутентификацию друг друга, обмениваясь цифровыми сертификатами и проверяя их.

Если подтверждение TLS/SSL прошло успешно, клиент и сервер TLS/SSL безопасно передают друг другу данные. В противном случае при сбое рукопожатия TLS/SSL соединение будет разорвано, а клиент получит ошибку 503 Service Unavailable.

Возможные причины сбоя рукопожатия TLS/SSL:

Несоответствие протокола

Сбой подтверждения TLS/SSL происходит, если протокол, используемый клиентом, не поддерживается сервером во входящем (северном) или исходящем (южном) подключении. Также ознакомьтесь со статьей О входящих и исходящих подключениях.

диагностика;

1. Определите, где произошла ошибка: в северном или южном соединении. Дополнительную информацию о том, как определить источник проблемы, можно найти в разделе Как определить источник проблемы.
2. Чтобы получить дополнительную информацию, запустите утилиту tcpdump:
   • Если вы используете частное облако, то можете собирать данные tcpdump на нужном клиенте или сервере. Клиентом может быть клиентское приложение (для входящих или северных подключений) или обработчик сообщений (для исходящих или южных подключений). Сервер может быть пограничным маршрутизатором (для входящих или северных подключений) или внутренним сервером (для исходящих или южных подключений) в зависимости от того, что вы определили на шаге 1.
   • Если вы используете общедоступное облако, то можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на бэкенд-сервере (для исходящих или южных подключений), поскольку у вас нет доступа к пограничному маршрутизатору или Message Processor.

   tcpdump -i any -s 0 host IP address -w File name
   

   Подробнее о том, как использовать команду tcpdump, можно узнать из данных tcpdump.
3. Проанализируйте данные tcpdump с помощью Wireshark или другого похожего инструмента.
4. Ниже приведен пример анализа tcpdump с помощью Wireshark:
   • В этом примере ошибка рукопожатия TLS/SSL произошла между Message Processor и бэкенд-сервером (исходящее или южное подключение).
   • Сообщение № 4 в приведенном ниже выводе tcpdump показывает, что Message Processor (источник) отправил сообщение "Client Hello" на бэкенд-сервер (назначение).
     

     

   • Если вы выберете сообщение Client Hello, то увидите, что Message Processor использует протокол TLSv1.2, как показано ниже:

     

   • В сообщении № 5 показано, что бэкенд-сервер подтверждает получение сообщения "Client Hello" от Message Processor.
   • Внутренний сервер немедленно отправляет Fatal Alert : Close Notify обработчику сообщений (сообщение № 6). Это означает, что рукопожатие TLS/SSL не выполнено и подключение будет закрыто.

   • Если посмотреть на сообщение № 6, можно увидеть, что причина сбоя при подключении TLS/SSL заключается в том, что серверная часть поддерживает только протокол TLSv1.0, как показано ниже:

     

   • Из-за несоответствия между протоколом, используемым Message Processor, и бэкенд-сервером, бэкенд-сервер отправил сообщение Fatal Alert Message: Close Notify.

Разрешение

Message Processor работает на Java 8 и по умолчанию использует протокол TLSv1.2. Если сервер не поддерживает протокол TLSv1.2, вы можете устранить проблему одним из следующих способов:

1. Обновите серверную часть, чтобы она поддерживала протокол TLSv1.2. Это рекомендуемое решение, поскольку протокол TLSv1.2 более безопасен.
2. Если вы не можете обновить внутренний сервер прямо сейчас, вы можете заставить процессор сообщений использовать протокол TLSv1.0 для связи с внутренним сервером, выполнив следующие действия:
   1. Если вы не указали целевой сервер в определении TargetEndpoint прокси, задайте для элемента Protocol значение TLSv1.0, как показано ниже:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Если вы настроили целевой сервер для прокси, используйте этот API управления, чтобы задать протокол TLSv1.0 в конфигурации целевого сервера.

Несоответствие шифров

Сбой рукопожатия TLS/SSL может произойти, если алгоритм набора шифров, используемый клиентом, не поддерживается сервером во входящем (северном) или исходящем (южном) подключении в Apigee Edge. Также ознакомьтесь со статьей О входящих и исходящих подключениях.

диагностика;

1. Определите, где произошла ошибка: в северном или южном подключении. Дополнительную информацию можно найти в разделе Как определить источник проблемы.
2. Чтобы получить дополнительную информацию, запустите утилиту tcpdump:
   • Если вы используете частное облако, то можете собирать данные tcpdump на нужном клиенте или сервере. Клиентом может быть клиентское приложение (для входящих или северных подключений) или обработчик сообщений (для исходящих или южных подключений). Сервер может быть пограничным маршрутизатором (для входящих или северных подключений) или внутренним сервером (для исходящих или южных подключений) в зависимости от того, что вы определили на шаге 1.
   • Если вы используете общедоступное облако, то можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на бэкенд-сервере (для исходящих или южных подключений), поскольку у вас нет доступа к пограничному маршрутизатору или Message Processor.

   tcpdump -i any -s 0 host IP address -w File name
   

   Подробнее о том, как использовать команду tcpdump, можно узнать из данных tcpdump.
3. Проанализируйте tcpdump данные с помощью инструмента Wireshark или любого другого инструмента, с которым вы знакомы.
4. Ниже приведен пример анализа выходных данных tcpdump с помощью Wireshark:
   • В этом примере сбой рукопожатия TLS/SSL произошел между клиентским приложением и пограничным маршрутизатором (северное подключение). Выходные данные tcpdump были собраны на пограничном маршрутизаторе.

   • Сообщение № 4 в приведенном ниже выводе tcpdump показывает, что клиентское приложение (источник) отправило сообщение "Client Hello" маршрутизатору Edge (назначение).

     

   • Если выбрать сообщение Client Hello, вы увидите, что клиентское приложение использует протокол TLSv1.2.

     

   • В сообщении № 5 показано, что пограничный маршрутизатор подтверждает получение сообщения "Client Hello" от клиентского приложения.
   • Пограничный маршрутизатор немедленно отправляет клиентскому приложению критическое оповещение : сбой рукопожатия (сообщение № 6). Это означает, что рукопожатие TLS/SSL не выполнено и подключение будет закрыто.
   • Если посмотреть подробную информацию о сообщении № 6, можно увидеть следующее:
     • Пограничный маршрутизатор поддерживает протокол TLSv1.2. Это означает, что протокол соответствует между клиентским приложением и пограничным маршрутизатором.

     • Однако маршрутизатор Edge по-прежнему отправляет клиентскому приложению критическое оповещение: ошибка подтверждения, как показано на скриншоте ниже.

       

   • Ошибка может быть вызвана одной из следующих проблем:
     • Клиентское приложение не использует алгоритмы набора шифров, поддерживаемые маршрутизатором Edge.
     • Пограничный маршрутизатор поддерживает SNI, но клиентское приложение не отправляет имя сервера.
   • В сообщении № 4 в выходных данных tcpdump перечислены алгоритмы набора шифров, поддерживаемые клиентским приложением, как показано ниже:

     

   • Список алгоритмов набора шифров, поддерживаемых маршрутизатором Edge, приведен в файле /opt/nginx/conf.d/0-default.conf. В этом примере маршрутизатор Edge поддерживает только алгоритмы набора шифров с высоким уровнем шифрования.
   • Клиентское приложение не использует ни один из алгоритмов набора шифров High Encryption. Это несоответствие является причиной сбоя рукопожатия TLS/SSL.
   • Поскольку маршрутизатор Edge поддерживает SNI, прокрутите вывод tcpdump до сообщения № 4 и убедитесь, что клиентское приложение правильно отправляет имя сервера, как показано на рисунке ниже:
     
     
     
   • Если имя действительно, можно сделать вывод, что ошибка рукопожатия TLS/SSL произошла из-за того, что алгоритмы набора шифров, используемые клиентским приложением, не поддерживаются маршрутизатором Edge.

Разрешение

Убедитесь, что клиент использует алгоритмы набора шифров, которые поддерживаются сервером. Чтобы устранить проблему, описанную в предыдущем разделе "Диагностика", скачайте и установите пакет Java Cryptography Extension (JCE) и добавьте его в установку Java для поддержки алгоритмов набора шифров High Encryption.

Неверный сертификат

Сбой рукопожатия TLS/SSL происходит, если в хранилище ключей или доверенном хранилище есть неправильные сертификаты, либо во входящем (северном), либо в исходящем (южном) подключении в Apigee Edge. Также ознакомьтесь со статьей О входящих и исходящих подключениях.

Если проблема на стороне клиента, вы можете увидеть разные сообщения об ошибках в зависимости от причины.

В следующих разделах приведены примеры сообщений об ошибках и инструкции по диагностике и устранению этой проблемы.

Сообщения об ошибках

В зависимости от причины сбоя рукопожатия TLS/SSL вы можете увидеть разные сообщения об ошибках. Ниже приведен пример сообщения об ошибке, которое может появиться при вызове прокси-сервера API:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Возможные причины

Обычно это происходит по следующим причинам:

Несовпадение имени хоста

диагностика;

1. Запишите имя хоста, используемое в URL, который возвращается при следующем вызове API управления Edge:

   curl -v https://myorg.domain.com/v1/getinfo

   Пример:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Получите CN, используемый в сертификате, который хранится в определенном хранилище ключей. Чтобы получить информацию о сертификате, можно использовать следующие API управления Edge:
   1. Получите название сертификата в хранилище ключей:
      
      Если вы используете Private Cloud, воспользуйтесь Management API следующим образом:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Если вы используете общедоступное облако, используйте Management API следующим образом:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Получите сведения о сертификате в хранилище ключей с помощью Management API Edge.
      
      Если вы используете частное облако:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Если вы пользователь общедоступного облака:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Пример сертификата::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      В названии субъекта основного сертификата в качестве общего имени указано значение something.domain.com..

      Поскольку имя хоста, используемое в URL запроса к API (см. шаг 1 выше), и имя субъекта в сертификате не совпадают, происходит сбой рукопожатия TLS/SSL.

Разрешение

Эту проблему можно устранить двумя способами:

• Получите сертификат (если у вас его ещё нет), в котором в поле CN субъекта есть подстановочный знак, а затем загрузите новую полную цепочку сертификатов в хранилище ключей. Пример:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Получите сертификат (если у вас его ещё нет) с существующим именем субъекта, но используйте your-org.your-domain в качестве альтернативного имени субъекта, а затем загрузите полную цепочку сертификатов в хранилище ключей.

Ссылки

Хранилища ключей и доверенных сертификатов

Неполная или неверная цепочка сертификатов

диагностика;

1. Получите CN, используемый в сертификате, который хранится в определенном хранилище ключей. Чтобы получить информацию о сертификате, можно использовать следующие API управления Edge:
   1. Получите название сертификата в хранилище ключей:
      
      Если вы пользователь частного облака:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Если вы пользователь общедоступного облака:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Получите информацию о сертификате в хранилище ключей:
      
      Если вы используете частное облако:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Если вы пользователь общедоступного облака:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Проверьте сертификат и его цепочку и убедитесь, что они соответствуют требованиям, указанным в статье Как работают цепочки сертификатов. Если цепочка сертификатов, хранящаяся в хранилище ключей, неполная или недействительная, то вы увидите ошибку рукопожатия TLS/SSL.
   4. На изображении ниже показан пример сертификата с недействительной цепочкой сертификатов, в которой промежуточный и корневой сертификаты не совпадают.

   Пример промежуточного и корневого сертификатов, в которых издатель и субъект не совпадают

   
   

Разрешение

1. Получите сертификат (если у вас его ещё нет), который включает полную и действительную цепочку сертификатов.
2. Выполните следующую команду openssl, чтобы проверить, правильно ли настроена цепочка сертификатов и является ли она полной:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Загрузите проверенную цепочку сертификатов в хранилище ключей.

Сервер или клиент отправил сертификат с истекшим сроком действия или неизвестный сертификат

Если сервер или клиент отправляет неправильный или просроченный сертификат при подключении к северному или южному интерфейсу, другая сторона (сервер или клиент) отклоняет сертификат, что приводит к сбою подтверждения TLS/SSL.

диагностика;

1. Определите, где произошла ошибка: в северном или южном соединении. Дополнительную информацию о том, как определить источник проблемы, можно найти в разделе Как определить источник проблемы.
2. Чтобы получить дополнительную информацию, запустите утилиту tcpdump:
   • Если вы используете частное облако, то можете собирать данные tcpdump на нужном клиенте или сервере. Клиентом может быть клиентское приложение (для входящих или северных подключений) или обработчик сообщений (для исходящих или южных подключений). Сервер может быть пограничным маршрутизатором (для входящих или северных подключений) или внутренним сервером (для исходящих или южных подключений) в зависимости от того, что вы определили на шаге 1.
   • Если вы используете общедоступное облако, то можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на бэкенд-сервере (для исходящих или южных подключений), поскольку у вас нет доступа к пограничному маршрутизатору или Message Processor.

   tcpdump -i any -s 0 host IP address -w File name
   

   Подробнее о том, как использовать команду tcpdump, можно узнать из данных tcpdump.
3. Проанализируйте данные tcpdump с помощью Wireshark или аналогичного инструмента.
4. По результатам команды tcpdump определите хост (клиент или сервер), который отклоняет сертификат на этапе проверки.
5. Вы можете получить сертификат, отправленный с другой стороны, из выходных данных tcpdump, если данные не зашифрованы. Это поможет сравнить сертификат с сертификатом, доступным в хранилище доверенных сертификатов.
6. Ознакомьтесь с примером tcpdump для SSL-соединения между Message Processor и внутренним сервером.

   Пример tcpdump с ошибкой "Неизвестный сертификат"

   
   

   1. Message Processor (клиент) отправляет бэкенд-серверу (сервер) "Client Hello" в сообщении № 59.
   2. Сервер отправляет сообщение "Server Hello" обработчику сообщений в сообщении 61.
   3. Они взаимно проверяют используемые алгоритмы протокола и набора шифров.
   4. Бэкенд-сервер отправляет сертификат и сообщение Server Hello Done в Message Processor в сообщении № 68.
   5. Message Processor отправляет критическое оповещение "Описание: сертификат Неизвестно" в сообщении № 70.
   6. Если посмотреть на сообщение № 70, то кроме предупреждения, показанного ниже, никаких дополнительных сведений нет:

      
      

   7. Проверьте сообщение № 68, чтобы получить информацию о сертификате, отправленном серверной частью, как показано на следующем изображении:

      

   8. Сертификат внутреннего сервера и вся его цепочка доступны в разделе "Сертификаты", как показано на рисунке выше.
7. Если сертификат неизвестен маршрутизатору (северное направление) или Message Processor (южное направление), как показано на примере выше, выполните следующие действия:
   1. Получите сертификат и его цепочку, хранящиеся в определенном хранилище доверенных сертификатов. (См. конфигурацию виртуального хоста для маршрутизатора и конфигурацию целевой конечной точки для процессора сообщений.) Чтобы получить информацию о сертификате, можно использовать следующие API:
      1. Получите название сертификата в хранилище доверенных сертификатов:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Как получить информацию о сертификате в хранилище доверенных сертификатов

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Проверьте, совпадает ли сертификат, хранящийся в доверенном хранилище маршрутизатора (северное направление) или процессора сообщений (южное направление), с сертификатом, хранящимся в хранилище ключей клиентского приложения (северное направление) или целевого сервера (южное направление), или с сертификатом, полученным из выходных данных команды tcpdump. Если они не совпадают, это и является причиной сбоя рукопожатия TLS/SSL.
8. Если клиентское приложение (на северном направлении) или целевой сервер (на южном направлении) не распознает сертификат, выполните следующие действия:
   1. Получите полную цепочку сертификатов, используемую в сертификате, хранящемся в определенном хранилище ключей. (См. конфигурацию виртуального хоста для маршрутизатора и конфигурацию целевой конечной точки для Message Processor.) Чтобы получить информацию о сертификате, можно использовать следующие API:
      1. Получите название сертификата в хранилище ключей:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Чтобы получить информацию о сертификате в хранилище ключей:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Проверьте, соответствует ли сертификат, хранящийся в хранилище ключей маршрутизатора (северное направление) или Message Processor (южное направление), сертификату, хранящемуся в доверенном хранилище клиентского приложения (северное направление) или целевого сервера (южное направление), или сертификату, полученному из выходных данных tcpdump. Если они не совпадают, то это и является причиной сбоя рукопожатия SSL.
9. Если срок действия сертификата, отправленного сервером или клиентом, истек, принимающий клиент или сервер отклонит сертификат и вы увидите следующее сообщение об ошибке в tcpdump:

   Предупреждение (уровень: критический, описание: срок действия сертификата истек)

10. Убедитесь, что срок действия сертификата в хранилище ключей нужного хоста истек.

Разрешение

Чтобы устранить проблему, описанную в примере выше, загрузите действительный сертификат внутреннего сервера в хранилище доверенных сертификатов на процессоре сообщений.

В таблице ниже приведены инструкции по устранению проблемы в зависимости от ее причины.

Сервер с поддержкой SNI

Сбой подтверждения TLS/SSL может произойти, когда клиент взаимодействует с сервером, на котором включена функция SNI (указание имени сервера), но сам клиент не поддерживает SNI. Это может произойти при подключении к северному или южному интерфейсу в Edge.

Сначала вам нужно определить имя хоста и номер порта используемого сервера и проверить, включена ли на нем функция SNI.

Идентификация сервера с поддержкой SNI

1. Выполните команду openssl и попробуйте подключиться к нужному имени хоста сервера (маршрутизатору Edge или внутреннему серверу) без передачи имени сервера, как показано ниже:

   openssl s_client -connect hostname:port

   Вы можете получить сертификаты, но иногда при выполнении команды openssl может произойти сбой подтверждения, как показано ниже:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. Выполните команду openssl и попробуйте подключиться к нужному имени хоста сервера (пограничному маршрутизатору или серверу внутренней сети), передав имя сервера, как показано ниже:

   openssl s_client -connect hostname:port -servername hostname

3. Если на шаге 1 произойдет сбой подтверждения или сертификаты на шагах 1 и 2 будут разными, это означает, что на указанном сервере включена функция SNI.

Если вы определили, что на сервере включена функция SNI, выполните следующие действия, чтобы проверить, не связана ли ошибка рукопожатия TLS/SSL с тем, что клиент не может подключиться к серверу SNI.

диагностика;

1. Определите, где произошла ошибка: в северном или южном соединении. Дополнительную информацию о том, как определить источник проблемы, можно найти в разделе Как определить источник проблемы.
2. Чтобы получить дополнительную информацию, запустите утилиту tcpdump:
   • Если вы используете частное облако, то можете собирать данные tcpdump на нужном клиенте или сервере. Клиентом может быть клиентское приложение (для входящих или северных подключений) или обработчик сообщений (для исходящих или южных подключений). Сервер может быть пограничным маршрутизатором (для входящих или северных подключений) или внутренним сервером (для исходящих или южных подключений) в зависимости от того, что вы определили на шаге 1.
   • Если вы используете общедоступное облако, то можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на бэкенд-сервере (для исходящих или южных подключений), поскольку у вас нет доступа к пограничному маршрутизатору или Message Processor.

   tcpdump -i any -s 0 host IP address -w File name
   

   Подробнее о том, как использовать команду tcpdump, можно узнать из данных tcpdump.
3. Проанализируйте выходные данные tcpdump с помощью Wireshark или похожего инструмента.
4. Ниже приведен пример анализа tcpdump с помощью Wireshark:
   1. В этом примере сбой подтверждения TLS/SSL произошел между процессором сообщений Edge и внутренним сервером (исходящее подключение).
   2. Сообщение № 4 в приведенном ниже выводе tcpdump показывает, что Message Processor (источник) отправил сообщение "Client Hello" на бэкенд-сервер (назначение).

      

   3. Если выбрать сообщение "Клиентское приветствие", можно увидеть, что обработчик сообщений использует протокол TLSv1.2.

      

   4. В сообщении № 4 показано, что бэкенд-сервер подтверждает сообщение "Client Hello" от Message Processor.
   5. Внутренний сервер немедленно отправляет критическое оповещение : ошибка подтверждения обработчику сообщений Message Processor (сообщение № 5). Это означает, что рукопожатие TLS/SSL не удалось и подключение будет закрыто.
   6. Изучите сообщение № 6, чтобы узнать следующую информацию:
      • Сервер поддерживает протокол TLSv1.2. Это означает, что протокол, согласованный между Message Processor и бэкенд-сервером, совпадает.
      • Однако сервер по-прежнему отправляет обработчику сообщений Fatal Alert: Handshake Failure, как показано на рисунке ниже.

        

   7. Эта ошибка может возникнуть по одной из следующих причин:
      • Message Processor не использует алгоритмы набора шифров, поддерживаемые бэкенд-сервером.
      • На внутреннем сервере включена функция SNI, но клиентское приложение не отправляет имя сервера.
   8. Подробнее изучите сообщение № 3 (Client Hello) в выходных данных tcpdump. Обратите внимание, что Extension: server_name отсутствует, как показано ниже:

      

   9. Это подтверждает, что Message Processor не отправил server_name на бэкенд-сервер с поддержкой SNI.
   10. Это приводит к сбою подтверждения TLS/SSL и тому, что сервер отправляет обработчику сообщений критическое оповещение: сбой подтверждения.
5. Убедитесь, что для параметра jsse.enableSNIExtension property в файле system.properties задано значение false в Message Processor, чтобы подтвердить, что Message Processor не может взаимодействовать с сервером с поддержкой SNI.

Разрешение

Чтобы разрешить Message Processor взаимодействовать с серверами, поддерживающими SNI, выполните следующие действия:

1. Создайте файл/opt/apigee/customer/application/message-processor.properties, если он ещё не существует.
2. Добавьте в этот файл следующую строку: conf_system_jsse.enableSNIExtension=true
3. Измените владельца файла на apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Перезапустите Message Processor.

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

5. Если у вас несколько обработчиков сообщений, повторите шаги 1–4 для каждого из них.

Если вы не можете определить причину сбоя рукопожатия TLS/SSL и устранить проблему или вам нужна дополнительная помощь, обратитесь в службу поддержки Apigee Edge. Поделитесь подробной информацией о проблеме и tcpdump.