400 Неверный запрос — ошибка SSL-сертификата

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

Симптом

Клиентское приложение получает ответ на запрос HTTP 400 — Bad с сообщением « Ошибка сертификата SSL ». Эта ошибка обычно отправляется Edge Router при двусторонней настройке TLS, включенной для входящего соединения с Apigee Edge.

Сообщение об ошибке

Клиентское приложение получает следующий код ответа:

HTTP/1.1 400 Bad Request

Далее следует страница с ошибкой HTML ниже:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

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

Возможные причины этой проблемы следующие:

Причина Описание Инструкции по устранению неполадок применимы для
Сертификат клиента с истекшим сроком действия Срок действия сертификата, отправленного клиентом, истек. Пользователи Edge частного и публичного облака
Неправильный сертификат отправлен клиентом Эта ошибка возникает, если сертификат, отправленный клиентским приложением, не совпадает с сертификатом, хранящимся в хранилище доверенных сертификатов маршрутизатора Edge. Пользователи Edge частного и публичного облака
Отсутствует корневой сертификат клиента в хранилище доверенных сертификатов Эта ошибка возникает, если корневой сертификат, подписанный ЦС клиента, отсутствует в хранилище доверенных сертификатов маршрутизатора Edge. Пользователи Edge частного и публичного облака
Сертификаты клиента не загружены в пограничный маршрутизатор Эта ошибка возникает, если сертификаты клиента, загруженные в хранилище доверенных сертификатов, не загружены на маршрутизатор. Пользователи Edge Private Cloud

Причина: истек срок действия сертификата клиента.

Эта проблема обычно возникает для двустороннего TLS , когда срок действия сертификата, отправленного клиентом, истек. В двустороннем TLS клиент и сервер обмениваются своими общедоступными сертификатами для выполнения рукопожатия. Клиент проверяет сертификат сервера, а сервер проверяет сертификат клиента.

В Edge двусторонний TLS реализован на виртуальном хосте , где сертификат сервера добавляется в хранилище ключей, а сертификат клиента — в хранилища доверенных сертификатов.

Если во время установления связи TLS будет обнаружено, что срок действия сертификата клиента истек, сервер отправит запрос 400 — Bad с сообщением « Ошибка сертификата SSL ».

Диагностика

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

    Обычно виртуальный хост для двусторонней связи TLS выглядит следующим образом:

    <VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

  2. Определите ссылку на хранилище доверенных сертификатов, используемую на виртуальном хосте. В приведенном выше примере имя ссылки на хранилище доверенных сертификатов — myTruststoreRef.

  3. Определите хранилище доверенных сертификатов, на которое указывает ссылка на хранилище доверенных сертификатов.
    1. В пользовательском интерфейсе Edge перейдите в раздел «Администратор» > «Среды» > «Ссылки» и найдите имя ссылки на хранилище доверенных сертификатов.

    2. Обратите внимание на имя конкретной ссылки на хранилище доверенных сертификатов в столбце «Ссылка» . Это будет ваше имя хранилища доверенных сертификатов.

      Пользовательский интерфейс Edge со списком ссылок
      Рисунок 1

      Обратите внимание, что в приведенном выше примере myTruststoreRef имеет ссылку на myTruststore . Таким образом, имя хранилища доверенных сертификатов — myTruststore .

  4. В разделе «Администратор» > «Среды» > «Хранилища ключей TLS» в пользовательском интерфейсе Edge перейдите к «Хранилища ключей TLS» и найдите хранилище доверенных сертификатов, найденное на шаге № 3.

  5. Выберите сертификат в конкретном хранилище доверенных сертификатов (определенном на шаге 3 выше), как показано ниже:

    Рисунок 2

    Сертификат с псевдонимом client-cert-markw в приведенном выше примере показывает, что срок его действия истек.

  6. Проверьте, не истек ли срок действия сертификата для псевдонима сертификата вашего хранилища доверенных сертификатов.
  7. Если срок действия сертификата не истек, перейдите к общим шагам диагностики других причин .

Разрешение

Приобретите новый сертификат и загрузите его:

  1. Создайте новое хранилище доверенных сертификатов, например myNewTruststore.
  2. Загрузите новый сертификат во вновь созданное хранилище доверенных сертификатов.

  3. Измените ссылку на доверенное хранилище, используемую на конкретном виртуальном хосте, чтобы она указывала на новое хранилище доверенных сертификатов, выполнив действия, описанные в разделе «Изменение ссылки» .

    В описанном выше примере укажите ссылку myTruststoreRef на myNewTruststore.

