Назад | Перейти на главную страницу

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

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

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

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

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

Ага, работает нормально; Центр сертификации Windows не боится работать в качестве подчиненного корня, отличного от Windows.

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

Пара вещей, которые можно поиграть с тем, что 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 по умолчанию. Измените это для подписанных запросов (конечно, убедитесь, что этого нет для запросов, которые не должны быть центрами сертификации). Это будет в разделе, настроенном x509_extensions собственность [ca] раздел:

    basicConstraints=CA:TRUE
certificatePolicies=2.5.29.32.0

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

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

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

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

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

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

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

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

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

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

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