java вопрос о процессе подписания сертификатов

Question

Я запутался в процессе создания действующего сертификата, подписанного ЦС, в Java.
Я знаю, что в Java есть инструмент keytool для создания открытых и закрытых ключей и сертификатов.
Также он поддерживает JKS и PKCS # 12.
Таким образом, можно создать хранилище ключей с парой открытый-закрытый ключ и сертификат, например,
keytool -genkey -keyalg RSA -alias aCert -keystore someKeystore.keystore Это создаст хранилище ключей с сертификатом (самоподписанным).
Пока я понимаю.
Я могу экспортировать сертификат для запроса csr для отправки в CA, например Verisign, без секретного ключа, конечно.
После этой части я потерялся.
ЦС подпишет его, и мне придется повторно импортировать его в мое хранилище ключей. Это заменит исходный сертификат, уже находящийся в хранилище ключей?
Хотя он все еще будет самоподписанным.
Разве эмитентом не должен быть сам ЦС? Но тогда как это возможно? Я просто посылаю только открытый ключ, а не сертификат?
Любая помощь по очистке процесса, пожалуйста?
UPDATE
Является ли центр сертификации, подписывающий сертификат (например, Verisign), также эмитентом? Или он может подписать сертификат, который issuer==subject?
Спасибо

Answer 1

Вы правы до момента создания КСО.Вы будете использовать что-то вроде этого:

$ keytool -certreq -alias myalias -file myalias.csr -keystore keystore

для создания CSR, который содержит:

• ваш открытый ключ (извлеченный из самоподписанного сертификата)
• Отличительное имя (т. Е. Название организации, для которой запрашивается сертификат)

и подписано вашим личным ключом.CA затем генерирует новый сертификат с:

• subject = ваш DN (либо из CSR, либо автоматически сгенерированный с использованием данных, которые вы указали в процессе подачи заявки)
• эмитент = CADN
• открытый ключ = из CSR

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

$ keytool -import -alias myalias -keystore keystore -file myalias.crt

Часто ЦС подписывают ваш новый сертификат с использованием промежуточного сертификата, который в свою очередь подписан доверенным корнем;в этом случае вы должны импортировать промежуточный сертификат перед вашим собственным:

$ keytool -import -trustcacerts -alias intermediate -file intermediate.crt -keystore keystore

Редактировать: этот непонятный раздел из документации keytool удивительно ясен (где говорится о «цепочке» сертификатов)это относится только к промежуточным сертификатам, которые связывают ваш сертификат с корнем):

keytool может создавать и управлять записями «ключа» хранилища ключей, каждый из которых содержит закрытый ключ и связанную цепочку сертификатов.Первый сертификат в цепочке содержит открытый ключ, соответствующий закрытому ключу.

Когда ключи генерируются впервые (см. Подкоманду -genkey), цепочка начинается с одного элемента, самозаверяющего сертификата.Самозаверяющий сертификат - это сертификат, для которого эмитент (подписывающее лицо) совпадает с субъектом (субъектом, открытый ключ которого аутентифицируется сертификатом).Всякий раз, когда подкоманда -genkey вызывается для создания новой пары открытого / закрытого ключа, она также оборачивает открытый ключ в самоподписанный сертификат.

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

Answer 2

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