Я пытаюсь настроить сценарий для создания сертификатов SSL для использования с IIS. Я пытаюсь заставить работать сертификаты, подписанные самоподписанным сертификатом CA. Я на 99% там, но что-то не так. Это для использования с сертификатами SSL MSExchange. Я хочу иметь долговечные самоподписанные сертификаты и корневой сертификат, который я могу установить на такие устройства, как смартфоны, что позволит мне доверять другим сертификатам, которые я подписал с ним, например сертификатам SSL.
Вот что я делаю:
/// create a private root cert
openssl genrsa -des3 -out work\Private-CA.key 2048
openssl req -new -x509 -days 3650
-key work\Private-CA.key
-out work\Public-CA.CRT
/// Create an SSL cert request
openssl genrsa -des3 -out work\Certificate-Request.key 2048
openssl req -new
-key work\Certificate-Request.key
-out work\SigningRequest.csr
/// Sign the request with the root cert
openssl x509 -req -days 3650 -extensions v3_req
-in work\SigningRequest.csr
-CA work\Public-CA.CRT
-CAkey work\Private-CA.key
-CAcreateserial
-out work\SSL-Cert-signed-by-Public-CA.CRT
Первые 4 команды кажутся нормальными. Последняя команда создает сертификат с нужными мне атрибутами.
Я импортирую Public-CA.CRT в Машинное хранилище как доверенный корневой сертификат. Затем я использую командлет exchange import-exchangecertifiate, чтобы попытаться импортировать SSL-Cert-signed-by-Public-CA.CRT. Это не срабатывает с сообщением о том, что сертификат не является доверенным.
Вроде бы не подписывается. Если я импортирую сертификат ssl в личный магазин компьютера, это также означает, что у него нет маршрута сертификации.
Может ли кто-нибудь, кто лучше разбирается в этом, увидеть, что мне не хватает?
В качестве отступления: есть ли способ из командной строки спросить openssl, подписан ли сертификат X сертификатом Y? Это должно работать, но не работает:
openssl verify -cafile Public-CA.CRT SSL-Cert-signed-by-Public-CA.CRT
usage: verify [-verbose] [-CApath path] [-CAfile file] [-purpose purpose] [-crl_check] [-engine e] cert1 cert2 ...
recognized usages:
sslclient SSL client
sslserver SSL server
nssslserver Netscape SSL server
smimesign S/MIME signing
smimeencrypt S/MIME encryption
crlsign CRL signing
any Any Purpose
ocsphelper OCSP helper
добавление -purpose не улучшает ситуацию.
Вы должны импортировать открытый ключ CA, а не закрытый ключ, в хранилище доверенных корней - закрытый ключ никогда не должен покидать ваш CA.
Доверяйте открытому ключу ЦС, и тогда у Exchange не должно возникнуть проблем с импортом вновь сгенерированного сертификата ... хотя, похоже, вы даете ему только открытый ключ, а не Certificate-Request.key
файл?
Я бы рекомендовал сгенерировать запрос на подпись сертификата из инструментов Microsoft на сервере Exchange, а затем подписать его в ЦС - или, если вы этого не сделаете, по крайней мере, упакуйте пару ключа и сертификата в файл PKCS12 для передачи в Exchange. cmdlet, поскольку похоже, что это формат, который он хочет использовать для любого импорта закрытого ключа:
openssl pkcs12 -export -out work\Exchange-Cert-Package.pfx -in work\SSL-Cert-signed-by-Public-CA.CRT -inkey work\Certificate-Request.key