Какой сертификат следует использовать в SSLContext при использовании самозаверяющего сертификата? Самоподписной сертификат или сертификат CA

Question

Я очень озадачен сертификатом, используемым в SSL на Android. Регулярно следует использовать ca.crt (сертификат CA) для проверки server.crt (сертификат) в клиенте. Тем не менее, кажется, что либо ca.crt и server.crt могут работать при использовании ssl на Android. Это очень странно. Может кто-нибудь объяснить, что происходит?

Заранее спасибо.

Как показано ниже, я могу использовать ca.crt или server.crt для создания client.bks. Оба они могут успешно подключиться к серверу. Кстати, после того, как я перестроил server.crt на стороне сервера с другой информацией, я могу использовать только ca.crt для подключения к серверу.

KeyStore trustKeyStore = KeyStore.getInstance("BKS");
InputStream keyStream = xxxApplication.getInstance().getAssets().open("client.bks");

trustKeyStore.load(keyStream, "".toCharArray());
            TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init(trustKeyStore);
sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(null, trustManagerFactory.getTrustManagers(), null);

---

По-другому, я хочу знать, какSSL в Android проверить сертификат сервера с TrustManager. Давайте назовем сертификат, который я использую для создания trustManager 'client.crt'. Кажется, что приведенный ниже код разрешает сертификаты сервера (как сертификат client.crt, так и сертификат, который может быть проверен client.crt).

Answer 1

По результатам, которые я наблюдаю, я полагаю, что по умолчанию trustManagerFactory в Android будет принимать два типа сертификатов. Один содержит сертификаты, которые мы загружаем в trustManagerFactory. Другой содержит сертификаты, которые могут быть правильно проверены загруженными нами сертификатами.

Таким образом, можно загрузить сертификат сервера, чтобы доверять определенному сертификату, или он может загрузить сертификат, чтобы доверять набору сертификатов, которые могут быть проверены этим сертификатом.

Answer 2

Когда вы находитесь в рукопожатии TLS, каждая сторона может иметь сертификат (со связанным закрытым ключом), который она предоставляет другой стороне для идентификации себя.

Часто имеет значение только сертификат сервера,как в HTTPS, но в целом клиент может также представить сертификат, если его запросит сервер.

В общих чертах обмен происходит так:

• client: hello
• сервер: у меня есть сертификат X
• (если сервер хочет, чтобы клиент представил сертификат) сервер: клиент, пожалуйста, пришлите мне свой сертификат, я распознаю центры сертификации A, B, C, D
• (если сервер запросил сертификат) клиент: вот мой сертификат Y

Что это значит?

Когда сервер запрашивает у клиента свой сертификат, он перечисляет, какие CAон знает о том, что он ведет клиента к выбору соответствующего сертификата (клиент может иметь более одного в своем хранилище доверенных сертификатов, поэтому ему нужно выбрать один - он может отправить только один - кем-тоавтоматически или в конце, попросив человека выбрать один из них)

Это всего лишь руководство, клиент может отправить любой сертификат, который он хочет, подписанный любым ЦС, который ему нравится ... но рискует, что сертификат будетзатем отклоняется сервером.

Таким образом, при настройке клиентской части для создания «контекста SSL» необходимо указать свой сертификат, свой закрытый ключ, связанный с сертификатом, или список сертификатов, называемый «цепочкой». "или" промежуточный ", так как все это без закрытого ключа необходимо будет отправить на сервер и отдельно настроить вашу сторону для распознавания некоторых ЦС как полностью доверенных, чтобы вы могли использовать их для проверки подлинности сертификата сервера.

Цепные / промежуточные из-за того, что сертификаты конечного пользователя / системы редко (никогда?) Подписываются непосредственно сертификатом CA (кроме случаев, когда самоподписанный, конечно, в этом случае конечный сертификат также является сертификатом CA),так что клиенту нужно отправить свой конечный сертификат и всю цепочкуf сертификаты, необходимые для привязки его конечного сертификата к одному из сертификатов CA («корневой» сертификат CA отправлять не нужно). Со всей этой информацией сервер сможет аутентифицировать клиента, используя его сертификат и все промежуточные сертификаты, а также сертификаты CA, которые сервер имеет в своем собственном локальном хранилище доверенных сертификатов.

Если вы настроите свою сторону с«настоящий» CA (публичный или частный), это означает, что вы примете любой сервер (для этой части проверок есть другие проверки, такие как даты, значение подписи, конечно, имена, включенные в сертификат и т. д.),возможность представить сертификат, выданный этим центром сертификации (снова через несколько промежуточных). Если вместо этого вы используете непосредственно самозаверяющий сертификат сервера, это означает, что вы фактически разрешите только этот сертификат, а не кому-либо еще (таким образом, ни один другой сервер, и даже не этот конкретный сервер после изменения его самоподписанного сертификата).

Обратите внимание, что на первом шаге (clientHello) клиент может также указать, о каких CA он знает (см. П. 4.2.4 RFC8446), но я считаю, что это редко.