☰

Могут ли службы сертификатов MS быть подчиненными по отношению к CA, созданному с помощью OpenSSL?

tag-icon • tag-icon ssl-certificate windows openssl certificate-authority
Могут ли службы сертификатов MS быть подчиненными по отношению к CA, созданному с помощью OpenSSL?

Я хочу настроить центр сертификации предприятия для своего домена. Чтобы я мог выдавать сертификаты для различных целей. Я хотел бы следовать лучшей практике, имея автономный центр сертификации в качестве корневого, и настроить свой центр сертификации предприятия в качестве подчиненного. Но кажется глупым лицензировать полную копию Windows для этой задачи.

Я надеюсь, что смогу установить какой-нибудь живой дистрибутив на USB-флеш-диск, а затем установить openssl и настроить свой CA на флэш-диске. Когда я буду готов создать корневой ключ/сертификат, я отключу компьютер от сети и больше никогда не буду использовать этот USB-диск на сетевом компьютере.

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

Я попытался поискать в Интернете, иэтотединственное, что я смог найти по этой теме. Но это было до 2008 года, и я не совсем уверен, что этот человек был настолько успешен.

решение1

Да, это работает просто отлично: центр сертификации Windows без колебаний работает в качестве подчиненного по отношению к корневому центру, отличному от Windows.

Протестировано с корневым каталогом OpenSSL и подчиненным каталогом Windows 2008 R2 в режиме Enterprise.

Несколько вещей, которые следует учитывать при работе с тем, что MS CA ожидает в конфигурации OpenSSL:

  • Действительные местоположения AIA и CDP должны применяться к корневому сертификату в разделе, настроенном свойством x509_extensionsраздела [req]для самоподписанного корня. Что-то вроде этого:

    authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
crlDistributionPoints = URI:http://test-rootca.test.local/root.crl

  • Конфигурация OpenSSL, вероятно, не разрешает подчиненные CA по умолчанию. Измените это для подписанных запросов (конечно, убедитесь, что это не касается запросов, которые не должны быть CA). Это будет в разделе, настроенном свойством x509_extensionsраздела [ca]:

    basicConstraints=CA:TRUE
certificatePolicies=2.5.29.32.0

Итак, мы проведем проверку подлинности для тестирования.

Создайте свой корень:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Поэкспериментируйте с вашей конфигурацией и создайте необходимые файлы и каталоги в [ca]разделе вашей конфигурации OpenSSL.

Все готово для запуска работы со стороны Microsoft: создайте подчиненный центр сертификации Windows с ручной подписью.

Загрузите запрос сертификата на сервер OpenSSL. Пока вы там, загрузите корневой сертификат. Импортируйте его в хранилище доверенных корней — компьютера, а не вашего пользователя!

Выдача подчиненного сертификата:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

Если это не сработало, вероятно, у вашего центра сертификации возникла проблема с конфигурацией — новый каталог сертификатов, индексный файл, серийный файл и т. д. Проверьте сообщение об ошибке.

Если он прошел, то все. Если нет, создайте CRL и поместите его в CDP, который вы настроили выше; я просто установил Apache и засунул его в webroot:

openssl ca -gencrl -out /var/www/root.crl

И поместите ваш сертификат в папку AIA, если это еще не сделано:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Загрузите недавно выпущенный подчиненный сертификат и установите его в CA с помощью оснастки Certification Authority MMC. Он будет ворчать о любых проблемах с доверием или проверкой, но у него нет никаких моральных возражений против его принятия.

Конечный результат: работающий центр сертификации Windows без жалоб со стороны оснастки Enterprise PKI, с контрольными OpenSSL Generated Certificateатрибутами.

рабочая-ca

решение2

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

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

Все, о чем вам нужно беспокоиться, это:

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

Не могу сказать, что я это делал, но уверен, что если вы будете следовать документации по генерации CSR из Windows, а затем следовать документации вашего центра сертификации по генерации сертификата .p7k из CSR, то у вас все будет в порядке.

Кстати, я бы рекомендовал вам создать свой CA как виртуальную машину для популярного гипервизора, такого как Hyper-V или VMware, а не как загрузочный диск, убедитесь, что вы храните его в очень надежном месте, где ваш преемник сможет его найти, и периодически запускайте его в автономном режиме, чтобы убедиться, что он работает, или переносите его на новый носитель/технологию. Корневой CA может иметь срок службы 10 или 20 лет...

Связанный контент