Можно ли использовать какой-либо сертификат SSL для проверки подлинности сертификата клиента?
Я пытаюсь подключиться к стороннему API, для которого включена настройка взаимной аутентификации TLS. Поэтому я должен установить свои клиентские сертификаты в хранилище ключей и отправить его в процессе рукопожатия TLS.
Для этого процесса я сейчас использую SSL с положительным сертификатом в качестве клиентского сертификата. Когда я делаю TLS-вызовы, сервер Evnthough запрашивает сертификат, а Клиент не отправляет его. И когда я проверял SChannel Log, я вижу предупреждение, подобное этому
Удаленный сервер запросил аутентификацию клиента TLS, но не удалось найти подходящий сертификат клиента. Будет предпринята попытка анонимного подключения. Этот запрос на соединение TLS может быть успешным или неуспешным, в зависимости от настроек политики сервера.
Так что я сомневаюсь в следующем: я использую правильный тип сертификата X509 для аутентификации на стороне клиента? Нужно ли использовать какой-либо другой конкретный тип? Поскольку мой текущий сертификат не получает отправку.
1 ответ
Это зависит. Сертификаты X.509v3 обычно поставляются с полем расширения "Расширенное использование ключа", которое содержит список разрешенных вариантов использования (EKU).
Обычные сертификаты веб- сервера содержат использование "TLS Server Authentication" (иногда отображается как "TLS Web Server", но на самом деле оно вообще не относится к Web).
Чтобы действовать в качестве клиента, вам необходим сертификат с "Аутентификацией клиента TLS" (который часто отображается как "Веб-клиент TLS", несмотря на то, что в нем нет ничего специфичного для сети).
Обычные SSL-сертификаты "веб-сервера" довольно часто содержат оба варианта использования - например, я смотрю сертификаты, выданные Let's Encrypt и DigiCert, и все они содержат оба варианта, поэтому могут использоваться для клиентской / взаимной аутентификации.,
Однако возможно, что в некоторых других центрах сертификации, особенно в центрах сертификации частных организаций, большинство сертификатов имеют одно или другое использование, но редко оба.
Например, OpenVPN раньше строго требовал "только TLS-клиента" (а не "хотя бы TLS-клиента", как это делают другие программы), поэтому его easy-rsa скрипт выдает только серверные и клиентские сертификаты, но не смешанный вид.
Поэтому вы должны проверить свои сертификаты и убедиться, что они содержат требуемый EKU. Практически любой инструмент сертификации будет делать эту работу - например, диалоговое окно свойств сертификата в Windows покажет это в "Расширениях V3", как и веб-браузеры, openssl x509, certtool, certutil, так далее.
Также стоит помнить, если вы используете свой собственный внутренний CA: если вы используете промежуточный сертификат CA, обратите на него внимание. Промежуточные звенья не обязательно должны иметь расширение EKU, но если они есть, то все сертификаты, выпущенные этим промежуточным звеном, ограничиваются им. (Если вы получаете сертификаты на коммерческой основе, не нужно беспокоиться об этом.)
Кроме того, сертификат будет иметь основное поле "Использование ключа", которое содержит некоторые очень общие ограничения: например, "Цифровая подпись" означает, что сертификату разрешено подписывать данные (и, следовательно, допускается рукопожатие EDH/EECDH в TLS); "Соглашение о ключах", по-видимому, предназначено для статического DH/ECDH; "Ключ шифрования" позволяет рукопожатия статического RSA.
Официальная документация X.509v3 очень запутана в том, что нужно использовать, когда... Коммерческие ЦС обычно правильно понимают это поле. Но для частных ЦС это стоит перепроверить.