Сбои установления связи TLS/SSL

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

Симптом

Ошибка установления соединения 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 (Transport Layer Security, предшественником которого является SSL) — это стандартная технология безопасности для установления зашифрованного соединения между веб-сервером и веб-клиентом, например, браузером или приложением. Процесс установления соединения (handshake ) позволяет клиенту и серверу TLS/SSL установить набор секретных ключей, с помощью которых они могут обмениваться данными. В ходе этого процесса клиент и сервер:

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

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

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

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

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

Диагноз

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

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

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

     

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

     

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

   • Дальнейшее изучение сообщения № 6 показывает, что причиной сбоя рукопожатия TLS/SSL является то, что бэкэнд-сервер поддерживает только протокол TLSv1.0, как показано ниже:

     

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

Разрешение

Обработчик сообщений работает на 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 только в клиентском приложении (для входящих соединений) или на бэкэнд-сервере (для исходящих соединений), поскольку у вас нет доступа к пограничному маршрутизатору или процессору сообщений.

   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" на пограничный маршрутизатор (получатель).

     

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

     

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

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

       

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

     

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

Разрешение

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

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

Ошибка подтверждения 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. Получите имя сертификата в хранилище ключей :
      
      Если вы используете частное облако , воспользуйтесь API управления следующим образом:
      

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

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

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

   2. Получите сведения о сертификате в хранилище ключей, используя 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
          },

      В основном сертификате имя субъекта имеет в качестве CN что-то вроде something.domain.com.

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

Разрешение

Эту проблему можно решить одним из двух способов:

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

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

• Получите сертификат (если у вас его еще нет) с существующим именем субъекта (CN), но используйте 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 только в клиентском приложении (для входящих соединений) или на бэкэнд-сервере (для исходящих соединений), поскольку у вас нет доступа к пограничному маршрутизатору или процессору сообщений.

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

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

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

   
   

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

      
      

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

      

   8. Сертификат бэкэнд-сервера и вся его цепочка доступны в разделе «Сертификаты», как показано на рисунке выше.
7. Если маршрутизатор (направление на север) или обработчик сообщений (направление на юг) обнаружит, что сертификат неизвестен, как в приведенном выше примере, выполните следующие действия:
   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. Получите полную цепочку сертификатов, используемых в сертификате, хранящемся в конкретном хранилище ключей. (См. конфигурацию виртуального хоста для маршрутизатора и конфигурацию целевой конечной точки для обработчика сообщений.) Для получения подробной информации о сертификате можно использовать следующие 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. Проверьте, совпадает ли сертификат, хранящийся в хранилище ключей маршрутизатора (на север) или обработчика сообщений (на юг), с сертификатом, хранящимся в хранилище доверенных сертификатов клиентского приложения (на север) или целевого сервера (на юг), или с сертификатом, полученным из вывода 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 и попробуйте подключиться к соответствующему имени хоста сервера (маршрутизатор Edge или бэкэнд-сервер), указав имя сервера , как показано ниже:

   openssl s_client -connect hostname:port -servername hostname

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

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

Диагноз

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

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

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

      

   3. Выбор сообщения "Client Hello" показывает, что обработчик сообщений использует протокол TLSv1.2.

      

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

        

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

      

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

Разрешение

Для обеспечения возможности взаимодействия обработчика(ов) сообщений с серверами, поддерживающими 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. Перезапустите обработчик сообщений.

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

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

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