Какой элемент pki не существует в службе сертификатов Active Directory сервера Windows

Обновлено: 21.11.2024

Windows Server 2012 R2

На этой странице содержится список известных исправлений, исправлений и известных проблем Microsoft, связанных с ролью служб сертификации Active Directory. Страница будет обновляться по мере выпуска новых выпусков Microsoft, а также при выявлении новых проблем. Вы можете подписаться на страницу, чтобы получать автоматические оповещения при изменении содержимого. Если у вас есть какие-либо отзывы или комментарии или вы заметили, что чего-то не хватает, сообщите нам об этом.

Журнал изменений — последнее обновление 23 августа 2017 г.

23 августа 2017 г. — обновлено описание исправления для 2008 R2 и 2012 R2 для ошибки OCSP (2950080) с длинными именами ЦС. В статье Microsoft неправильно описана проблема с именем хоста, проблема заключается в имени ЦС.

7 ноября 2016 г. – магический номер OCSP перемещен в раздел проблем клиента

6 июня 2016 г. – Добавлена ошибка 5298357, связанная с недопустимым кодированием ASN.1 расширений политик выдачи сертификатов

Исправления

- Microsoft Online Responder не может обслужить запрос OCSP, содержащий несколько сертификатов.

- Служба сетевого ответчика не возвращает детерминированное GOOD для всех сертификатов, не включенных в CRL.

- Большой запрос URI в прокси веб-приложения завершается сбоем в Windows Server 2012 R2.

- Заявление эмитента, указанное в файле Capolicy.inf, не включено в выданный сертификат. *Хотя эта статья указана как Windows Server 2000, она применима ко всем более новым операционным системам. Эта проблема актуальна только для сертификатов End Entity, использующих шаблоны сертификатов, где информация о субъекте создается из AD.

- NDES перестает работать после перезапуска сервера ЦС на базе Windows Server 2012 R2.

Известные проблемы

Изоляция сеанса 0 интерактивных служб и HSM CSP/KSP.
Начиная с Windows Server 2012 службы, работающие в другом контексте, чем пользователь, выполнивший вход на рабочий стол, не могут взаимодействовать. Это связано с изоляцией сеанса 0, встроенной в ядро. Это не позволит многим CSP/KSP модуля аппаратной безопасности взаимодействовать с пользователями. Это будет преобладать, когда необходимо использовать наборы карт для аутентификации перед доступом к ключам CA. Это известная проблема в мире безопасности Thales nCipher — по крайней мере, до версии S/W 11.70. Компания Thales знает об этой проблеме и работает над ее исправлением. Подробнее об изоляции сеанса 0 читайте в статье об интерактивных службах.

Исправление: измените HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\NoInteractiveServices на значение 0 и перезагрузите компьютер.
Обновление: компания Thales выпустила Security World версии 12.1, в которой изменена модель драйвера, и этот раздел реестра больше не влияет на нее.

Клиенты Windows XP не могут по умолчанию зарегистрироваться в ЦС Windows Server 2012 R2.
Когда запрос сертификата получен центром сертификации (ЦС), шифрование запроса может быть принудительно применено ЦС через RPC_C_AUTHN_LEVEL_PKT , как описано в статье MSDN Константы уровня аутентификации. В Windows Server 2008 R2 и более ранних версиях этот параметр по умолчанию не включен в ЦС. В ЦС Windows Server 2012 или Windows Server 2012 R2 этот расширенный параметр безопасности включен по умолчанию. Дополнительные сведения доступны в разделе Повышенная безопасность, включенная по умолчанию для службы роли ЦС.
Исправлено: в ЦС запустите certutil -setreg CAInterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST и перезапустите службы сертификации.

Вы не можете подать заявку на сертификат протокола статуса онлайн-сертификата (CERT_E_INVALID_POLICY).
Windows Server 2008–2012 R2 может не иметь возможности подать заявку на сертификат OCSP. Чаще всего это вызвано ЦС в иерархии, который указал определенные OID, но не включает в свой EKU специальный OID OCSP (1.3.6.1.5.5.7.3.9). Для получения дополнительной информации см. https://mskb.pkisolutions.com/kb/2962991.
Исправлено: при указании конкретных OID для CA EKU необходимо включать OID OCSP (1.3.6.1.5.5.7.3.9). При использовании конфигурации по умолчанию «Все политики приложений» никаких действий не требуется.

Настройте гостевую ВМ с отключенным или отключенным сетевым адаптером. После завершения установки вы можете удалить сетевой адаптер из гостевой ВМ.
Вы также можете указать расположение базы данных ЦС, даже если это расположение по умолчанию, добавив аргумент –DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog") к команде Powershell
Для выполнения установки используйте графический интерфейс диспетчера серверов.

Ошибка при установке ADCS на компьютерах с именами узлов длиной более 15 символов.
Состояние ошибки может возникнуть, если имена компьютеров имеют длину 16 или более символов, а сетевой адаптер не подключен (например, автономный центр сертификации). ). Хотя ОС укажет, что возможно разрешение имен Netbios, это не препятствует использованию длинных имен. При установке роли ADCS в Server 2012/R2 установка завершится успешно, второй шаг по настройке роли приведет к сбою диспетчера серверов. На данный момент нельзя удалить ADCS и, следовательно, имя компьютера нельзя сократить до 15 или менее символов.
Исправление. Исправление этой проблемы заключается в использовании имен хостов, содержащих не более 15 символов. Если вы уже установили ADCS и столкнулись с этой проблемой, временно подключите сетевой адаптер, чтобы разрешить удаление ADCS, а затем измените имя компьютера.

Обновление сертификата корневого ЦС и изменение срока действия с помощью файла CAPolicy.inf завершается ошибкой
При обновлении сертификата корневого ЦС срок действия нового сертификата эквивалентен сроку действия обновляемого сертификата (поскольку сервер 2008). Если требуется альтернативный период действия, параметры RenewalValidityPeriod и RenewalValidityPeriodUnits можно поместить в файл capolicy.inf, чтобы отразить другое значение для нового сертификата. Однако ADCS будет использовать это значение только в том случае, если оно равно или превышает значение обновляемого сертификата. Вы не можете настроить ADCS для обновления корневого сертификата ЦС на срок жизни, меньший, чем у предыдущего сертификата.
Исправлено: используйте certutil –sign для подписи и указания желаемого срока действия сертификата, добавьте измененный сертификат в личное хранилище компьютера ЦС и свяжите его с закрытым ключом, измените реестр ЦС ( CACertHash ) и перезапустите ЦС. .

Инструмент командной строки Windows Server sConfig позволяет изменять членство в домене и имя компьютера даже при установленном центре сертификации ADCS.
При установке ролей сервера ADCS на сервере размещаются элементы управления, чтобы предотвратить изменения членства в домене и изменения имени хоста. . Чтобы внести изменения в любой из них, сначала необходимо установить ADCS. Такое поведение возникает при внесении изменений в апплет Панель управления\Система. Однако при использовании sConfig (Server Core 2008 R2 или любой версии Windows Server 2012+) нет средств для предотвращения этих изменений. Изменение членства в домене или имени компьютера может нарушить функциональность ЦС предприятия и привести к неподдерживаемой конфигурации.
Исправлено: удалите функции роли ADCS перед использованием sConfig для внесения изменений в членство в домене или имя хоста компьютера. Кроме того, при использовании версии Windows Server с графическим интерфейсом используйте апплет Панель управления\Система.

Ошибка 5298357 — Неверное кодирование ASN.1 расширений политики выдачи сертификатов
Это известная ошибка Microsoft, приводящая к появлению лишнего символа в конце URL-адресов в расширениях политики выдачи сертификатов. Как правило, это не вызывает проблем, но для сред, подлежащих оценке сертификатов, соответствию CABForum, аудитам WebTrust или использованию таких инструментов, как certlint, вы можете получить такие ошибки, как «ОШИБКА: в строке в CertificatePolicies найден управляющий символ».
Исправлено: ошибка влияет на синтаксический анализ раздела CAPolicy.inf для политик выдачи, например:

Обходной путь – указать расширение в шестнадцатеричном формате. Удалите конечный байт 00 из дампа ASN.1, созданного certutil -v -asn для неправильно закодированного сертификата, а затем уменьшите выделенные длины на единицу для компенсации.

Примечание редактора. Этот пост был первоначально опубликован в сентябре 2016 г. и обновлен региональным менеджером по продуктам GlobalSign Себастьяном Шульцем, чтобы предоставить дополнительную информацию о преимуществах AD CS.

Огромное количество организаций используют Windows Server в качестве основы своей ИТ-инфраструктуры. Бесчисленное количество организаций также используют PKI для различных нужд безопасности (например, защита веб-серверов [SSL], аутентификация на основе сертификатов, цифровые подписи для документов, шифрование электронной почты [S/MIME]). Тем не менее, мы часто удивляемся, узнав, как много людей не знают, что эти два явления могут быть связаны. Войдите в службы сертификации Active Directory (AD CS).

