Содержание статьи

Сообщение «No required ssl certificate was sent» появляется, когда сервер настроен на обязательную проверку клиентских сертификатов, а браузер или приложение не отправляет нужный файл. Чаще всего это связано с отсутствием корректного клиентского сертификата в хранилище, ошибками в цепочке доверия или неверной конфигурацией SSL-проверки на стороне сервера.
Чтобы убедиться, что проблема не в клиенте, стоит проверить наличие сертификата в «Личном» хранилище и его соответствие требованиям сервера: формат .p12 или .pfx, наличие приватного ключа и корректный срок действия. Если сертификат установлен, но не используется, полезно удалить дубликаты, очистить кэш SSL и перезапустить браузер. В корпоративных средах нередко требуется явное указание сертификата в настройках приложения или импорт корневого удостоверяющего центра.
На серверной стороне ошибка возникает, когда веб-сервер настроен на режим ssl_verify_client on, но список доверенных центров сертификации сформирован неправильно. Проверяется путь к ssl_client_certificate и актуальность цепочки CA. Для Nginx и Apache важно обеспечить корректные права доступа к файлам сертификатов и отсутствие лишних промежуточных звеньев. После исправления конфигурации сервер перезапускается, а клиентское устройство повторно проходит проверку.
Ошибка “No required ssl certificate was sent”: как исправить
Проверьте настройки сервера. На Nginx убедитесь, что параметры ssl_verify_client и ssl_client_certificate заданы корректно. Для обязательной проверки сертификатов должно быть: ssl_verify_client on;, а путь к файлу CA – валидным и читаемым.
Убедитесь, что клиентский сертификат установлен. В браузерах Chrome и Firefox сертификат нужно добавить в хранилище “Личные” или “Your Certificates”. Если используется приложение, проверьте путь к сертификату в конфигурационном файле и его пароль.
Проверьте цепочку доверия. Клиент должен передавать полный набор сертификатов. Если файл сформирован неправильно, сервер отклонит запрос. Пересоберите .p12 с указанием приватного ключа и CA: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile ca.pem -out client.p12.
Сравните домены. CN или SAN в клиентском сертификате должны соответствовать требованиям сервера. Несоответствие часто приводит к отказу даже при наличии корректного файла.
Проверьте уровень протокола. Некоторые сервера требуют TLS 1.2 или выше. Если клиент использует устаревший протокол, запросы будут блокироваться. Обновите настройки транспорта или используемую библиотеку.
Проверьте права доступа. На Linux файлы ключей должны иметь разрешения не выше 600. Иные права могут вызвать отказ в загрузке ключа.
Проверка наличия клиентского сертификата в хранилище браузера
Браузер должен иметь установленный клиентский сертификат с закрытым ключом. Без него сервер отклоняет запрос и выдаёт ошибку «No required SSL certificate was sent». Чтобы убедиться, что сертификат корректно установлен, выполните проверку в конкретном браузере.
-
Chrome / Edge (Chromium)
- Откройте: Настройки → Конфиденциальность и безопасность → Безопасность → Управление сертификатами.
- Перейдите во вкладку «Личные». В списке должен быть сертификат нужного центра выпуска.
- Проверьте: указан ли закрытый ключ, корректен ли срок действия, совпадает ли CN с требуемым.
-
Firefox
- Откройте: Настройки → Конфиденциальность и защита → Сертификаты → Просмотр сертификатов.
- Во вкладке «Ваши сертификаты» ищите нужный файл PKCS#12 (PFX/P12), который вы импортировали.
- Проверьте: присутствует ли отметка о закрытом ключе, нет ли статуса о недоверенном центре сертификации.
-
Safari (macOS)
- Откройте «Связку ключей» → «Локальные элементы» или «login».
- Найдите сертификат: он должен отображаться вместе с закрытым ключом.
- Убедитесь, что доверие настроено правильно и цепочка сертификатов не содержит ошибок.
Если сертификата нет или ключ не прикреплён, импортируйте корректный файл PFX/P12 и повторите проверку. После установки перезапустите браузер, иначе он не подтянет обновлённые данные из хранилища.
Настройка требований к клиентским сертификатам на сервере
Причина ошибки «No required SSL certificate was sent» чаще всего связана с тем, что сервер либо требует обязательный сертификат, либо настроен так, что клиенту не отправляется запрос на его предоставление. Ниже приведены рабочие конфигурации для серверов, где чаще всего возникают подобные ситуации.
Nginx
- Активировать запрос сертификата:
ssl_verify_client on;– обязательный сертификат.ssl_verify_client optional;– сервер запрашивает сертификат, но продолжает работу без него.
- Передать список доверенных CA:
ssl_client_certificate /etc/nginx/ca_bundle.crt;- При необходимости добавить промежуточные CA в один файл.
- Выставить глубину проверки:
ssl_verify_depth 4;
- При использовании SNI убедиться, что параметры заданы внутри правильного
server {}.
Apache

