Подтвердить что ты не робот

Когда устанавливать хранилище ключей и когда устанавливать только сертификат, завернутый в хранилище ключей

У меня есть файл PKCS # 12, который я рассматривал как файл хранилища ключей, так как он содержит одну ключевую запись и одна запись сертификата.

В Android я вижу людей программным способом установить keystore следующим образом (код из блог разработчиков Android):

byte[] keystore = . . (read from a PKCS#12 keystore)

Intent installIntent = KeyChain.createInstallIntent();
installIntent.putExtra(KeyChain.EXTRA_PKCS12, keystore);
startActivityForResult(installIntent, INSTALL_KEYSTORE_CODE);

Я также вижу, что люди программно устанавливают только сертификат, завернутый внутри хранилища ключей:

Intent intent = KeyChain.createInstallIntent();
intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert);
startActivity(intent);

Кроме того, я также вижу, что люди устанавливают хранилище ключей и сертификат, завернутый в хранилище ключей. Например, эта статья показывает нам, как сначала установить хранилище ключей, а затем программно установить сертификат, завернутый в хранилище ключей.

Я действительно запутался в том, когда мне нужно установить keystore и когда мне нужно установить сертификат (завернутый в хранилище ключей)? И когда я должен установить оба? Может ли кто-нибудь объяснить мне это?

Например, мой файл PKCS # 12 хранилища ключей (mycert.p12) содержит пару ключей/сертификатов, он используется для подключения к VPN-серверу. Когда мой клиент android установит как хранилище ключей, так и сертификат, завернутый в хранилище ключей? Когда клиент должен установить только сертификат, завернутый в хранилище ключей? Каковы различия? Я совершенно смущен этим.

4b9b3361

ОТВЕТЫ

Ответ 1

У меня есть файл PKCS # 12, который я рассматривал как файл хранилища ключей, так как он содержит одну ключевую запись и одну запись сертификата.

Правильно.

В Android я вижу, как люди программно устанавливают keystore следующим образом...

Это делается, когда у вас есть хранилище ключей, т.е. пара ключей и сертификат.

Я также вижу, что люди программно устанавливают только сертификат, завернутый в хранилище ключей

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

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

Конечная нормативная ссылка для всего этого материала Рекомендация МСЭ X.509.

Наконец, некоторые заметки о некачественных блогах, которые вы связали.

От Объединение доступа к хранилищу ключей в ICS:

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

Это уже неверно.

  • Для аутентификации веб-сервера вам ничего не нужно, если у него есть сертификат с сертификатом CA. Если у него есть самозаверяющий сертификат, вам нужно будет импортировать его в свою сеть доверия.

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

От Использование API ключей ключей ICS:

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

Полная ерунда. У нас уже есть закрытый ключ, открытый ключ и сертификат. Они уже пригодны для использования. Создание подписи и проверка ее локально - всего лишь полная трата времени.

Установка сертификата ЦС не очень отличается от установки Файл PKCS # 12: вы загружаете сертификат в массив байтов и передаете его как в дополнение к намерению установки.

Разница заключается в том, что вы используете KeyChain.EXTRA_CERTIFICATE в случае сертификата CA и KeyChain.EXTRA_PKCS12 в кейфовом случае.

Ответ 2

Поскольку никто еще не ответил на вас, я надеюсь, что смогу хотя бы прояснить некоторые моменты из статьи блога, с которой вы связались.

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

Вот два основных варианта использования здесь:

  • Если вы проверяете подлинность с помощью сертификата клиента (который подтверждает сервер, что вы являетесь авторизованным клиентом), вы должны установить сертификат.
  • Если вы пытаетесь проверить идентификатор сервера, вам необходимо проверить сертификат сервера. В этом случае вам нужно установить хранилище ключей (возможно, цепочку, если вы не используете самозаверяющие сертификаты). Закрытый ключ в хранилище ключей будет использоваться для проверки сертификата сервера.

Этот второй бит кода, который у вас есть в вашем вопросе, был предназначен для создания цепочки сертификатов (когда вы НЕ используете самоподписанные сертификаты):

Сначала мы получаем секретный ключ и цепочку сертификатов, используя ключевой псевдоним а затем создать и проверить подпись, чтобы проверить, действительно ли ключ годные к употреблению. Поскольку мы используем самозаверяющий сертификат, состоит из одной записи, но для сертификата, подписанного CA, вы необходимо будет найти фактический сертификат конечного объекта в возвращенном массив.

Установка сертификата ЦС не очень отличается от установки Файл PKCS # 12: вы загружаете сертификат в массив байтов и передаете его как в дополнение к намерению установки.

Intent intent = KeyChain.createInstallIntent();
intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert);
startActivity(intent);

Надеюсь, это объяснение поможет!:)

Ответ 3

В отношении андроида или любого другого "клиента", то есть приложения, выполняется следующее:

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

Если сертификат сервера уже подписан доверенным центром сертификации (подразумевая, что сертификат уже присутствует в хранилище java-runtime-truststore, который обычно можно найти в $JAVA_HOME/jre/lib/security/cacerts), тогда этот шаг не требуется, если не настроен SSLContext (что также означает, что используется TrustManager).

Например, текущий текущий сертификат SO подписан DigiCert, идентифицированный SHA1-Thumbprint: 5F: B7: EE: 06: 33: E2: 59: DB: AD: 0C: 4C: 9A: E6: D3: 8F: 1A: 61: C7: DC: 25 и, вероятно, будет присутствовать в доверительном магазине "cacerts" под псевдонимом "digicerthighassuranceevrootca". Если java-клиент должен был выполнить запрос /fooobar.com/..., то по умолчанию для связи не было бы никакого определенного хранилища ключей или доверенного хранилища.

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

Это также необходимо, если сервер ожидает, что клиент представит свой собственный сертификат для аутентификации как часть двустороннего ssl-рукопожатия. Из того, что я встретил, это не часто.

Ссылки:

Двусторонний SSL

Собственный журнал Keystore и сообщение доверия