Что такое службы сертификатов Active Directory (AD CS)?

Согласно Microsoft, AD CS — это «роль сервера, которая позволяет вам создавать инфраструктуру открытого ключа (PKI) и предоставлять криптографию с открытым ключом, цифровые сертификаты и возможности цифровой подписи для вашей организации».

Здесь нужно кое-что распаковать. Если вы баловались инфраструктурой открытых ключей (PKI) раньше, скорее всего, вы понимаете, что вам не нужны AD CS для создания центра сертификации. И сертификаты для подписей, а также многие другие варианты использования также легко доступны в Интернете. Так зачем возиться с AD CS? Подсказкой здесь является слово «предоставлять». Правда в том, что относительно просто создать свой собственный ЦС и подписать несколько сертификатов с помощью таких инструментов, как OpenSSL. Вы также можете купить несколько сертификатов в ЦС, таком как GlobalSign, и установить их вручную. Но AD CS делает больше. Это позволяет вашей организации широко распространять сертификаты ЦС для компаний с тысячами сотрудников и, возможно, даже с большим количеством компьютеров. Как это делается?

Преимущества использования AD CS

Использование AD CS дает ряд преимуществ, в основном связанных с администрированием сертификатов.

Получить из Active Directory. Вы можете использовать существующую информацию об удостоверении конечной точки, существующую в AD, для регистрации сертификатов (чтобы избежать повторной регистрации). Это означает, что пользователи и компьютеры, зарегистрированные в вашем AD, могут автоматически вставлять свою информацию в сертификаты. Никто не захочет подавать заявки на все это вручную, верно?
Использовать существующую групповую политику. Вы можете настроить групповые политики AD (правила для групп определенных пользователей, определенных в AD, например, всех сотрудников, работающих в сфере бухгалтерского учета), чтобы указать, каким пользователям и машинам разрешено использовать какие типы сертификатов. Это отлично подходит для реализации управления доступом на основе ролей или атрибутов.
Автоматизация подготовки сертификатов и управления их жизненным циклом. Как только конечная точка впервые подключается к сети, в AD отправляется запрос на проверку типов сертификатов (называемых шаблонами), к которым у конечной точки есть доступ на основе групповой политики. На основе результатов этого запроса конечная точка запрашивает соответствующие сертификаты, которые затем отправляются обратно на конечную точку и устанавливаются. Сертификаты можно настроить на автоматическое продление так часто, как вам нравится. Это позволяет использовать недолговечные сертификаты, избавляя вас от беспокойства по поводу неожиданного истечения срока действия и пробелов в покрытии.
Тихая установка. Как упоминалось выше, процесс установки является автоматическим и не требует вмешательства конечного пользователя (или ИТ-специалиста). PKI может стать кошмаром в масштабе, если вы действительно не настроите автоматизацию. AD может помочь!

Недостаток служб сертификатов Active Directory (AD CS) — запуск собственного центра сертификации

Теперь, после описанных выше преимуществ, вы можете подумать: "Зарегистрируйте меня!" Но мы не можем говорить об AD CS, не обсудив другой критический элемент этого типа настройки PKI — внутренний ЦС (то есть ЦС Microsoft), который предоставляет сертификаты. AD CS является своего рода официантом в рассмотренном выше сценарии, принимающим запросы от конечных точек и доставляющим соответствующие сертификаты — и это отличный официант! Это «кухня» (т. е. центр сертификации Майкрософт), управлять которой может быть непросто.

В прошлом мы уже рассматривали недостатки работы внутреннего ЦС, но в целом они сводятся к тем же аргументам, с которыми вы всегда сталкиваетесь, пытаясь выбрать между аутсорсингом или внутренними силами. Подумай об этом. Вы бы посвятили время, деньги и ресурсы на разработку внутренней CRM? Или вы бы воспользовались одним из множества доступных вариантов SaaS, разработанных экспертами?

Поскольку PKI намного сложнее CRM, к обсуждению также следует добавить дополнительные соображения. Вот лишь несколько примеров:

Затраты на оборудование. Вам необходимо защищать и хранить корневой и закрытый ключи подписи на безопасном оборудовании (например, в аппаратном модуле безопасности или HSM).
Поддержка служб проверки. Вам необходимо убедиться, что у вас есть способ проверки действительности сертификата, например обновление списков отзыва сертификатов, сохранение списков отзыва сертификатов и запуск служб OCSP. Это может представлять собой еще большую проблему, чем распространение и управление жизненным циклом сертификатов. Если другая сторона захочет проверить действительность ваших сертификатов, CRL и OCSP-респонденты должны быть доступны круглосуточно и без выходных по всему миру.
Внутренний опыт работы с инфраструктурой открытых ключей. Система PKI сложна, и передовой опыт постоянно совершенствуется. Трудно найти старших специалистов по PKI, и они могут стоить недешево. Как убедиться, что ваша PKI безопасна? Как вы будете обеспечивать соблюдение требований? Как вы адаптируетесь к изменениям в криптографических стандартах?

Лучшее из двух миров: интеграция Active Directory от стороннего центра сертификации

В течение долгого времени (некоторые люди могут до сих пор так думать) единственным способом использовать Active Directory для PKI и получить все эти замечательные преимущества было использование AD CS и запуск собственного ЦС, но времена изменились! Несколько общедоступных ЦС, таких как GlobalSign, теперь предлагают интеграцию с AD, которая дает вам те же преимущества администрирования и автоматизации без необходимости внутреннего управления ЦС.

Благодаря этим интеграциям вы по-прежнему можете использовать AD и групповую политику для регистрации и назначения сертификатов, но запросы на сертификаты отправляются и на них отвечает общедоступный ЦС на основе SaaS. Сертификаты по-прежнему могут автоматически предоставляться, обновляться и автоматически устанавливаться.
Некоторые организации хотят сохранить полный контроль и иметь внутренние ресурсы для поддержки Microsoft CA. Некоторые этого не делают, и в этом случае важно знать, что такие типы общедоступных ЦС существуют. Главный вывод здесь заключается в том, что Active Directory может быть очень мощным инструментом для развертывания PKI, независимо от того, как вы это делаете.

Посетите наш веб-сайт, чтобы узнать больше об использовании Active Directory для автоматизации PKI и облегчения крупномасштабного развертывания.

Здравствуйте, друзья! Сегодня я хочу подробно рассказать о контейнерах Active Directory, связанных с ADCS (службы сертификатов Active Directory), их целях и принципах работы.

Все контейнеры, связанные с ADCS, хранятся в контексте именования конфигурации в контейнере служб открытых ключей:

Поскольку контейнер служб открытых ключей хранится в контексте именования конфигурации, любой его контент реплицируется между всеми контроллерами домена в текущем лесу (а не только в текущем домене) и доступен любому клиенту в лесу. Это означает, что невозможно ограничить контейнеры PKI только определенным доменом или доменами.

Вот скриншот из инструмента ADSIEdit.msc:

В контейнере Public Key Services находятся следующие подконтейнеры:

АИА
Программа CDP
Шаблоны сертификатов
Центры сертификации
Службы регистрации
КРА
ИД объекта

и следующую запись (не контейнер):

В разделах ниже описывается назначение каждого контейнера.

Этот контейнер используется для хранения промежуточных сертификатов ЦС и кросс-сертификатов. Этот контейнер может содержать записи типа certificateAuthority. Сертификаты CA записываются в атрибут cACertificate, а кросс-сертификаты записываются в атрибут crossCertificatePair.

При установке нового ЦС предприятия его сертификат автоматически устанавливается в контейнер AIA.

вы можете программно установить сертификат ЦС в этот контейнер, выполнив следующую команду certutil.exe:

с фактическим путем и именем файла сертификата.

Все сертификаты из этого контейнера распространяются на каждый клиент в рамках обработки групповой политики в контейнере Intermediate Certification Authorities клиента.

И этот контейнер может содержать записи типа cRLDistributionPoint. Базовый CRL записывается в атрибут certificateRevocationList. Разностные CRL (допускается несколько разностных CRL) записываются в атрибут deltaRevocationList.

Когда вы устанавливаете новый ЦС предприятия, он автоматически публикует первые CRL в контейнере CDP.

вы можете программно установить список отзыва сертификатов в этот контейнер, выполнив следующую команду certutil.exe:

с фактическим путем и именем файла сертификата. И замените на требуемое имя. Обычно имя подконтейнера представляет собой короткое имя узла ЦС (NetBIOS).

CRL из контейнеров CDP НЕ распространяются клиентам и используются только тогда, когда сертификат ссылается на конкретную запись cRLDistributionPoint в контейнере CDP.