- Активировать проверку сертификата:
SSLVerifyClient require– отказ при отсутствии сертификата.SSLVerifyClient optional– сервер запрашивает, но не блокирует доступ.
- Указать цепочку CA:
SSLCACertificateFile /etc/apache2/ca_chain.crt- При раздельных файлах использовать
SSLCACertificatePath.
- Определить глубину:
SSLVerifyDepth 4
- Проверить, что виртуальный хост с нужным доменом содержит параметры выше, иначе клиент не получит запрос.
HAProxy
- Настроить точку приёма TLS:
bind :443 ssl crt server.pem ca-file ca_chain.crt verify required- Заменить
requiredнаoptionalпри тестировании.
- Добавить полную цепочку CA в
ca-file, иначе клиентский сертификат будет отклонён. - Проверить совместимость версий TLS и наборов шифров с клиентом.
Проверка конфигурации
- Проверить, действительно ли сервер отправляет запрос на клиентский сертификат:
openssl s_client -connect host:443 -showcerts - Проверить сертификат клиента:
openssl x509 -in client.crt -text -noout - Убедиться, что CN или SAN удовлетворяют правилам фильтрации, если такие правила заданы сервером.
- Если используется прокси-схема, проверить, что запрос сертификата выполняется конечным сервером, а не теряется на промежуточном узле.
Корректная привязка сертификата к домену в конфигурации веб-сервера

