no client certificate ca names sent что это значит
Привет, Telnet! И пока. Команда OpenSSL s_client для зашифрованных соединений
Изображение: JanBaby, via Pixabay CC0
Сетевая утилита telnet на слуху. Её в своё время очень активно использовало подавляющее большинство системных администраторов и прочих любителей удалённого администрирования серверов. Утилита позволяет получить доступ к портам удалённого хоста, пройти процедуру авторизации и запускать команды на этой машине.
Но протокол telnet не использует шифрование. В сегодняшних реалиях жертвовать безопасностью — непозволительная роскошь. Однако, есть ряд задач, которые telnet с переменным успехом может выполнять: тестирование сети, проверка портов, а также взаимодействие с IoT устройствами и роутерами.
Казалось бы, утилиту можно легко использовать, как продвинутую версию ping. Сама по себе, команда ping в лучшем случае всего лишь проверяет доступность хоста (иногда эту команду вообще не получится использовать, например, из-за ограничений политики доступа). А вот команда telnet не только проверяет, открыт ли порт, но и может взаимодействовать с сетевыми службами через этот порт. Но со временем мы всё чаще будет сталкиваться с необходимостью использовать зашифрованное соединение, где telnet вновь окажется бессилен.
OpenSSL и команда s_client
Поэтому в большинстве случаев вместо telnet я использую команду s_client из библиотеки OpenSSL. Команда s_client выполняет функции SSL/TLS клиента для подключения к удалённому хосту с различными настройками — ключ шифрования, вид рукопожатия, протокол и так далее. Команда также позволяет проверить, происходит ли возобновление сеанса.
Установка OpenSSL
Если библиотека OpenSSL ещё не установлена на вашей ОС, то её можно установить с помощью менеджера пакетов:
Проверка доступа к порту
Так работает команда telnet для проверки доступа к порту номер 25:
В примере выше мы открыли интерактивный сеанс с неким почтовым сервером, который слушает 25-й порт. Если мы получим к нему доступ, то сможем обмениваться с ним сообщениями. Если порт 25 окажется недоступен, соединение не будет установлено.
Теперь посмотрим, как работает аналогичная команда из OpenSSL:
Как видим, не было отправки данных об SSL-сертификате, поэтому подключение было прервано, открыть сеанс не удалось. Чтобы установить безопасное зашифрованное соединение по протоколу HTTPS, нужно обращаться к специальному порту.
Открываем интерактивный сеанс с зашифрованным подключением
В этом случае браузеры и веб-серверы взаимодействуют таким образом, что трафик, направленный на порт 80, фактически перенаправляется на порт 443, зарезервированный для HTTPS-трафика. Зная это, вы можете с любой веб-службой, которая слушает порт 443.
Нам удалось открыть интерактивный сеанс. Пока он не закрылся, мы можем отправлять на сервер HTTP-сообщения:
Дважды нажмём клавишу Return (для MacOS) или ENTER (для Windows), и получим от сервера ответ в виде example.com/index.html:
Почтовый сервер
Команду s_client можно использовать для тестирования зашифрованного соединения с почтовым сервером. Чтобы это работало, нам понадобится имя пользователя и пароль (в моём случае — для тестового пользователя), закодированные в Base64.
Закодировать их можно, например, так:
Если всё пройдёт успешно, можно переходить к следующему шагу — подключение к почтовому серверу через SSL. Обычно используется порт 587:
Я ввёл адрес почты admin@example.com, на который я ожидаю получить тестовое сообщение от почтового сервера.
Неоправданный риск
Кто-то всё ещё использует telnet, но это уже не тот незаменимый инструмент, которым он когда-то был. Теперь во многих системах он классифицирован как «устаревший» пакет. Некоторые системные администраторы недоумевают, почему он исключён из установки по умолчанию. Telnet постепенно теряет актуальность. Это объективный процесс.
Сетевая безопасность жизненно необходима для большинства систем, поэтому стоит разобраться с соответствующими инструментами. Важно, что они способны работать с защищёнными подключениями. Так что во время тестирования или устранения неполадок не придётся отключать защиту системы и рисковать безопасностью.
Облачные серверы от Маклауд быстрые и безопасные.
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
Background
I am stuck in a finger-pointing match with a service provider with an API protected by SSL server and client certificates.
A sample (failed) request
My reading of the SSL3 alert read:fatal:unknown CA error is that the server does not recognize the issuer of the certificate I am (in fact) providing. However, the provider «assures» me that the CA certificates are loaded properly and I have been unable to convince them otherwise.
Question
So, putting other (extensive) troubleshooting steps aside, what I’d really like to know is:
Is there some output available from openssl s_client that conclusively shows that a client certificate wasn’t just requested by the server, but in fact was transmitted to the server during the SSL handshake?
2 Answers 2
First as a baseline, try running
You’ll get a ton of output, but the lines we are interested in look like this:
What’s happening here:
This is only important for helping you find your place in the output.
So in other words: s_client finished reading data sent from the server, and sent 12 bytes to the server as (what I assume is) a «no client certificate» message.
your output between the «read server done» line and the «write client certificate» line will be much longer, representing the binary form of your client certificate:
The 1576 bytes is an excellent indication on its own that the cert was transmitted, but on top of that, the right-hand column will show parts of the certificate that are human-readable: You should be able to recognize the CN and issuer strings of your cert in there.
I know this is an old question but it does not yet appear to have an answer. I’ve duplicated this situation, but I’m writing the server app, so I’ve been able to establish what happens on the server side as well. The client sends the certificate when the server asks for it and if it has a reference to a real certificate in the s_client command line. My server application is set up to ask for a client certificate and to fail if one is not presented. Here is the command line I issue:
When I leave out the «-cert client.pem» part of the command the handshake fails on the server side and the s_client command fails with an error reported. I still get the report «No client certificate CA names sent» but I think that has been answered here above.
The short answer then is that the server determines whether a certificate will be sent by the client under normal operating conditions (s_client is not normal) and the failure is due to the server not recognizing the CA in the certificate presented. I’m not familiar with many situations in which two-way authentication is done although it is required for my project.
You are clearly sending a certificate. The server is clearly rejecting it.
The missing information here is the exact manner in which the certs were created and the way in which the provider loaded the cert, but that is probably all wrapped up by now.
Как локально проверить SSL-сертификат
Проверьте локально сохраненный сертификат SSL, используя основные утилиты, такие как openssl и curl.
Эти знания особенно полезны, когда вы хотите подготовить сертификат SSL для балансировщика нагрузки.
Самоподписанный сертификат SSL
Это простейший возможный пример, который предназначен для сбоев, поскольку нет способа проверить какой-либо случайный самаподписанный сертификат SSL.
Выполните простую программу сервера SSL / TLS, используя самоподписанный сертификат SSL и его закрытый ключ.
Выполните простую клиентскую программу SSL / TLS, чтобы проверить этот сертификат.
Проверьте код возврата – вы не можете использовать этот сертификат, не отключив проверку SSL-сертификата.
Все как и должно быть.
Квалифицированный сертификат
Выполните простую программу сервера SSL / TLS, используя сертификат SSL, его закрытый ключ и промежуточные сертификаты.
Выполните простую клиентскую программу SSL / TLS, чтобы проверить этот сертификат.
Проверьте код возврата – вы можете безопасно использовать этот сертификат.
Используйте подробный вывод для дальнейшей проверки всего процесса.
Пакет сертификатов HAproxy
После проверки сертификата необходимо создать комплект сертификатов domain.pem, который включает сертификат domain.crt, промежуточные сертификаты domain.intermediate.crt и закрытый ключ domain.key.
Именно в таком порядке.
Там больше ничего нет.
Дополнительные примечания
Вы можете использовать веб-браузер вместо curl для проверки локально сохраненного сертификата, но это не очень удобно.
Я отключил эфемерные комплекты алгоритмов DH, но вы можете указать файл параметров DH для использования.
Вы можете использовать openssl s_server для обслуживания файлов по сети, но это просто еще один лакомый кусочек.
Проверьте код возврата (он отличается от кода выхода), так как он четко покажет, что с предоставленными промежуточными сертификатами что-то не так.
Код возврата не является кодом выхода.
Коды возврата описаны на странице руководства verify.
«No server certificate CA names sent» message is confusing #9080
Comments
p-mongo commented Jun 4, 2019
I ran openssl server as follows:
I then attempted to connect to this server from my client. The server produced the following output in its terminal:
This issue is with respect to No server certificate CA names sent message. What does it mean? Searching the internet for this message seems to yield as a general description of what happened, «something related to openssl was not correctly configured».
The text was updated successfully, but these errors were encountered:
mattcaswell commented Jun 5, 2019
It was introduced as part of #3015 and is related to TLSv1.3 support. #3015 adds the ability for a client to send a list of acceptable CA names to the server. It’s explained in more details here:
That document actually actively discourages a client setting a list of acceptable CA names «in most cases», so it would actually be unusual to see anything other than this message.
The extension that this relates to is available in TLSv1.2, but is used for a server to tell a client which CA names are acceptable in any client certificate if client auth is used. The same code for printing this message is also used on the client side (and existed prior to OpenSSL 1.1.1) but there the message would be «No client certificate CA names sent».
I’d be tempted to suppress this message on the server side when the list is empty, since almost all of the time it would be. Could be a good first issue for someone to tackle.
Криво установленный сертификат HTTPS от 22 февраля 2016 #159
Comments
winnehr commented Feb 28, 2016
Симптомы:
error:0906D066:PEM routines:PEM_read_bio:bad end line
скорее всего цепочка сертификатов склеена без разрыва строк, или нет перевода строки после последнего сертификата в цепочке.
The text was updated successfully, but these errors were encountered:
maizy commented Feb 29, 2016
Действительно, был поломанный сертификат. Некоторый http клиенты на него ругались.
Исправили. Проверьте, пожалуйста, работает ли у вас.
winnehr commented Feb 29, 2016
Пока проблема не исправилась, можно проверить командой curl из командной строки дебиана
maizy commented Feb 29, 2016
Возможно у вас отсутствует какой-то из промежуточных сертификатов в локальном CA хранилище.
У меня нет под рукой debian, но на Ubuntu 12.04/14.04 с последней версией пакета ca-certificates всё работает.
ssl верификаторы тоже репортят успешную проверку
https://www.ssllabs.com/ssltest/analyze.html?d=api.hh.ru
https://www.sslshopper.com/ssl-checker.html#hostname=api.hh.ru
winnehr commented Mar 1, 2016
тот же ssllabs предупреждает Certificates provided 3 (3482 bytes) Chain issues: Contains anchor
возможно с этим связано, у нас так не заработало, до 22 февраля всё нормально было.
Если бы проблема была в неустановленном сертификате, то ругалось бы на самоподписанный или недоверенный сертификат. что-то с формированием. может не тот сертификат в цепочке?
maizy commented Mar 1, 2016
Я к сожалению не могу получить напрямую доступ к сертфикату, им занимается наша служба эксплуатации. Вчера какие-то из проблем пофиксили.
Напишите, пожалуйста, версию debain, и пакетов:
я в таком случае смогу на своей стороне собрать похожее на ваше окружение и повторить проблему.
maizy commented Mar 1, 2016
«Contains anchor» для сертификата, насколько я понимаю, означает, что в цепочке SSL сертификатов присутсвует root сертификат, что по RFC не обязательно, но возможно.
maizy commented Mar 1, 2016
Ещё, если не сложно, приложите вывод команды
maizy commented Mar 1, 2016
Я проверил на debian wheezy в таком окружении работает успешно: