Я хочу сэкономить на лицензии ОС, упростить обновление списков отзыва сертификатов и иметь более одного экземпляра сертификата на одном сервере.
Для меня это имеет смысл с точки зрения безопасности, потому что у меня есть:
Один центр сертификации, который действует как корневой, которому необходимо публиковать и обновлять списки отзыва сертификатов для серверов политик (следующий маркер)
Есть очень много серверов политик (2-й уровень), которые ограничены ограничениями имени или использованием EKU. Точно так же им тоже нужно публиковать множество CRL и записей AIA.
В настоящее время мы оцениваем потребность в 10 000–50 000 серверов политик. На каждом сервере политики будет храниться список отзыва сертификатов в хранилище BLOB-объектов Azure с выделенным контейнером для каждого сервера для масштабируемости операций ввода-вывода.
На основании вывода certutil -ping (а именно параметра конфигурации) выяснилось, что у меня может быть более одной конфигурации для каждого экземпляра ADCS.
Кроме того, несколько других параметров Certutil (и соответствующего API) позволяют мне указать, к какому «экземпляру» я хочу подключиться.
/// --- NOTE: The ability to specify an individual config seems to indicate multiple PKIs are possible per box:
PS C:\Windows\system32\CertSrv\en-US> certutil -ping -config "a.Issue01.bitclear.us\Secure Issuer 01a-001"
Connecting to a.Issue01.bitclear.us\Secure Issuer 01a-001 ...
Server "Secure Issuer 01a-001" ICertRequest2 interface is alive (0ms)
CertUtil: -ping command completed successfully.
/// --- NOTE "Entry 0" implies that more entries are possible
PS C:\Windows\system32\CertSrv\en-US> certutil -v
Entry 0: (Local)
Name: `Secure Issuer 01a-001'
Organizational Unit: `Email Privacy'
Organization: `Bitclear LLC'
Locality: `'
State: `'
Country/region: `us'
Config: `a.Issue01.bitclear.us\Secure Issuer 01a-001'
Exchange Certificate: `'
Signature Certificate: `a.Issue01.bitclear.us_Secure Issuer 01a-001.crt'
Description: `'
Server: `a.Issue01.bitclear.us'
Authority: `Secure Issuer 01a-001'
Sanitized Name: `Secure Issuer 01a-001'
Short Name: `Secure Issuer 01a-001'
Sanitized Short Name: `Secure Issuer 01a-001'
Flags: `13'
Web Enrollment Servers:
1
4
0
https://a.issue01.bitclear.us/Secure%20Issuer%2001a-001_CES_UsernamePassword/service.svc/CES
0
CertUtil: -dump command completed successfully.
Можно ли разместить более одного PKI на одном хосте ADCS? Как это сделать?
Кроме того: я помню, как обсуждали это, возможно, в прошлом, но я не уверен, было ли это реализовано.
Делать:
Я протестирую эту теорию с помощью специального CertFile и нового имени, когда я запустите команду:
certutil -installcert [-f] [-gmt] [-seconds] [-v] [-config CAMachineName\CAName] [CACertFile]
Возможно, это тоже как-то связано с «Серверы политик» и «Серверы регистрации» что может быть связано с этой командой. Возможность отделить их от основного экземпляра ADCS очень интересна и действительно документирована.
Насколько я понимаю, у вас может быть только один экземпляр ADCS на хост и до 3 центров сертификации в лесу AD. «\ CA Name» больше относится к имени вашего дерева PKI, и его не следует путать с экземплярами типа \ INST1, видимыми в конфигурации MSSQL, о чем, я думаю, вы, возможно, думаете.
Было бы хорошо держать ваши центры сертификации отдельно, потому что, если бы все они были на одном хосте, в случае взлома хоста все CA на хосте скомпрометированы.
Если бы у вас было несколько деревьев PKI в вашем лесу, вы бы увидели несколько записей из certutil.
Существует возможность отделить сервер политики регистрации с помощью сервера регистрации веб-политики - это полезно для сред DMZ, где вам необходимо выдавать сертификаты извне.
Технически невозможно иметь более одной иерархии PKI на одном сервере, и это плохая идея с точки зрения безопасности, как уже упоминалось (единая точка отказа). Роль ADCS связана с идентификатором сервера в AD, так что единственный способ изменить DN иерархии - это удалить роль и начать заново.
Что касается лицензий, я не считаю, что автономный корневой ЦС должен быть чем-то особенным. Технически вы можете сгенерировать ключевой материал на хосте Linux и опубликовать его в AD из выпускающего центра сертификации вашего предприятия, если конечные точки CRL и AIA совпадают.