Файл ключа и сертификат должны соответствовать одному доменному имени. Проверяйте поле CN и список SAN в сертификате: домен, указанный в запросе, обязан присутствовать в этих полях. Если используется wildcard-сертификат, структура вида *.example.com не подходит для доменов второго уровня.
В конфигурации Nginx для каждого домена указывайте отдельный server-блок с параметрами ssl_certificate и ssl_certificate_key. Путь к файлам должен указывать на актуальные версии сертификата и ключа. Для OCSP-степлирования добавляйте ssl_stapling on; и корректный файл цепочки через ssl_trusted_certificate.
В Apache используйте привязку через директивы SSLCertificateFile, SSLCertificateKeyFile и SSLCertificateChainFile внутри виртуального хоста с включённым SSLEngine on. Каждый виртуальный хост должен иметь собственную пару файлов, если домены различаются.
При использовании SNI убедитесь, что серверная версия OpenSSL поддерживает эту функцию и не используется устаревшая схема с одним сертификатом на все домены. SNI позволяет отдавать корректный сертификат для каждого хоста, иначе клиент может получить ошибку о том, что сертификат отсутствует или не подходит.
После изменения конфигурации проверяйте корректность привязки через openssl s_client -connect domain:443 -servername domain. Ошибки «no required ssl certificate was sent» часто возникают, когда сервер неправильно отдаёт цепочку или выбирает неверный сертификат. Проверка покажет, какая цепочка уходит клиенту и совпадает ли доменное имя.
Проверка цепочки доверия и установленных корневых сертификатов
Ошибка No required SSL certificate was sent часто возникает из-за неполной цепочки доверия или отсутствия необходимых корневых сертификатов на клиенте или сервере. Для исправления необходимо выполнить проверку всех компонентов цепочки SSL.
Шаги для проверки цепочки доверия:
- Скачайте сертификат сервера с помощью команды OpenSSL:
openssl s_client -connect example.com:443 -showcerts
Это покажет полный список сертификатов, отправленных сервером.
- Сравните корневой сертификат с тем, что установлен в хранилище доверенных сертификатов клиента:
- Windows: управление сертификатами через mmc → Certificates → Trusted Root Certification Authorities
- Linux: проверка через файлы /etc/ssl/certs или команду
update-ca-certificates - macOS: Keychain Access → System Roots
- Если корневой или промежуточный сертификат отсутствует, добавьте его в хранилище доверенных. На сервере убедитесь, что полный цепочный сертификат загружен вместе с ключом.
- Для тестирования корректности цепочки используйте онлайн-сервисы, например SSL Labs или команду:
openssl verify -CAfile chain.pem server.crt
Ошибки валидации укажут на отсутствующие или некорректные сертификаты.
Регулярная проверка цепочки доверия предотвращает ошибки при установлении SSL-соединений и гарантирует корректное распознавание сертификатов клиентами.
Настройка параметров TLS-рукопожатия и поддерживаемых протоколов
Ошибка No required SSL certificate was sent часто связана с несовпадением настроек TLS-рукопожатия между клиентом и сервером. Для устранения проблемы важно корректно настроить поддерживаемые версии протоколов и наборы шифров.
На сервере необходимо явно указать версии TLS, которые разрешены. Рекомендуется отключить SSL 2.0 и SSL 3.0, а также TLS 1.0 и TLS 1.1 из-за известных уязвимостей. Допустимыми остаются TLS 1.2 и TLS 1.3. В конфигурационных файлах Apache это делается через директиву SSLProtocol, например:
SSLProtocol TLSv1.2 TLSv1.3
Для Nginx настройка поддерживаемых протоколов выглядит так:
ssl_protocols TLSv1.2 TLSv1.3;
Следующий шаг – определение списка разрешённых шифров. Для TLS 1.2 рекомендуется использовать только безопасные наборы, например:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
Для TLS 1.3 шифры задаются автоматически в соответствии с RFC 8446, вручную их указывать обычно не требуется.
Важно включить проверку клиентских сертификатов на сервере. В Apache это делается через директивы SSLVerifyClient require и SSLCACertificateFile. В Nginx необходимо использовать ssl_verify_client on; и указать путь к файлу CA-сертификатов через ssl_client_certificate.
После изменения конфигурации рекомендуется протестировать соединение с помощью openssl s_client, например:
openssl s_client -connect example.com:443 -cert client.crt -key client.key
Это позволит проверить, что TLS-рукопожатие проходит корректно, а сервер принимает клиентский сертификат.
Устранение ошибок при генерации и экспорте клиентского сертификата

Ошибки при создании клиентского сертификата часто связаны с некорректной генерацией ключей или неправильным выбором формата при экспорте. Для корректной работы SSL требуется, чтобы сертификат содержал приватный ключ и был подписан доверенным центром сертификации (CA).
При генерации сертификата в OpenSSL используйте команду:
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr
Здесь `rsa:2048` гарантирует достаточную длину ключа, а флаг `-nodes` предотвращает шифрование ключа паролем, что важно для автоматизированных приложений.
После подписания запроса на сертификат CA необходимо объединить приватный ключ и сертификат в один файл формата PKCS#12 для экспорта в браузер или систему:
openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -name "ClientCert" -CAfile ca.crt -caname "RootCA"
Типичные ошибки при экспорте:
| Ошибка | Причина | Решение |
|---|---|---|
| No private key found | Файл сертификата не содержит приватного ключа | Убедиться, что используете правильный ключ `client.key` при экспорте в PKCS#12 |
| Cannot read CA certificate | Файл CA указан неверно или поврежден | Проверить целостность `ca.crt` и корректность пути |
| Export failed due to unsupported format | Браузер или система не поддерживает указанный формат | Использовать PKCS#12 (`.p12` или `.pfx`) вместо PEM при импорте в Windows или macOS |
Для проверки корректности сгенерированного файла PKCS#12 используйте:
openssl pkcs12 -info -in client.p12
Команда покажет наличие сертификата, приватного ключа и цепочки CA. Если какой-либо компонент отсутствует, повторите генерацию и экспорт с правильными параметрами.
Важно также убедиться, что сертификат и ключ не повреждены, а имя субъекта (`CN`) соответствует требованиям сервера, иначе ошибка `No required ssl certificate was sent` будет повторяться.
Настройка доступа к закрытому ключу и прав пользователей

