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

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

Симптом

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

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

HTTP/1.1 503 Service Unavailable

Вы также можете увидеть это сообщение об ошибке, когда происходит сбой подтверждения TLS/SSL:

Received fatal alert: handshake_failure

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

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

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

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

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

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

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

Диагностика

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

   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.
   • Если вы являетесь пользователем Public Cloud , вы можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на внутреннем сервере (для исходящих или южных подключений), поскольку у вас нет доступа к Edge. Маршрутизатор или процессор сообщений.

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

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

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

     

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

     

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

     • Однако маршрутизатор Edge по-прежнему отправляет клиентскому приложению «Неустранимая ошибка: сбой установления связи» , как показано на снимке экрана ниже:

       

   • Ошибка может быть результатом одной из следующих проблем:
     • Клиентское приложение не использует алгоритмы набора шифров, поддерживаемые пограничным маршрутизатором.
     • 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 для поддержки алгоритмов набора шифров 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. Получите имя сертификата в хранилище ключей :
      
      Если вы являетесь пользователем частного облака , используйте 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. Получите сведения о сертификате в хранилище ключей с помощью 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.
   • Если вы являетесь пользователем Public Cloud , вы можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на внутреннем сервере (для исходящих или южных подключений), поскольку у вас нет доступа к Edge. Маршрутизатор или процессор сообщений.

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

   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.
   • Если вы являетесь пользователем Public Cloud , вы можете собирать данные tcpdump только в клиентском приложении (для входящих или северных подключений) или на внутреннем сервере (для исходящих или южных подключений), поскольку у вас нет доступа к Edge. Маршрутизатор или процессор сообщений.

   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. Внутренний сервер немедленно отправляет процессору сообщений фатальное предупреждение: сбой квитирования (сообщение № 5). Это означает, что подтверждение TLS/SSL не удалось и соединение будет закрыто.
   6. Просмотрите сообщение №6, чтобы узнать следующую информацию.
      • Внутренний сервер поддерживает протокол TLSv1.2. Это означает, что протокол между процессором сообщений и внутренним сервером совпадает.
      • Однако внутренний сервер по-прежнему отправляет неустранимое предупреждение: сбой квитирования процессору сообщений, как показано на рисунке ниже:

        

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

      

   9. Это подтверждает, что процессор сообщений не отправил имя_сервера на внутренний сервер с поддержкой SNI.
   10. Это является причиной сбоя подтверждения TLS/SSL и причиной того, что внутренний сервер отправляет неустранимое предупреждение: сбой установления связи на процессор сообщений.
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 .