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

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

Симптом

Клиентское приложение получает ответ HTTP 400 — Bad request с сообщением « Ошибка SSL-сертификата ». Эта ошибка обычно отправляется пограничным маршрутизатором в рамках двусторонней 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 Private Cloud

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

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

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

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

Диагноз

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

    Как правило, виртуальный хост для двусторонней 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 Get virtual host, чтобы получить определение конкретного виртуального хоста.

    Как правило, виртуальный хост для двусторонней 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. Если вы являетесь пользователем публичного облака, предоставьте следующую информацию:
    1. Название организации
    2. Название среды
    3. Имя API-прокси
    4. Имя виртуального хоста
    5. Псевдоним хоста
    6. Выполните команду curl для воспроизведения ошибки.
    7. TCP/IP-пакеты, перехваченные клиентским приложением.
  2. Если вы являетесь пользователем частного облака, предоставьте следующую информацию:
    1. Имя виртуального хоста и его определение с помощью API получения виртуального хоста.
    2. Псевдоним хоста
    3. Полное сообщение об ошибке.
    4. TCP/IP-пакеты, перехваченные клиентским приложением или маршрутизатором.
    5. Результат выполнения команды `List`: список сертификатов из хранилища ключей API , а также подробные сведения о каждом сертификате, полученные с помощью команды `Get cert details API` .
  3. Пожалуйста, укажите, какие разделы этого руководства вы уже пробовали, а также любые другие замечания, которые помогут нам ускорить решение этой проблемы.