503 Служба недоступна — ошибка рукопожатия SSL

Мониторинг API

Процедура №1: Использование мониторинга API

Для диагностики ошибки с помощью мониторинга API:

1. Войдите в пользовательский интерфейс Apigee Edge под учетной записью пользователя с соответствующей ролью .

2. Переключитесь на организацию, в которой вы хотите расследовать проблему.

   
3. Перейдите на страницу Анализ > Мониторинг API > Исследование .
4. Выберите конкретный временной промежуток, в течение которого вы наблюдали ошибки.

5. Постройте график зависимости кода ошибки от времени .

6. Выберите ячейку с кодом ошибки messaging.adaptors.http.flow.SslHandshakeFailed , как показано ниже:

   ( Посмотреть увеличенное изображение )

   

7. Информация об ошибке с кодом messaging.adaptors.http.flow.SslHandshakeFailed отображается следующим образом:

   ( Посмотреть увеличенное изображение )

   

8. Нажмите «Просмотреть журналы» и разверните строку с неудачным запросом.

   ( Посмотреть увеличенное изображение )

   
9. В окне «Журналы» обратите внимание на следующие сведения:
   • Идентификатор сообщения запроса
   • Код состояния: 503
   • Источник неисправности: target
   • Код ошибки: messaging.adaptors.http.flow.SslHandshakeFailed

След

Процедура №2: Использование инструмента трассировки

Для диагностики ошибки с помощью инструмента трассировки:

1. Включите сеанс трассировки и либо
   • Дождитесь появления ошибки 503 Service Unavailable с кодом ошибки messaging.adaptors.http.flow.SslHandshakeFailed или
   • Если вы можете воспроизвести проблему, выполните вызов API для воспроизведения ошибки 503 Service Unavailable

2. Убедитесь, что параметр «Показывать все FlowInfos» включен:

   
3. Выберите один из запросов, завершившихся неудачей, и изучите трассировку.
4. Проследите за различными этапами трассировки и определите место возникновения сбоя.

5. Ошибка обычно возникает после этапа "Начался поток целевого запроса" , как показано ниже:

   ( Посмотреть увеличенное изображение )

   
6. Обратите внимание на следующие значения из трассировки:
   • Ошибка: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class: com.apigee.errors.http.server.ServiceUnavailableException
   • Значение ошибки SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target указывает на то, что SSL Handshake завершился неудачей, поскольку обработчик сообщений Apigee Edge не смог проверить сертификат бэкэнд-сервера.
7. Перейдите к этапу AX (Analytics Data Recorded) в трассировке и щелкните по нему.

8. Прокрутите вниз до раздела «Заголовки ошибок в подробностях этапа» и определите значения X-Apigee-fault-code , X-Apigee-fault-source и X-Apigee-Message-ID, как показано ниже:

   ( Посмотреть увеличенное изображение )

   
9. Обратите внимание на значения X-Apigee-fault-code , X-Apigee-fault-source и X-Apigee-Message-ID :

Заголовки ошибок	Ценить
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Процедура №3: ​​Использование журналов доступа NGINX

Для диагностики ошибки с помощью журналов доступа NGINX:

1. Если вы используете частное облако , то можете использовать журналы доступа NGINX для получения ключевой информации об ошибке HTTP 503 Service Unavailable .

2. Проверьте журналы доступа NGINX:

   /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log

3. Проверьте, были ли какие-либо ошибки 503 с кодом ошибки messaging.adaptors.http.flow.SslHandshakeFailed за определенный период времени (если проблема возникала ранее) или есть ли запросы, которые по-прежнему завершаются с ошибкой 503 .

4. Если вы обнаружите ошибки 503 с кодом X-Apigee-fault-code, соответствующим значению messaging.adaptors.http.flow.SslHandshakeFailed , определите значение X-Apigee-fault-source.

   Пример ошибки 503 из журнала доступа NGINX:

   ( Посмотреть увеличенное изображение )

   

   Приведенная выше запись из журнала доступа NGINX содержит следующие значения для X-Apigee-fault-code и X-Apigee-fault-source:

   Заголовки	Ценить
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Журналы обработчика сообщений

Процедура №4: Использование журналов процессора сообщений

1. Определите идентификатор сообщения одного из запросов, завершившихся с ошибкой, используя мониторинг API, инструмент трассировки или журналы доступа NGINX, как описано в разделе «Общие шаги диагностики» .

2. Найдите идентификатор конкретного сообщения запроса в журнале обработчика сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log ). Вы можете увидеть следующую ошибку:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   Указанная выше ошибка свидетельствует о сбое SSL-рукопожатия между обработчиком сообщений и серверной частью.

   Затем возникнет исключение с подробным трассировочным стеком, как показано ниже:

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   Обратите внимание, что сбой при установлении соединения произошел по следующей причине:

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   Это указывает на то, что SSL-рукопожатие не удалось, поскольку обработчик сообщений Apigee Edge не смог проверить сертификат бэкэнд-сервера.

Фаза 1

Этап 1: Определение цепочки сертификатов бэкэнд-сервера.

Для определения цепочки сертификатов бэкэнд-сервера используйте один из следующих методов:

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

Фаза 2

Этап 2: Сравните сертификат бэкэнд-сервера с сертификатами, хранящимися в хранилище доверенных сертификатов обработчика сообщений.

