Ошибка 400: неверный запрос – ошибка сертификата SSL

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

Symptom

Клиентское приложение получает ответ HTTP 400 – неверный запрос с сообщением Ошибка сертификата 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>

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

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

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

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

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

Если во время подтверждения TLS будет обнаружено, что срок действия сертификата клиента истек, сервер отправит ошибку 400 (неверный запрос) с сообщением Ошибка SSL-сертификата.

диагностика;

1. Войдите в интерфейс Edge и посмотрите конфигурацию определенного виртуального хоста (Admin > Virtual Hosts), для которого выполняется запрос к API, или используйте API для получения виртуального хоста Management 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 выберите Admin > Environments > References и найдите название ссылки на хранилище доверенных сертификатов.

   2. Запомните название в столбце Ссылка для определенной ссылки на хранилище доверенных сертификатов. Это будет название хранилища доверенных сертификатов.

      

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

4. В интерфейсе Edge выберите Admin > Environments > TLS Keystores (Администратор > Среды > Хранилища ключей TLS), перейдите к хранилищам ключей TLS и найдите хранилище доверенных сертификатов, найденное на шаге 3.

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

   

   В примере выше сертификат с псевдонимом 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:

      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, в котором маршрутизатор отправляет пакет Certificate Request, проверьте раздел Distinguished Names, в котором приведена информация о сертификате клиента, его цепочке и центрах сертификации, принимаемых маршрутизатором (сервером).



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

   

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

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

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

диагностика;

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

   2. Запомните название в столбце Ссылка для определенной ссылки на хранилище доверенных сертификатов. Это будет название хранилища доверенных сертификатов.

      

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

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

   1. Как получить список сертификатов для API хранилища ключей или доверенного хранилища

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

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

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

5. Проверьте, совпадают ли издатель и субъект каждого сертификата и его цепочки, хранящихся в myCompanyTruststore, с издателем и субъектом сертификата и его цепочки, указанными в пакетах TCP/IP (см. пакет № 38 выше). Если они не совпадают, это означает, что сертификаты, загруженные в хранилище доверенных сертификатов, не загружаются в маршрутизатор Edge. Перейдите к разделу Причина: сертификаты клиента не загружены в маршрутизатор Edge.
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 выберите Admin > Environments > References и найдите название ссылки на хранилище доверенных сертификатов.

5. Название хранилища доверенных сертификатов для определенной ссылки на него указано в столбце Ссылка.

   

   В этом примере обратите внимание, что в столбце "Ссылка" для myCompanyTruststoreRef указано myCompanyTruststore. Таким образом, название хранилища доверенных сертификатов – myCompanyTruststore.

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

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

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

Разрешение

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

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

1. Если вы используете общедоступное облако, обратитесь в службу поддержки Apigee Edge.
2. Если вы используете частное облако, выполните приведенные ниже инструкции для каждого маршрутизатора:
   1. Проверьте, существует ли файл /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem для определенного виртуального хоста. Если файла нет, перейдите к разделу Решение проблемы ниже.
   2. Если файл существует, используйте приведенную ниже команду openssl, чтобы получить сведения о сертификатах, доступных на маршрутизаторе Edge:

      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. Имя виртуального хоста и его определение с помощью Get virtual host API.
   2. Псевдоним хоста
   3. Полное сообщение об ошибке
   4. Пакеты TCP/IP, захваченные в клиентском приложении или маршрутизаторе.
   5. Выходные данные API для получения списка сертификатов из хранилища ключей, а также сведения о каждом сертификате, полученные с помощью API для получения сведений о сертификате.
3. Подробную информацию о том, какие разделы этого руководства вы уже изучили, и любые другие сведения, которые помогут нам быстрее решить проблему.