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

В сертификате клиента ADCS отсутствует закрытый ключ

Я настроил ADCS для установки сертификатов пользователей и компьютеров через GPO. С этими сертификатами я могу выполнять аутентификацию EAP-TLS с машин на сервер Clearpass RADIUS. Это хорошая вещь.

Но я пытаюсь заставить пользователей загружать пользовательские сертификаты для компьютеров, не относящихся к домену, с http: /// certsrv. Они могут загрузить сертификат, но он будет помещен не в хранилище «Персональных» сертификатов на клиентском компьютере, а в хранилище «Пользовательский объект Active Directory». Аутентификация EAP-TLS не работает. При дальнейшем исследовании выясняется, что сертификат не имеет загруженного с ним закрытого ключа. У сертификатов, установленных через GPO, есть закрытый ключ. Без закрытого ключа на компьютере EAP-TLS всегда не работает.

Как заставить ADCS разрешить загрузку закрытого ключа через веб-интерфейс? В шаблоне сертификата «Пользователь» установлен флажок, позволяющий это сделать. Я даже создал новый шаблон сертификата и убедился, что включена опция, разрешающая загрузку закрытого ключа.

Идеи?

Спасибо!

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

При использовании ADCS Web Enrollment для компьютеров, не подключенных к домену, вам необходимо создать запрос сертификата вручную, либо с помощью certreq.exe (входит в состав Windows), либо OpenSSL.

Когда вы создаете запрос сертификата с certreq.exe, закрытый ключ создается на клиентском компьютере и хранится локально на клиентском компьютере. У CA никогда не было вашего закрытого ключа. (Архивирование ключей ЦС предприятия здесь не рассматривается.) ЦС просто подписывает ваш запрос на сертификат. Когда вы затем отправляете подписанный запрос сертификата обратно своему клиенту и импортируете его, он затем «связывается» с закрытым ключом.

Это все руководство. Автоматизация является преимуществом клиентов Active Directory, управляемых доменом, и Enterprise PKI. Но вы указали неприсоединение к домену.

(PS, я думаю, вы могли бы написать сценарий для автоматизации требуемых команд certreq и certutil, но у меня нет этого сценария. Может быть, что-то вроде этот.)

Изменить: последнее замечание, вы можете попробовать настроить архивирование ключей в своем ЦС, а затем установить RequestType = CMC и PrivateKeyArchive = True в запросе сертификата, я честно не знаю, будет ли это работать с машиной, не присоединенной к домену, но теоретически это возможно, потому что вы можете безопасно передать свой закрытый ключ от клиента в ЦС с помощью сертификата ЦС. (Хотя вы можете возразить, что хранить закрытый ключ в нескольких местах в принципе небезопасно.)

Но я никогда не тестировал это и не могу найти документально.

(Не то чтобы вам нужен Key Archival для реализации базовой процедуры certreq, которую я описал выше; я проделывал эту часть сотни раз и знаю, что это работает.)