Для корректной работы SSL-сертификатов серверу необходим доступ к закрытому ключу. Ошибка No required ssl certificate was sent часто возникает из-за отсутствия прав на чтение файла ключа или некорректной настройки пользователей.
На системах Linux права доступа к закрытому ключу должны быть ограничены. Файл ключа должен принадлежать пользователю, под которым работает веб-сервер (например, www-data для Apache или Nginx). Разрешения рекомендуется выставлять как 600:
| Действие | Команда |
|---|---|
| Установить владельца ключа | chown www-data:www-data /etc/ssl/private/server.key |
| Установить права доступа | chmod 600 /etc/ssl/private/server.key |
Для Nginx можно явно указать путь к ключу и сертификату в блоке server:
| Параметр | Пример |
|---|---|
| ssl_certificate | /etc/ssl/certs/server.crt |
| ssl_certificate_key | /etc/ssl/private/server.key |
В системах с SELinux необходимо убедиться, что контекст безопасности разрешает чтение ключа процессом веб-сервера:
| Действие | Команда |
|---|---|
| Проверить контекст | ls -Z /etc/ssl/private/server.key |
| Установить правильный контекст | chcon -t cert_t /etc/ssl/private/server.key |
Проверка доступа может выполняться через запуск сервера от соответствующего пользователя с использованием sudo -u www-data cat /etc/ssl/private/server.key. Если доступ запрещён, ошибка SSL-соединения сохраняется.
Для многопользовательской среды рекомендуется создавать отдельную группу для процессов веб-сервера, добавлять в неё пользователей и давать группе права на чтение ключа. Это минимизирует риски утечки ключа.
Диагностика проблемы с помощью openssl и логов сервера

Для выявления причин ошибки «No required ssl certificate was sent» первым шагом используйте утилиту openssl. Выполните команду:
openssl s_client -connect example.com:443 -cert client.crt -key client.key -state -debug
Она покажет этапы TLS handshake, включая отправку клиентского сертификата. Обратите внимание на строки Certificate request и Client certificate. Если сертификат не отправляется, проверьте правильность пути к файлам и формат сертификата (PEM/DER).
Для проверки цепочки доверия используйте:
openssl verify -CAfile ca_bundle.crt client.crt
Ошибки на этом шаге указывают на несоответствие корневого или промежуточного сертификата, которое блокирует отправку клиентского сертификата сервером.
Параллельно изучите логи сервера. Для Apache это error_log, для Nginx – error.log. Ищите строки с отметками SSL, client certificate или handshake failure. Например:
[ssl:error] [pid 1234] SSL handshake failed: client did not provide certificate
Если лог показывает отсутствие сертификата, проверьте настройки виртуального хоста: директивы SSLVerifyClient require и SSLCACertificateFile для Apache или ssl_client_certificate и ssl_verify_client on для Nginx. Ошибки в этих параметрах напрямую вызывают отказ при handshake.
Вопрос-ответ:
Что означает ошибка «No required SSL certificate was sent» при подключении к сайту?
Эта ошибка появляется, когда сервер запрашивает у клиента SSL-сертификат, но он не был предоставлен или не распознан. Обычно это происходит при попытке доступа к ресурсам с требованием взаимной аутентификации через сертификаты.
Почему браузер не отправляет клиентский сертификат автоматически?
Браузер отправляет сертификат только если он установлен и соответствует запросу сервера. Если сертификат не добавлен в хранилище или не выбран правильно, сервер получает пустой ответ, что вызывает сообщение «No required SSL certificate was sent».
Как проверить, установлен ли у меня клиентский сертификат для конкретного сайта?
В браузере можно открыть настройки безопасности или сертификатов. Там отображается список установленных личных сертификатов. Если нужного сертификата нет или он просрочен, подключение к серверу будет блокировано, и появится ошибка.
Какие действия помогут исправить ошибку на стороне сервера?
На сервере следует убедиться, что настройка TLS требует правильного типа клиентских сертификатов. Проверяют цепочку доверия, соответствие CA и наличие поддержки протоколов. Иногда достаточно добавить или обновить сертификаты в хранилище доверенных на сервере.
Можно ли обойти ошибку без установки клиентского сертификата?
Обойти её напрямую невозможно, так как сервер требует аутентификации по сертификату. Единственный способ получить доступ без ошибки — установить правильный клиентский сертификат, который сервер распознаёт.