1. Определите цепочку сертификатов бэкэнд-сервера .
2. Определите сертификат, хранящийся в хранилище доверенных сертификатов обработчика сообщений, выполнив следующие шаги:

   1. Получите имя ссылки на хранилище доверенных сертификатов из элемента TrustStore в разделе SSLInfo в TargetEndpoint .

      Рассмотрим пример раздела SSLInfo в конфигурации TargetEndpoint :

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>

   2. В приведенном выше примере имя ссылки TrustStore — myCompanyTruststoreRef .

   3. В пользовательском интерфейсе Edge выберите «Среды» > «Ссылки» . Запишите имя в столбце «Ссылка» для конкретной ссылки на хранилище доверенных сертификатов. Это будет имя вашего хранилища доверенных сертификатов.

      ( Посмотреть увеличенное изображение )

      

   4. В приведенном выше примере имя хранилища доверенных сертификатов следующее:

      myCompanyTruststoreRef : myCompanyTruststore

3. Получите сертификаты, хранящиеся в хранилище доверенных сертификатов (определенном на предыдущем шаге), используя следующие API:

   1. Получить все сертификаты для хранилища ключей или хранилища доверенных сертификатов . Этот API отображает список всех сертификатов в конкретном хранилище доверенных сертификатов.

      Пользователь публичного облака:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Пользователь частного облака:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Где:

      • ORGANIZATION_NAME — это название организации.
      • ENVIRONMENT_NAME — это имя среды.
      • KEYSTORE_NAME — это имя хранилища ключей.
      • Переменная $TOKEN устанавливается в значение вашего токена доступа OAuth 2.0, как описано в разделе «Получение токена доступа OAuth 2.0».
      • Параметры curl , используемые в этом примере, описаны в разделе «Использование curl».

      Пример выходных данных:

      В качестве примеров сертификатов для хранилища доверенных myCompanyTruststore используются следующие:

      [
        "serverCert"
      ]

   2. Получение сведений о конкретном сертификате из хранилища ключей или хранилища доверенных сертификатов . Этот API возвращает информацию о конкретном сертификате в конкретном хранилище доверенных сертификатов.

      Пользователь публичного облака:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Пользователь частного облака

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Где:

      • ORGANIZATION_NAME — это название организации.
      • ENVIRONMENT_NAME — это имя среды.
      • KEYSTORE_NAME — это имя хранилища ключей.
      • CERT_NAME — это имя сертификата.
      • Переменная $TOKEN устанавливается в значение вашего токена доступа OAuth 2.0, как описано в разделе «Получение токена доступа OAuth 2.0».
      • Параметры curl , используемые в этом примере, описаны в разделе «Использование curl».

      Пример выходных данных

      В подробной информации о serverCert указаны субъект и издатель следующим образом:

      Сертификат Leaf/Entity:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      Сертификат о прохождении промежуточного курса:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

4. Убедитесь, что фактический сертификат сервера, полученный на шаге 1, и сертификат, хранящийся в хранилище доверенных сертификатов, полученный на шаге 3, совпадают. Если они не совпадают, то это и является причиной проблемы.

   Рассмотрим по одному сертификату из приведенного выше примера:

   1. Сертификат листа:

      С серверной части:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4

      Из хранилища доверенных сертификатов обработчика сообщений (клиента):

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      Конечный сертификат, хранящийся в хранилище доверенных сертификатов, совпадает с сертификатом бэкэнд-сервера.

   2. Сертификат о прохождении промежуточного курса:

      С серверной части:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      Из хранилища доверенных сертификатов обработчика сообщений (клиента):

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

      Промежуточный сертификат, хранящийся в хранилище доверенных сертификатов, соответствует сертификату бэкэнд-сервера.

   3. Корневой сертификат:

      С серверной части:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      В хранилище доверенных сертификатов обработчика сообщений полностью отсутствует корневой сертификат.

   4. Поскольку корневой сертификат отсутствует в хранилище доверенных сертификатов, обработчик сообщений выдает следующее исключение:

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

      и возвращает клиентским приложениям 503 Service Unavailable с кодом ошибки messaging.adaptors.http.flow.SslHandshakeFailed .

Правильное полное доменное имя (FQDN)

Обновите хранилище ключей на бэкэнд-сервере, указав правильное полное доменное имя (FQDN) и действительную и полную цепочку сертификатов:

1. Если у вас нет сертификата бэкэнд-сервера с правильным полным доменным именем (FQDN), получите соответствующий сертификат у уполномоченного центра сертификации (CA).

2. Убедитесь, что у вас имеется действительная и полная цепочка сертификатов бэкэнд-сервера .

3. После того как у вас будет действительная и полная цепочка сертификатов с правильным полным доменным именем (FQDN) бэкэнд-сервера в конечном сертификате или сертификате сущности, идентичным имени хоста, указанному в целевой конечной точке, обновите хранилище ключей бэкэнда, указав полную цепочку сертификатов.

Правильный сервер бэкэнда

Обновите целевую конечную точку, указав правильное имя хоста бэкэнд-сервера:

1. Если в целевой конечной точке было неверно указано имя хоста, обновите целевую конечную точку, указав правильное имя хоста, соответствующее полному доменному имени (FQDN) в сертификате бэкэнд-сервера.

2. Сохраните изменения в API-прокси.

   В приведенном выше примере, если имя хоста бэкэнд-сервера было указано неверно, вы можете исправить это, используя полное доменное имя (FQDN) из сертификата бэкэнд-сервера, а именно backend.apigee.net , следующим образом:

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>