Общие этапы диагностики других причин

  1. Чтобы исследовать эту проблему, вам потребуется перехватывать пакеты TCP/IP с помощью инструмента tcpdump .
    1. Если вы являетесь пользователем частного облака , вы можете перехватывать пакеты TCP/IP в клиентском приложении или маршрутизаторе.
    2. Если вы являетесь пользователем общедоступного облака , захватите пакеты TCP/IP в клиентском приложении.

    3. После того, как вы решили, где вы хотите захватывать пакеты TCP/IP, используйте следующую команду tcpdump для захвата пакетов TCP/IP:

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

      Примечание. Если вы принимаете пакеты TCP/IP на маршрутизаторе, используйте общедоступный IP-адрес клиентского приложения в команде tcpdump .

      Если вы принимаете пакеты TCP/IP в клиентском приложении, используйте общедоступный IP-адрес имени хоста, используемого в виртуальном хосте, в команде tcpdump .

      Обратитесь к tcpdump для получения дополнительной информации об этом инструменте и других вариантах этой команды.

  2. Проанализируйте пакеты TCP/IP, собранные с помощью инструмента Wireshark или аналогичного инструмента, с которым вы знакомы.

Вот анализ образцов данных пакетов TCP/IP с использованием инструмента Wireshark:

  1. Пакет № 30 в tcpdump (изображение ниже) показывает, что клиентское приложение (источник) отправило сообщение «Client Hello» маршрутизатору (назначение).
  2. Пакет № 34 показывает, что маршрутизатор подтверждает сообщение Client Hello от клиентского приложения.
  3. Маршрутизатор отправляет «Server Hello» в пакете № 35, а затем отправляет свой сертификат, а также запрашивает клиентское приложение отправить свой сертификат в пакете № 38.
  4. В пакете № 38, где Маршрутизатор отправляет пакет «Запрос сертификата» , проверьте раздел «Различные имена», в котором представлены сведения о клиентском сертификате, его цепочке и центрах сертификации, которые принимаются Маршрутизатором (сервером).
    5. Рисунок 3

  5. Клиентское приложение отправляет свой сертификат в пакете № 41. Проверьте раздел «Проверка сертификата» в пакете № 41 и определите сертификат, отправленный клиентским приложением.

    Рисунок 4
  6. Убедитесь, что субъект и эмитент сертификата и его цепочка, отправленные клиентским приложением (пакет № 41), совпадают с принятым сертификатом и его цепочкой от Маршрутизатора (пакет № 38). Если есть несоответствие, то это и есть причина данной ошибки. Следовательно, маршрутизатор (сервер) отправляет зашифрованное предупреждение (пакет № 57), за которым следуют FIN, ACK (пакет 58) клиентскому приложению, и в конечном итоге соединение разрывается.
  7. Несоответствие сертификата и его цепочки может быть вызвано сценариями, описанными в следующих разделах.

Причина: клиент отправил неправильный сертификат.

Обычно это происходит, если субъект/эмитент сертификата и/или его цепочки, отправленного клиентским приложением, не соответствует сертификату и/или его цепочке, хранящимся в хранилище доверенных сертификатов Маршрутизатора (Сервера).

Диагностика

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

    Обычно виртуальный хост для двусторонней связи TLS выглядит следующим образом:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. Определите ссылку на хранилище доверенных сертификатов, используемую на виртуальном хосте.

    В приведенном выше примере имя ссылки на хранилище доверенных сертификатов — myCompanyTruststoreRef.

  3. Определите хранилище доверенных сертификатов, на которое указывает ссылка на хранилище доверенных сертификатов.
    1. В пользовательском интерфейсе Edge перейдите в раздел «Администратор» > «Ссылки на среды» и найдите имя ссылки на хранилище доверенных сертификатов.

    2. Обратите внимание на имя конкретной ссылки на хранилище доверенных сертификатов в столбце «Ссылка» . Это будет ваше имя хранилища доверенных сертификатов.

      Пользовательский интерфейс Edge показывает ссылку на хранилище доверенных сертификатов.
      Рисунок 5

      Обратите внимание, что в приведенном выше примере myCompanyTruststoreRef имеет ссылку на myCompanyTruststore. Таким образом, имя хранилища доверенных сертификатов — myCompanyTruststore.

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

    1. Перечислите сертификаты для API хранилища ключей или хранилища доверенных сертификатов .

      Этот API перечисляет все сертификаты в конкретном хранилище доверенных сертификатов.

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

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

  5. Проверьте, совпадают ли эмитент и субъект каждого сертификата и его цепочки, хранящихся в myCompanyTruststore , с сертификатом и его цепочкой, как показано в пакетах TCP/IP (см. пакет № 38) выше. Если есть несоответствие, это означает, что сертификаты, загруженные в хранилище доверенных сертификатов, не загружаются в пограничный маршрутизатор. Перейдите к причине: сертификаты клиента не загружены в пограничный маршрутизатор .
  6. Если на шаге №5 не было обнаружено несоответствий, это означает, что клиентское приложение отправило неправильный сертификат и его цепочку.