Этот контейнер содержит шаблоны корпоративных сертификатов, используемые ЦС предприятия. Вы не должны редактировать шаблоны напрямую.Рассмотрите возможность использования оснастки MMC "Шаблоны сертификатов" (certtmpl.msc) для управления шаблонами.

Этот контейнер используется для хранения доверенных корневых сертификатов. Этот контейнер может содержать записи типа certificateAuthority. Сертификаты ЦС записываются в атрибут cACertificate.

При установке Enterprise Root CA его сертификат автоматически устанавливается в контейнер центра сертификации.

вы можете программно установить сертификат Root CA в этот контейнер, выполнив следующую команду certutil.exe:

с фактическим путем и именем файла сертификата. Обратите внимание, что копия корневого сертификата ЦС также установлена в контейнере AIA.

Все сертификаты из этого контейнера передаются каждому клиенту в рамках обработки групповой политики в контейнер доверенных корневых центров сертификации клиента.

Этот контейнер используется для хранения объектов Enterprise CA. Клиенты используют этот контейнер для поиска ЦС предприятия в лесу.

При установке нового ЦС предприятия создается новая запись в контейнере Enrollment Services.

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

Этот контейнер используется для хранения сертификатов агентов восстановления ключей для каждого ЦС предприятия. Когда ЦС предприятия выдает сертификат на основе шаблона агента восстановления ключей, он автоматически добавляет его в соответствующую запись. Если это первый сертификат KRA, CA создает для себя запись и записывает сертификат KRA в атрибут userCertificate.

Сертификаты из контейнера KRA доступны только при назначении нового агента восстановления ключей серверу ЦС.

Этот контейнер используется для хранения идентификаторов объектов (OID), зарегистрированных на предприятии. Контейнер OID может содержать определения идентификаторов объектов для пользовательских политик приложений, политик выдачи (сертификатов) и шаблонов сертификатов. Когда клиент является членом леса Active Directory, он использует контейнер OID для разрешения идентификаторов объектов вместе с локальной базой данных OID.

Новые OID следует регистрировать с помощью оснастки MMC "Шаблоны сертификатов" (certtmpl.msc), добавив новую политику приложения или выдачи (сертификата) на вкладке "Расширение" шаблона сертификата.

В качестве альтернативы вы можете использовать модуль PKI PowerShell, который содержит команды для добавления или удаления OID из Active Directory: Get-ObjectIdentifierEx, Register-ObjectIdentifier и Unregister-ObjectIdentifier.

Эта запись используется для хранения сертификатов ЦС, которые имеют право выдавать сертификаты для входа в систему с помощью смарт-карты и выполнять архивацию закрытого ключа клиента в базе данных ЦС.

Во время входа со смарт-картой контроллер домена проверяет, представлен ли эмитент в записи NTAuthCertificates. В противном случае попытка входа будет немедленно отклонена.
Во время регистрации сертификата на основе шаблона, который требует архивации закрытого ключа в базе данных ЦС, клиент регистрации проверяет, представлен ли сертификат ЦС в записи NTAuthCertificates. Если это не так, процесс регистрации завершится сбоем.

вы можете программно установить сертификат ЦС в этот контейнер, выполнив следующую команду certutil.exe:

с фактическим путем и именем файла сертификата.

При установке нового ЦС предприятия его сертификат добавляется в запись NTAuthCertificates. Обратите внимание, что копия сертификата CA также установлена в контейнере AIA.

Хотя ADSIEdit.msc позволяет просматривать и редактировать расширенные сведения о контейнере служб открытых ключей, он не очень удобен для пользователя и не может отображать двоичные данные (сертификаты и CRL) в пользовательском интерфейсе. Чтобы просмотреть содержимое контейнера в пользовательском интерфейсе, вы можете использовать инструмент PKI Health Monitor (PKIView.msc).

Войдите на компьютер, на котором установлены средства управления ADCS (RSAT), и запустите консоль PKIView.msc.
В открывшейся консоли выберите верхний узел с именем Enterprise PKI.
Откройте меню "Действие" и выберите "Управление контейнерами объявлений".

В этом окне вы можете просматривать и удалять записи для всех контейнеров, кроме шаблонов сертификатов и OID.

Службы сертификатов Active Directory — это реализация шифрования с открытым ключом (PKI) в Windows. ADCS необходим всякий раз, когда вы размещаете веб-сервер, которому необходимо шифровать данные по сети. Вместо того, чтобы покупать общедоступный сертификат, вы реализуете собственный доверенный внутренний центр сертификации (ЦС), развертываете корневой сертификат на своих клиентах через объект групповой политики, а затем можете создать столько сертификатов веб-сервера, сколько захотите.

