SSL: 400 no required certificate was sent
The code and inputs I’m trying to establish SSL connection and I’m getting 400 No required SSL certificate was sent response from the server. I’m doing this in a standard way like it’s described for example here; I run Java 8. The sample of my code would be:
OkHttpClient client = new OkHttpClient(); KeyStore keyStoreClient = getClientKeyStore(); KeyStore keyStoreServer = getServerKeyStore(); String algorithm = ALGO_DEFAULT;//this is defined as "PKIX" KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance(algorithm); keyManagerFactory.init(keyStoreClient, PASSWORD_SERVER.toCharArray()); SSLContext sslContext = SSLContext.getInstance("TLS"); TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(algorithm); trustManagerFactory.init(keyStoreServer); sslContext.init(keyManagerFactory.getKeyManagers(), trustManagerFactory.getTrustManagers(), new SecureRandom()); client.setSslSocketFactory(sslContext.getSocketFactory()); client.setConnectTimeout(32, TimeUnit.SECONDS); // connect timeout client.setReadTimeout(32, TimeUnit.SECONDS); // socket timeout return client;
And here is the code that I use to send GET-request:
public String get(String url) throws IOException
System.setProperty("javax.net.debug", "ssl"); So to see debug messages — but there’s no errors/warnings/alerts there, the only thing is in the very end:
main, called close() main, called closeInternal(true) main, SEND TLSv1.2 ALERT: warning, description = close_notify main, WRITE: TLSv1.2 Alert, length = 26 main, called closeSocket(true) - Different protocols disabling/enabling. For instance, forcing TLSv1 / TLSv1.1 for the socket with no success. To try that I wrapped my ssl factory into another factory which disables/enables certain protocols.
- Disabling SSLv2Hello — but it doesn’t change the picture.
- Install Oracle policies because before there were notices about some skipped algorithms and this installation «solved» that but the overall result is still same.
- Setting System.setProperty(«sun.security.ssl.allowUnsafeRenegotiation», «true»); — lame, but also didn’t change a thing apart from message in the log Allow unsafe renegotiation: true (was «false» obviously)
- Using KeyManagerFactory.getDefaultAlgorithm() as algorithm for KeyManagerFactory.getInstance() call. That raises exception Get Key failed: Given final block not properly padded and as far as I got the idea, it’s because of wrong algorithm used (read this). My default algorithm is: SunX509
- Adding the certificate directly to my machine with keytool -importcert -file /path/to/certificate -keystore keystore.jks -alias «Alias» and then using this in my program via System.setProperty(«javax.net.ssl.trustStore»,»/path/to/keystore.jks»); with setting password: System.setProperty(«javax.net.ssl.trustStorePassword»,»mypassword»); (I set password in keytool after which confirmed trusted certificate with yes ); see this and this posts. No errors were raised with this — but issue persisted.
- Adding the certificate to the global keystore (the one located in JAVA_PATH/jre/lib/security/cacerts ) with: keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias Alias -file /path/to/certificate (see this); looks like import operation was successful but it didn’t change the picture
There’s also notice in debug: ssl: KeyMgr: choosing key: 1 (verified: OK) — not sure if it’s relevant as I’m not SSL expert.
Unfortunately I can not see the server-side logs so I can’t observe the full picture.
Question
What can be the reason for this 400 error and how can I progress further (debug/try something else) ? Any tips would be much appreciated.
Nginx — ошибка 400 Bad Request — No required SSL certificate was sent
может быть по нескольким причинам:
1) Браузер отправляет на Nginx неверный запрос, когда размер заголовков запроса больше допустимого предела. Например, большие куки.
Решение — увеличить размер больших заголовков для nginx в секции http <>:
large_client_header_buffers 4 16k;
и перезапустить nginx
2) Проверить в конфиге nginx наличие опций’ssl_client_certificate и ssl_verify_client
ssl_client_certificate /etc/nginx/cloudflare.crt; ssl_verify_client
Закомментировать их и перезапустить nginx.
Авторизация пользователей с помощью SSL сертификата NGINX?
Стоит такая задача: есть сайт site.com на нем установлен ssl сертификат от godaddy , поднят суб домен simple.site.com , вот как раз для суб домена simple.site.com нужно сделать доступ только при наличии ssl сертификата который я генерирую на сервере (Пытался сделать по этой статье, все безуспешно https://habrahabr.ru/post/213741/).
Еще такой момент, много комментариев почитал , наткнулся на то что nginx не может так разруливать , в общем беда какая то второй день пытаюсь сделать такой доступ но при курле выдает ошибку : 400 Bad Request
No required SSL certificate was sent
- Вопрос задан более трёх лет назад
- 1174 просмотра
Типовые ошибки Агента СМЭВ4
Рассмотрим наиболее частые ошибки Агента СМЭВ4, которые могут возникнуть у участника взаимодействия после разворачивания ПО и попытки направить тестовый запрос в ядро ПОДД:
1. В лог-файле присутствует ошибка: «Ошибка вызова функции acquireContext: 0x80090016«, а в Агентах версии 2.15.0 и выше присутствует фраза: «Не удалось получить закрытый ключ » (Рисунок 1).
Рисунок 1 – Лог Агента СМЭВ4 с ошибкой: «Ошибка вызова функции acquireContext: 0x80090016».
Данная ошибка указывает на проблемы с контейнером ключей сертификата. Убедитесь, что в конфигурационном файле application.yml в названии alias (контейнера ключей) не допущено ошибок. Далее следует убедиться, что в директории keys создана директория с именем пользователя /var/opt/cprocsp/keys/>. Если такой директории нет, то необходимо создать её и разместить в ней контейнер с ключами (контейнер с ключами выдаётся удостоверяющим центром вместе с сертификатом).
Если все условия соблюдены, но ошибка сохраняется, проверьте, что Агент запускается под пользователем >. А если Агент был развернут из docker-образа, то убедитесь, что при запуске указан ключ «—user=1000».
2. В логе присутствуют сообщения «No required SSL certificate was sent» (Рисунок 2):
Рисунок 2 – Лог Агента СМЭВ4 с ошибкой: «No required SSL certificate was sent».
1) Для начала необходимо проверить, что используется верный ключ;
2) Убедиться, что указан корректный адрес >;
3) Далее проверить наличие цепочки сертификатов закрытого ключа (проверить наличие цепочки в ОС Windows и в ОС Linux).
Если все 3 пункта выполнены, но ошибка сохраняется, то необходимо убедиться, что сертификат добавлен в ngate (сертификат удостоверяющего центра должен быть добавлен в ядро ПОДД).
3. Если в самом тексте конфигурационного файла присутствуют ошибки, то в логе Агента будет подсвечена строка из конфигурационного файла, где находится фактическая ошибка (Рисунок 3).
Рисунок 3 – подсвечены номера строк из конфигурационного файла, где находится фактическая ошибка.
4. В логе присутствуют сообщения «No such provider: JCP», «class not found exception«.
— убедитесь, что CryptoPro JCS и CryptoPro CSP установлены корректно;
— убедитесь, что для запуска приложения используется тот экземпляр java, который указывался при установке CryptoPro JCP;
— убедиться, что путь к jar файлам СryptoPro JCP присутствует в classpath при запуске java.
5. В логе присутствуют сообщения «unable to find valid certification path to requested target«.
Убедитесь, что файл cp_ca_store содержит нужную цепочку сертификатов.
6. В лог-файле присутствует ошибка: «Ошибка вызова функции getKeyParam: 0x8010002С” (Рисунок 4), а в ряде случаев, при попытке направить тестовый запрос в ядро ПОДД, будет всплывать следующая ошибка: “SignatureExeption: Срок действия закрытого ключа истек. Срок действия закрытого ключа не может превышать 1 год 3 месяца” (Рисунок 5).
Рисунок 4 – Лог Агента СМЭВ4 с ошибкой: «Ошибка вызова функции getKeyParam: 0x8010002С”.
Рисунок 5 – Тестовый запрос Select 1. “Ошибка со сроком действия сертификата“.
Проверьте срок действия сертификата ИС (проверять необходимо в карточке ИС в ЛК УВ). Если он действующий, то нужно убедиться, что в контейнер добавлен нужный сертификат, и есть привязка к закрытому ключу.
Примечание: с помощью тестового запроса “SELECT 1”, можно проверить соединение Агента с Ядром ПОДД. Для того, чтобы отправить тестовый запрос — воспользуйтесь командой с использованием утилиты curl:
| curl -X POST -H «Accept-Version:1» -H «Content-Type: application/json» -d ‘>’ http://:8192/query —silent -m 30 |
7. При попытке направить тестовый запрос всплывает ошибка: “Ошибка при передаче SQL запроса в ядро: IllegalStateExeption: Ошибка при получении токена: HTTP/1.1 400 Bad Request“ (Рисунок 6):
Рисунок 6 – Тестовый запрос Select 1. “Ошибка при передаче SQL запроса в ядро“.
Необходимо перейти в карточку ИС в ЛК УВ и проверить присвоена ли роль ПОДД информационной системе – должна стоять галочка в соответствующем окошке поставщик/потребитель. Далее проверить корректно ли название ИС: если в ЛК УВ мнемоника ИС прописана в верхнем регистре, то и в конфигурационном файле application.yml мнемоника ИС должна быть прописана также. Описание заполнения файла application.yml приведено в статье “Как сформировать конфигурационный файл агента СМЭВ 4”. Также ошибка может свидетельствовать о том, что в ядро ПОДД был добавлен отличный от ЛК УВ сертификат.
Примечание: данная ошибка может указывать на то, что в файле application.yml заполненные данные мнемоник Агента и Витрины данных, начинающиеся с 0, не были обособлены одинарными кавычками ‘ ‘.
8. При отправке запроса в витрину ошибка: «Витрина не зарегистрирована» (Рисунок 7).
Рисунок 7 – Ошибка: «Витрина не зарегистрирована».
Убедиться, что в конфигурационном файле application.yml мнемоника Витрины данных указана в нижнем регистре. Если это не так, следует исправить, сохранить конфигурационный файл, выполнить рестарт Агента и повторно направить запрос.
Примечание: также данная ошибка может возникнуть при одновременно запущенных Агентах-поставщиках, настроенных на одной мнемонике ИС в ЛК УВ.
9. Может наблюдаться остановка контейнера через несколько секунд после запуска, с сообщением в логе: “Ошибка вызова функции acquireContext: 0x8009001a”.
В этом случае необходимо сделать пользователя > владельцем директории /var/opt/cprocsp/keys/>.
Если же Агент был развёрнут через doker-образ, то следует изменить владельца каталога keys и вложенных подкаталогов и файлов на пользователя с >
| chown -R 1000 keys |
после чего повторить выполнение скрипта запуска контейнера.
10. Ошибка при отправке тестового запроса: “Непредвиденная ошибка отправки сведений об агенте в ядро” или “Внутренняя ошибка сервера” (Рисунок 8):
Рисунок 8 – Тестовый запрос Select 1. Ошибка: “Внутренняя ошибка сервера”.
Убедиться, что в конфигурационном файле application.yml прописан корректный alias (в названии контейнера (alias) не должно быть пробелов!).
11. При попытке направить запрос — запрос не проходит, а в логе агента появляются сообщения “java.lang.IllegalStateException: Ошибка вызова функции signHash: 0x65b“ (Рисунок 9):
Рисунок 9 – сообщения “java.lang.IllegalStateException: Ошибка вызова функции signHash: 0x65b“ при попытке направить тестовый запрос.
Используемая trial лицензия CryptoPro истекла. Необходимо приобрести лицензии на CryptoPro CSP и JCP и внести информацию о них в систему, как описано руководстве пользователя по разворачиванию Агента.
После того, как учтутся все необходимые изменения, для корректной работы Агента СМЭВ4 необходимо произвести рестарт.
12. При выполнении запроса всплывает сообщение: «Получен сигнал завершения работы агента«.
| ,»tags»:[«PODD-einfahrt-0146»]> |
Необходимо проверить, не запущен ли ещё один Агент, настроенный на ту же мнемонику ИС, на другой машине.
13. В логе Агента присутствует фраза: “threw exception; nested exception is java.lang.ClassNotFoundException: ru.CryptoPro.reprov.RevCheck“, а при отправке тестового запроса Select 1 всплывает ошибка: “rejected from java.util.concurrent“ (Рисунок 10):
Рисунок 10 – Тестовый запрос Select 1. Ошибка: “rejected from java.util.concurrent“.
Может возникнуть после обновления версии Агента с более поздних версий. Необходимо переустановить агент, используя новый пакет дистрибутивов. Всё необходимое ПО обновлённых версий Агента можно найти в Документах СМЭВ 4 (ПОДД) в разделе «Для внедрения» в ЕСКС.
14. При попытке направить тестовый запрос всплывает ошибка: «IllegalStateException: Ошибка при получении токена: HTTP/1.1 404 Not Found«.
| ,»tags»:[«PODD-einfahrt-0146»]> |
Ошибка указывает на некорректный ip-адрес, указанный в пункте Настройки подключения к Pulsar в строке auth-server-url: конфигурационного файла application.yml.
Примечание: в новых версиях Агента СМЭВ4 для обращения к сервису аутентификации нужно указывать доменное имя!
Необходимо проверить корректность заполненных данных доменного имени и ip-адреса в файле /etc/hosts. Если для подключения используется нестандартный адрес, его необходимо также добавить в файл hosts.
Для Агента, развернутого из doker-образа, нестандартный ip-адрес необходимо передавать параметром (внести соответствующие изменения в файле запуска скрипта run_agent.sh).
15. При попытке направить тестовый запрос во всплывающем сообщении об ошибке присутствует фраза: connection refused.
| :6650 : org.apache.pulsar.shade.io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Connection refused: podd.test.gosuslugi.ru/172.26.155.209:6650″,»context»:»default»> |
Проверить соединение по необходимым адресам для подключения к тестовой и продуктивной среде командой telnet. Если соединение отсутствует, необходимо получить доступ. Подробнее с доступами можно ознакомиться в Регламенте подключения к СМЭВ 4 (п.1.2 «Настройка сетевого взаимодействия с тестовой и продуктивной средами ПОДД СМЭВ»), размещённом на портале ЕСКС, в разделе Документы СМЭВ 4. Также необходимо проверить, чтобы адрес подключения к СМЭВ 4 (ПОДД) был прописан в /etc/hosts (актуально для Агента без docker).