Разрешение

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

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

Эта ошибка возникает, если корневой сертификат, подписанный ЦС клиента, отсутствует в хранилище доверенных сертификатов маршрутизатора Edge.

Диагностика

  1. Войдите в пользовательский интерфейс Edge и просмотрите конкретную конфигурацию виртуального хоста, для которой выполняется запрос API ( Администратор > Виртуальные хосты > virtual_host ), или используйте API получения виртуального хоста , чтобы получить определение конкретного виртуального хоста.

    Обычно виртуальный хост для двусторонней связи TLS выглядит следующим образом:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. Определите ссылку на хранилище доверенных сертификатов, используемую на виртуальном хосте. В предыдущем примере имя ссылки на хранилище доверенных сертификатов — myCompanyTruststoreRef.
  3. Определите фактическое хранилище доверенных сертификатов, используемое ссылкой на хранилище доверенных сертификатов.
  4. В пользовательском интерфейсе Edge перейдите в раздел «Администратор» > «Среды» > «Ссылки» и найдите имя ссылки на хранилище доверенных сертификатов.

  5. Имя хранилища доверенных сертификатов для конкретной ссылки на хранилище доверенных сертификатов указано в столбце «Ссылка» .

    Рисунок 6

    Обратите внимание, что в этом примере myCompanyTruststoreRef имеет myCompanyTruststore в столбце «Ссылка». Таким образом, имя хранилища доверенных сертификатов — myCompanyTruststore .

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

  7. Проверьте, включает ли сертификат полную цепочку, включая корневой сертификат, отправленный конкретным клиентом, как показано в пакетах TCP/IP (см. рис. 4 ). Хранилище доверенных сертификатов должно включать корневой сертификат, а также конечный сертификат клиента или листовой и промежуточный сертификат. Если действительный корневой сертификат клиента отсутствует в хранилище доверенных сертификатов, это и есть причина ошибки.

    Однако если полная цепочка сертификатов клиента, включая корневой сертификат, существует в хранилище доверенных сертификатов, это указывает на то, что сертификаты, загруженные в хранилище доверенных сертификатов, возможно, не загружены в пограничный маршрутизатор. В этом случае см. раздел Причина: сертификаты клиента не загружены в пограничный маршрутизатор .

Разрешение

Убедитесь, что правильный сертификат клиента, включая корневой сертификат, доступен в хранилище доверенных сертификатов маршрутизатора Apigee Edge.

Причина: сертификаты клиента не загружены в пограничный маршрутизатор.

  1. Если вы являетесь пользователем публичного облака , обратитесь в службу поддержки Apigee Edge .
  2. Если вы являетесь пользователем частного облака , следуйте приведенным ниже инструкциям для каждого маршрутизатора:
    1. Проверьте, существует ли файл /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem для конкретного виртуального хоста. Если файл не существует, перейдите в раздел «Разрешение» ниже.
    2. Если файл существует, используйте приведенную ниже команду openssl чтобы получить подробную информацию о сертификатах, доступных на пограничном маршрутизаторе: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. Проверьте эмитента, тему и дату окончания срока действия сертификата. Если что-либо из этого не соответствует тому, что наблюдалось в хранилище доверенных сертификатов в пользовательском интерфейсе Edge или при использовании API управления, это и есть причина ошибки.
    4. Возможно, Маршрутизатор не перезагрузил загруженные сертификаты.

Разрешение

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

apigee-service edge-router restart

Перезапустите API и проверьте результаты. Если проблема не устранена, перейдите к разделу «Сбор диагностической информации» .

Сбор диагностической информации

Если проблема не устранена даже после выполнения приведенных выше инструкций, соберите следующую диагностическую информацию. Свяжитесь со службой поддержки Apigee Edge и поделитесь собранной информацией:

  1. Если вы являетесь пользователем Public Cloud, предоставьте следующую информацию:
    1. Название организации
    2. Имя среды
    3. Имя прокси API
    4. Имя виртуального хоста
    5. Псевдоним хоста
    6. Завершите команду Curl, чтобы воспроизвести ошибку.
    7. Пакеты TCP/IP, перехваченные клиентским приложением
  2. Если вы являетесь пользователем частного облака, предоставьте следующую информацию:
    1. Имя виртуального хоста и его определение с помощью API получения виртуального хоста
    2. Псевдоним хоста
    3. Обнаружено полное сообщение об ошибке
    4. Пакеты TCP/IP, перехваченные клиентским приложением или маршрутизатором.
    5. Вывод списка сертификатов из API хранилища ключей , а также сведений о каждом сертификате, полученном с помощью API получения сведений о сертификате .
  3. Подробная информация о том, какие разделы этого руководства вы пробовали, а также любые другие сведения, которые помогут нам ускорить решение этой проблемы.