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 (записанные аналитические данные) в трассировке и щелкните его.

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-код неисправности	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-источник-ошибки	target
X-Apigee-Message-ID	MESSAGE_ID

НГИНКС

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

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

1. Если вы являетесь пользователем частного облака , вы можете использовать журналы доступа NGINX для определения ключевой информации о 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-код неисправности	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-источник-ошибки	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 , используемые в этом примере, описаны в разделе «Использование завитка».

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

      Сертификаты из примера хранилища доверенных сертификатов 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 , используемые в этом примере, описаны в разделе «Использование завитка».

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

      Подробная информация о serverCert показывает субъект и эмитента следующим образом:

      Сертификат листа/субъекта:

      "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 клиентским приложениям.

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

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

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

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

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

Правильный серверный сервер

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

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

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

   В приведенном выше примере, если имя хоста внутреннего сервера было указано неправильно, вы можете исправить это, используя полное доменное имя из сертификата внутреннего сервера, то есть 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>