Мое развертывание состоит из двух серверов с Windows Server 2019. Первый сервер будет автономным корневым центром сертификации (автономным, поскольку он будет отключен большую часть времени) и не будет частью домена. Второй сервер будет членом домена и центром сертификации.

Итак, на первом сервере установите роль ADCS на сервере рабочей группы в диспетчере серверов:

В разделе "Службы ролей" выберите "Центр сертификации".

После установки роли приступайте к настройке.

Этот сервер будет автономным корневым ЦС, член домена будет подчиненным ЦС предприятия.

Создайте новый закрытый ключ. SHA256 должен подойти для алгоритма хеширования с длиной ключа 2048.

Дайте ЦС имя.

Автономный корневой ЦС должен быть действителен в течение 10 лет. Онлайн ЦС для 5.

Здесь краткий обзор выбранных нами настроек.

Прежде чем настраивать второй сервер, давайте изменим доступ к информации о полномочиях (AIA) и точку распространения CRL (CDP). Они должны быть доступны клиентам в любое время. Откройте свойства и перейдите к расширениям. Удалите все точки распространения на CDP и создайте эти (я не уверен, нужен ли IDP, дайте мне знать):

Вот единственная точка распространения для AIA (обратите внимание на правильную переменную):

Изменить срок действия сертификата подчиненного ЦС, который мы собираемся выдать, и CDP (5 лет для подчиненного ЦС и один год для CDP):

Теперь давайте установим и настроим второй онлайн-сервер ЦС. Мастер установки компонента такой же, как и на первом сервере. Конфигурация немного отличается.

Как упоминалось ранее, мы используем корпоративный подчиненный ЦС.

Мы создаем новый ключ. Алгоритм хеширования также SHA256 с размером ключа 2048.

Запрос на сертификат будет загружен на первый сервер и подписан автономным корневым центром сертификации в цифровой форме.

Вот еще раз сводка всех настроенных параметров.

Теперь загрузите файл запроса сертификата в первый ЦС. Откройте MMC центра сертификации на первом сервере и отправьте новый запрос.

В разделе Ожидающий запрос вы должны увидеть свой запрос (это может занять несколько секунд). Здесь вы можете оформить сертификат.

Сохраните подписанный сертификат в файл в формате DER. Также скопируйте корневой сертификат на второй сервер и установите его в локальном хранилище сертификатов.

В онлайн-ЦС запустите службу ADCS и установите подписанный сертификат из автономного ЦС.

Выберите ранее сохраненный файл.

Теперь вам понадобится веб-сервер, на котором будут размещены эти файлы. Я установлю IIS на тот же сервер, но настоятельно рекомендуется разместить его на отдельном сервере.

Создайте запись DNS, указывающую на сервер:

Создайте файл CRL в автономном корневом ЦС и скопируйте его в корневую папку IIS (в моем случае это C:\inetpub\wwwroot\pki):

Файл будет создан в папке C:\cert. Нам также понадобится файл Root CA. Однако имя файла должно быть Ajni-Root-CA.crt.

Вот файл в папке IIS:

В pkiview.msc на Ajni-Root-CA все должно быть зеленым. При работе с Delta CRL IIS может блокировать загрузки из-за двойного экранирования. Чтобы решить эту проблему, разрешите двойное экранирование в IIS в разделе «Фильтрация запросов»:

Теперь, когда CDP доступен, можно без проблем запустить подчиненный ЦС. Как и в корневом ЦС, мы должны изменить расположение CDP и AIA:

При указанной выше конфигурации CRL и разностный CRL будут автоматически опубликованы в корневую папку IIS.

Публикуйте первый CRL вручную (необходимо отозвать один сертификат, иначе список не будет создан. Сделайте это через certlm.msc). После этого в pkiview.msc все должно стать зеленым.

Опубликуйте как CRL, так и Delta CRL.

Файлы должны быть созданы внутри C:\inetpub\wwwroot\pki. Сертификат подчиненного ЦС необходимо скопировать вручную и правильно назвать. Вы можете игнорировать тот факт, что у меня есть 2 сертификата подчиненного центра сертификации. Вы должны увидеть только один.

Pkiview.msc тоже доволен:

После того, как все настроено, вы можете закрыть автономный центр сертификации. Вам нужно запускать его только один раз в год при публикации CRL.

Наконец, опубликуйте корневой сертификат в Active Directory с помощью certutil. Этого также можно добиться с помощью GPO.

Читайте также: