Службы сертификации active directory windows 10

Numerous organizations rely on Windows Server as the backbone of their IT infrastructure. Many also use PKI to address diverse security requirements, including web server security (SSL), certificate-based authentication, digital document signatures, and email encryption (S/MIME). Active Directory Certificate Services (AD CS) is a Windows Server role that connects these two elements together. In this article, we’ll dig into what AD CS is, best practices for using it, and details on configuring it.

Active Directory Services is a feature in Windows Server environments that provides Public Key Infrastructure (PKI) for issuing and managing digital certificates. Certificates are used to secure communication, verify the identity of users and devices, and facilitate secure data exchange in a network. AD CS gives organizations the ability to issue, renew, revoke, and distribute certificates to users, computers, and services within the network.

As the name suggests, Active Directory serves as a directory service designed for Windows domain networks. The foundation of each Active Directory implementation is Active Directory Domain Services (AD DS). AD DS stores information about users, computers, and groups within a domain, verifies their credentials, and sets access rights. AD CS was introduced in Windows Server 2008 to issue digital certificates to the computer, user, and device accounts on the domain to enhance security and provide additional authentication methods.

AC DS configuration and certificate management

Proper certificate management and configuration are important for maintaining a secure and efficient PKI with an organization. Here are some key elements of managing and configuring Active Directory Services Certificate Services (AD CS).

Managing certificate templates and enrollment policies

Certificate templates define the properties and usage of certificates issued by AD CS. Administrators can create custom certificate templates to meet specific security requirements and control the attributes of issued certificates. One template could be created for web server authentication while another is designed for user authentication.

Enrollment policies determine how certificates are processed and authorized within the PKI. These policies can be based on criteria, such as user or group membership, device type, or network location to ensure that only authorized entities can request and obtain specific certificates.

Configuring certificate revocation and renewal

Administrators should configure and maintain the Certificate Revocation List (CRL) and/or Online Certificate Status Protocol (OCSP) to provide real-time status information about revoked certificates to guarantee that revoked certificates can’t be used for authentication or encryption.

Best practices for configuring renewal and revocation include the following:

• Regularly update CRLs or OCSP responders to ensure clients receive the latest status.
• Plan for overlapping periods to avoid service interruption.
• Implement renewal well before the expiration date to prevent gaps.
• Monitor CRA and OCSP performance to ensure they respond quickly.

Implementing certificate trust and validation

In AD CS, a certificate verifies that entities are who they claim to be. It is issued to an entity (a Certificate Authority) by a third party that is trusted by the other parties. Organizations need to configure trust relationships between CAs so that certificates issued by trusted CAs are recognized and accepted across the network.

A certificate trust list (CTL) is a mechanism that AD CS uses to specify which CAs are trusted by an organization. It holds a list of trusted CA certificates that clients use to validate the authenticity of certificates presented to them during the validation process.

Setting up and configuring NDES for network device enrollment

Network Device Enrollment Services (NDES) facilitates the enrollment of certificates for network devices like routers, switches, and wireless access points. Proper setup and configuration of NDES streamlines this process and allows these devices to get and use certificates for secure authentication and communication.

To use NDES, you must install the NDES service role on your AD CS server and configure a service account for NDES either as a user account specified as a service account or the built-in application pool identity. Then configure the NDES service account with request permission on the CA, set up an enrollment agent certificate and configure the Signature Key Provider and/or Encryption Key Provider.

Benefits of using Active Directory Certificate Services (AD CS)

Active Directory Services offers many advantages that significantly strengthen the security and efficiency of Windows domain networks. 

Some of the key benefits include:

• Enhanced security through digital certificates and encryption

The certificates supplied by AD CS play a pivotal role in verifying users, device, and service within a network. AD CS ensures that only authorized recipients can access encrypted data, mitigating unauthorized access and data breach risks.

• Simplified certificate management and lifecycle

AD CS streamlines the issuance, renewal, and revocation of certificates. Centralized administration, templates, and enrollment policies facilitate efficient handling of requests and distribution, reduces administrative burden, and saves time.

• Integration with Active Directory for centralized administration

AD CS’s integration with AD DS allows centralized certificate administration, leveraging the existing Active Directory infrastructure. Administrators can efficiently manage certificates alongside user accounts, ensuring consistent policies throughout the domain.

• Support for various certificate types and usage scenarios

Organizations can issue certificates for web servers (SSL/TLS certificates) to secure online communications, implement certificate-based authentication to enhance user identity verification, use digital signatures for document integrity and non-repudiation, and encrypt emails using S/MIME certificates.

Downsides of Active Directory Certificate Services (AD CS)

• Complex setup

Setting up AD CS can be complex and requires technical expertise with certificate authorities and the PKI architecture. Organizations must invest substantial resources for implementation, training, time and more..

• Challenging to use

AD CS requires a team with technical expertise in PKI management to maintain and this team would need additional training and resources to stay up-to-date with PKI best practices.

• High maintenance cost

While Microsoft CAs are free, organizations must invest in assembling and training a team to handle AD CS in addition to hardware and software requirements.

• Cross-site scripting exploitation

Cross-site scripting (XSS) refers to a web application security vulnerability in which attackers inject scripts into web pages. This script allow hackers to access sensitive information and even perform actions such as changing websites content or redirecting users to malicious websites. AD CS’s Web Enrollment does not properly validate user inputs which makes it vulnerable to XSS attacks.

• Compatibility issues

Integrating AD CS with existing devices and applications can sometimes be challenging for hybrid IT infrastructure. For example, Microsoft Group Policies (GPO) are not compatible with macOS or Linux devices so users would need to find work arounds such as RMM or MDM software.

Best practices for Active Directory Certificate Services (AD CS)

To ensure the smooth and secure operation of Active Directory Services, adopting the following best practices is essential:

Secure the AD CS Infrastructure

To secure your AD CS infrastructure, be sure to:

• Limit administrative access: Restrict this access to dedicated accounts used for managing the PKI and enforce the members of the local administrators’ group via GPO.
• Use application whitelisting: Use AppLocker or a third-party application whitelisting tool to configure services and applications that are permitted to run on CAs. This will add an additional layer of security by stopping unauthorized applications from running.
• Implement secure remote access: This is essential in a world of remote and hybrid work environments.

Implement backup and recovery procedures

Proper backup and recovery of AD CS is crucial to ensuring the availability, integrity, and security of your certificate infrastructure. 

Some key best practices include the following:

• Backup regularly: Frequently backing up the AD CS database, private key backups, and configuration data ensures the ability to recover from hardware failure and other catastrophic events.
• Store backups offsite: Store the backup copies securely at a remote location to protect against on-premises disasters.
• Test restoration: Periodically test the restoration process to verify the integrity of backups and the ability to recover from data loss effectively.

Perform regular monitoring and maintenance

The right maintenance and monitoring processes will ensure that AD CS components are functioning optimally and help address potential issues early on. Here are some tips to help you do that:

• Implement event logging: Reviewing event logs regularly will help you identify and respond to any potential issues or security breaches promptly.
• Monitor certificate expiration: Setting up alerts can help ensure that certificate renewals happen on time.
• Implement revocation checking: Ensure that clients check for certificate revocation through CRLs or OCSP, to avoid using compromised certificates.
• Perform health monitoring: Monitor the health of AD CS components, like Certificate Authority and web services, to detect and address potential performance or reliability issues.

Ensure compliance with industry standards

To make sure that you comply with industry standards and best practices, follow these guidelines:

• Develop a PKI policy: Create and enforce a clear PKI policy that defines the purpose and usage of certificates within the organization.
• Use certificate templates: Templates ensure consistent and appropriate use of certificates throughout the organization.
• Conduct compliance auditing: Regular audits should assess AD CS compliance with industry standards and internal security practices.
• Train employees: Educate administrators and other employees on best practices, security risks, and their roles in maintaining a secure PKI environment.

How to configure Active Directory Certificate Services (AD CS)

The first step to creating a secure and efficient PKI with AD CS is installing and configuring it. Here is an overview of the process, from prerequisites to step-by-step installation, along with important configuration considerations.

Prerequisites for AD CS installation

Before starting the AD CS installation, ensure that the following requirements are met:

• Windows Server: You need to have a Windows Server operating system with the latest updates installed.
• Active Directory Domain Services (AD DS): AD CS is tightly coupled with AD DS. Make sure that your network has an existing AD DS environment with at least one domain controller.
• Static IP address: Assign a static IP address to the server that will host AD CS components. This ensures stable network communication for certificate services.
• Administrative privileges: You need administrative privileges on the server to install AD CS.

Step-by-step guide to installing AD CS on a Windows Server

Here are the steps to installing Active Directory Certificate Services:

1. Launch Server Manager: You will find it in the Start menu.
2. Add roles and features: Navigate to “Manage” and click “Add Roles and Features.”
3. Choose installation type: Choose “Role-based or feature-based installation” from the “Add Roles and Features Wizard” and click “Next.”
4. Select server: Ensure the target server is selected and click “Next.”
5. Select server roles and features: Scroll down and select “Active Directory Certificate Services.” Click “Add Features” in the wizard and then click “Next.”
6. Select role services: Choose the AD CS role services you want to install and click “Next.”
7. Install AD CS: Review your selections, select “Restart the destination server automatically if required” and click “Install.”
8. Configure AD CS: Once the installation has finished, click “Close.” Select the notification flag in the Server Manager application, find the message to begin post deployment configuration and click the link to begin the configuration.

Configuration options and considerations during setup

By customizing the configuration of AD CS to your specific security requirements and operational needs, you can create a PKI environment that meets compliance standards and enhances the security posture of your network. Here are some options to consider:

• Key storage: During installation, you can choose to store the private key in the Microsoft Strong Cryptographic Provider or in a Hardware Security Model (HSM) for added security.
• Revocation settings: Configure the CRL publishing frequency and method (CRL or OCSP) to ensure timely revocation status updates for clients.
• Certificate templates: Configure the certificate templates that will be needed for various use cases in your organization.
• CA backup: Implement a backup plan to safeguard the CA private key and configuration data.
• Security configuration: Properly secure the CA server by limiting administrative access and enabling auditing.

Troubleshooting common AD CS issues

Even if AD CS has been configured carefully, issues can still arise. Here are some tips to help you identify, troubleshoot, and resolve some common AD CS issues:

Identifying Common Configuration Issues

• Certificate template errors: Issues with certificate issuance and enrollment could come down to certificate templates being configured incorrectly.
• CA services fail to start: Examine the event logs for error messages. It could be due to database corruption, inadequate permission, or port conflicts.
• Revocation configuration: Verify that CRLs or OCSP responders are configured correctly and accessible by clients.
• Certificate revocation failures: This can be caused by unreachable CRL distribution points or OCSP responders, or certificate chain validation issues.

Troubleshooting enrollment and validation problems

• Enrollment failures: Check permission on certificate templates and enrollment agents. Ensure that clients can communicate with the CA and access enrollment URLs.
• Expired certificates: Verify that certificates have not expired and set up monitoring to alert administrators about upcoming expirations.
• Revoked certificates: Investigate the reason for the revocation and ensure that clients can access up to date CRLs or OCSP responders.
• Certificate chain validation errors: Verify that the entire chain certificate is intact and valid. Check intermediate and root certificates’ presence in the trusted root certificate store.
• Client-side issues: Check time synchronization, network connectivity, and firewall configurations on the client side.

Can I still use AD CS after migrating to Azure AD (Microsoft Enterprise ID)?

Yes, IT teams can still use AD CS even after migrating to Azure AD (Microsoft Enterprise ID). AD CS’s certificates secure communications, authenticate devices, and enable secure access to resources, regardless of whether identities are managed in Azure AD or on-premise Active Directory. Azure AD can automate certificate enrollment to streamline workflows for IT teams.

Does AD CS work with mobile device management (MDM)?

Yes, MDM software typically utilize certificates for device authentication, encryption, and mobile device security.

AD CS can work with MDM solhttps://www.ninjaone.comutions as most providers provide AD CS Connector that enables cloud solutions such as MDM to communicate with the AD CS server. These connectors are especially helpful when dealing with non-Windows devices such as Apple and Android. Technicians can add custom CA and deploy and manage them through their MDM solution.

Seamless integration with an MDM software ensures that devices are properly authenticated and secured, enhancing overall data and device security within the organization.

Conclusion

Active Directory Certificate Services (AD CS) plays an important role in enhancing the security of Windows domain networks. AD CS integrates PKI with the familiar Active Directory infrastructure and enables organizations to issue and manage digital certificates, secure communication, and verify the identity of users and devices within the network. The benefits of AD CS include improved security through encryption and certificate-based authentication, simplified certificate management, and centralized administration in Active Directory.

To achieve these benefits, AD CS must be managed and configured correctly which means adhering to a set of best practices, which include implementing backup and recovery procedures, monitoring AD CS, and performing regular maintenance. By following these and other guidelines suggested in this article and building your troubleshooting skills, you can maintain a reliable and secure AD CS infrastructure that contributes to the overall resilience of your IT ecosystem.

В настоящей статье мы рассмотрим, что такое Active Directory Certificate Services и выполним базовое развертывание и настройку.

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

В нашей сегодняшней статье мы будем разворачивать двухуровневую архитектуру PKI, которая, как правило, удовлетворяет требованиям большинства компаний.

Планируемая инфраструктура

Перед началом работ необходимо составить план и нарисовать схему, которую мы будем реализовывать. Как я уже писал выше – у нас будет двухуровневая инфраструктура PKI. Архитектура решения представлена на рисунке ниже:

В данной схеме представлены следующие объекты:

Развертывание инфраструктуры

Развертывание корневого центра сертификации

1. Заходим на сервер корневого центра сертификации;

2. Идем в Server Manager – Manage – Add Roles and Features:

3. Откроется Add Roles and Features Wizard:

На странице Before you begin нажимаем Next;

4. В окне Installation Type оставляем все по умолчанию и нажимаем Next:

5. На странице Select destination server выбираем наш сервер:

И нажимаем Next;

6. На странице Select server roles выбираем Active Directory Certificate Services:

Нам сразу будет предложено установить Remote Server Administration Tools. Нажимаем Add Features и затем нажимаем Next;

7. На странице Select features нажимаем Next;

8. На странице Active Directory Certificate Services нажимаем Next;

9. На странице Select role services убеждаемся, что у нас выбран пункт Certification Authority (он, как правило, выбран по умолчанию):

И нажимаем Next;

10. На странице Confirm installation selections нажимаем Install:

11. Начнется процесс установки:

12. После окончания установки мы увидим такое окно:

Для продолжения настройки выбираем Configure Active Directory Certificate Services on the destination server;

13. Откроется окно AD CS Configuration:

На странице Credentials необходимо указать учетные данные. Поскольку у нас сервер будет недоменный и настройка в режиме Standalone, то оставляем нашу административную учетную запись по умолчанию и нажимаем Next;

14. На странице Role Services выбираем Certification Authority и нажимаем Next:

15. На странице Setup Type выбираем Standalone CA и нажимаем Next:

16. На странице CA Type выбираем Root CA и нажимаем Next:

17. На странице Private Key выбираем Create a new private key:

И нажимаем Next;

18. На странице Cryptography for CA оставляем все по умолчанию и нажимаем Next:

19. На странице CA Name:

Заполняем поле Common name for this CA. Остальные поля в рамках нашей сегодняшней инфраструктуры мы не трогаем. Нажимаем Next;

20. На странице Validity Period выставляем 15 лет и нажимаем Next:

21. На следующей странице CA Database можно настроить пути для баз данных:

Оставляем все по умолчанию и нажимаем Next;

22. На странице Confirmation проверяем наши настройки и нажимаем Configure:

23. Начнется процесс установки и если все хорошо, то мы увидим такую страницу:

24. Идем в Server Manager – Tools – Certification Authority:

25. И попадаем в консоль CA:

Далее, идем по стандартрому пути C:\Windows\System32\CertSrv\CertEnroll и копируем оттуда сертификат и список отзыва сертификатов. Они нам понадобятся на этапе настройки выдающего центра сертификации.

Настройка выдающего центра сертификации

Для начала нам необходимо установить службу ADCS на нашем сервере, который будет выполнять роль выдающего центра сертификации. Для развертывания данной роли повторяем шаги 2-12 из раздела «Развертывание корневого центра сертификации«. После того, как мы завершили установку службы сертификатов, перейдем к ее настройке.

1. Откроется окно мастера AD CS Configuration:

На странице Credentials необходимо выбрать доменную учетную запись с правами Domain Admin и Enterprise Admin и нажимаем Next;

2. На странице Role Services необходимо выбрать роль Certification Authority:

И нажимаем Next;

3. На странице Setup Type выбираем Enterprise CA:

И нажимаем Next;

4. На странице CA Type выбираем Subordinate CA:

И нажимаем Next;

5. На странице Private Key выбираем Create a new private key:

И нажимаем Next;

6. На странице Cryptography for CA оставляем все по умолчанию и нажимаем Next;

7. На странице CA Name указываем имя в поле Common name for this CA:

И нажимаем Next;

8. На странице Certificate Request необходимо выбрать вариант запроса к корневому центру сертификации:

Выбираем (если не выбран) Save a certificate request to file on the target machine и нажимаем Next;

9. На странице CA Database оставляем все по умолчанию и нажимаем Next;

10. На странице Confirmation проверяем наши настройки и если все в порядке, то нажимаем Configure:

11. Начнется установка, и после завершения на странице Result можно посмотреть результаты установки:

Как видим, система сообщает, что установка полностью не завершена, поскольку не установлен сертификат. Этим сейчас и займемся.

Получение сертификата с корневого центра сертификации

1. Копируем наш созданный *.req – запрос на сервер RootCA в корень диска C;

2. На сервере RootCA запускаем CMD имени администратора и выполняем следующую команду:

certreq -submit "C:\subordCA.domain.com_domain-SUBORDCA-CA-1.req"

3. Во время запуска команды появится окно Certification Authority List:

Выбираем наш CA и нажимаем ОК;

4. Если запрос выполнен успешно, то мы увидим сообщение примерно такого содержания:

Нам сообщают, что наш запрос на сертификат ждет выдачи;

5. Идем по пути Server Manager – Tools – Certification Authority:

6. Заходим в Pending Requests:

И видим наш запрос с присвоенным Request ID 2;

7. Вызываем контекстное меню:

Выбираем All Tasks – Issue;

8. Переходим в Issued Certificates и видим наш сертификат:

9. Возвращаемся в командную строку и вводим следующую команду:

certreq -retrieve 2 C:\SubCA.crt

В данном случае нашему сертификату будет присвоено имя SubCA, но при желании можете указать любое другое название для выгружаемого сертификата;

10. В форме Certification Authority List выбираем наш CA и нажимаем ОК;

11. Теперь у нас готов сертификат для нашего промежуточного сервера Subordinate CA.

Теперь, мы должны скопировать полученный нами сертификат, а также корневой сертификат и список отзыва (которые мы получили раньше) на наш промежуточный сервер сертификации в каталог C:\Install.

Установка корневого и промежуточного сертификатов

1. Открываем PowerShell с правами администратора и выполняем следующие команды:

certutil -dspublish -f "C:\install\RootCA_CompanyRootAuthority.crt"
certutil -addstore -f root "C:\install\RootCA_CompanyRootAuthority.crt"
certutil -addstore -f root "C:\install\CompanyRootAuthority.crl"

Данными командами мы выполняем публикацию и добавление корневого сертификата, полученного от сервера RootCA и список отзыва сертификатов. Если все команды отработали успешно, то можно устанавливать полученный сертификат SubCA.crt;

2. Открываем CMD от имени администратора и вводим следующую строку:

certutil -installcert C:\install\SubCA.crt

Эта команда установит наш сертификат на сервер Subordinate CA;

3. Если команда отработала без ошибок, то необходимо выполнить запуск службы CertSrv и наш сервер выдачи сертификатов готов к работе:

Итог

В рамках данной статьи мы развернули корневой и промежуточный центр сертификации. И данная система уже может функционировать, но если необходимо, чтобы клиенты автоматически получали сертификаты — потребуется дополнительная настройка внутри GPO. Статья по настройке автоматической выдачи сертификатов выйдет чуть позже.

А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере Windows Server 2016. Поговорим о подготовке контроллера домена, подготовке веб-сервера, установке корневого и издающего центров сертификации и об обновлении сертификатов. Заглядывайте под кат!

Первая часть серии

Вторая часть серии

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа, набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем… Приложения могут использовать CRL для подтверждения, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, является частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
• CPS (Certificate Practice Statement) — документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.

Общий план развёртывания

Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:

1. Контроллер домена — необходим для функционирования домена Active Directory;
2. Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
3. Корневой ЦС — будет выполнять функции корневого ЦС;
4. Подчинённый ЦС — будет выполнять функции издающего ЦС.

Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

Подготовка контроллера домена

Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.

Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

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

• Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment
• User Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment

Политика в обоих разделах должна быть сконфигурирована как показано на следующей картинке:

Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.

Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:

Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom" 

Подготовка веб-сервера

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

• Установка службы IIS

Для установки службы IIS можно воспользоваться следующей командой:

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

• Создание папки PKIdata

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:\InetPub\wwwroot\PKIdata

New-Item -ItemType Directory -Path C:\InetPub\wwwroot -Name PKIdata -Force
New-SmbShare -Path C:\inetpub\wwwroot\PKIdata -Name PKI -FullAccess everyone

После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

• Создание веб-сайта

Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:\inetpub\wwwroot\PKIdata
New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:\inetpub\wwwroot\PKIdata

• Включение поддержки Delta CRL

В нашем сценарии издающий ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию, IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Для этого необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Установка корневого ЦС

Фактическая установка ЦС будет включать в себя несколько этапов:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки.

Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	Standalone CA
Тип ЦС	Root CA
Сертификат
Имя сертификата	Contoso Lab Root Certification authority
Дополнительный суффикс	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа	RSA#Microsoft Software Key Storage Provider
Длина ключа	4096 бит
Алгоритм подписи	SHA256
Срок действия	15 лет

В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.

Предварительная конфигурация

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%\CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType StandaloneRootCA `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod "years" `
    -ValidityPeriodUnits 15 `
    -DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog")

Итоговая настройка

После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

Название параметра	Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов	15 лет
Точки публикации CRT	1) По-умолчанию 2) C:\CertData\contoso-rca<CertificateName>.crt 3) IIS:\InetPub\PKIdata\contoso-rca<CertificateName>.crt*
Точки распространения CRT	1) cdp.contoso.com/pki/contoso-rca<CertificateName>.crt
Точки публикации CRL	1) По-умолчанию 2) C:\CertData\contoso-rca<CRLNameSuffix>.crt 3) IIS:\InetPub\PKIdata\contoso-rca<CRLNameSuffix>.crt*
Точки распространения CRL	1) cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt
Сертификат
Состав CRL	Base CRL
Base CRL
Тип	Base CRL
Срок действия	6 месяцев
Расширение срока действия	1 месяц
Алгоритм подписи	SHA256
Публикация в AD	Нет

* — копируется на сервер IIS

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Root CA post-installation script                               ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=C:\CertData\contoso-rca%%8.crl
SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl
SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt

:: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка
:: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows.
md C:\CertData

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl\n1:%CrlLocal%\n2:%CDP%"

certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-rca.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-rca.crt C:\CertData

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 15
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Months"
certutil -setreg CA\CRLOverlapUnits 1

:: Отключаем дифференциальные списки отзыва (или Delta CRL)
certutil -setreg CA\CRLDeltaPeriodUnits 0

:: Отключаем генерацию кросс-сертификатов
certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «\n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

Название галочки в MMC	Числовое значение	Название галочки в MMC	Числовое значение
Publish CRLs to this location.	1	Include in the AIA extension of issued certificates.	2
Include in the CDP extension of issued certificates.	2	Include in the Online Certificate Status. Protocol (OCSP) extension.	32
Include in CRLs. Clients use this to find Delta CRL locations.	4
Include in all CRLs. Specifies where to publish in AD DS when publishing manually.	8
Publish Delta CRLs to this location.	64
Include in the IDP extension of issued CRLs.	128

Если взять путь для CDP: 1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

В каждом пути включены переменные с двойным знаком процента «%%». Это переменные, которые ЦС при формировании пути будет автоматически заполнять исходя из типа переменной.

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

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

Переменная в редакторе расширений CDP и AIA	Переменная в скрипте	Где используется	Значение
<ServerDNSName>	%1	CDP/AIA	Полное ДНС имя сервера ЦС
<ServerShortName>	%2	CDP/AIA	Короткое (NetBIOS) имя сервера ЦС
<CaName>	%3	CDP/AIA	Имя ЦС (атрибут CN в сертификате)
<CertificateName>	%4	AIA	Индекс сертификата ЦС. Используется только при обновлении сертификата ЦС.
<ConfigurationContainer>	%6	CDP/AIA	Путь к configuration naming context в Active Directory
<CATruncatedName>	%7	CDP/AIA	Укороченное (санитизированное) имя сертификата ЦС. В общем случае будет совпадать с полным именем ЦС
<CRLNameSuffix>	%8	CDP	Индекс ключа ЦС, которым был подписан данный CRL. Используется при обновлении ключевой пары ЦС.
<DeltaCRLAllowed>	%9	CDP	Добавляет суффикс для Delta CRL (знак «+»).
<CDPObjectClass>	%10	CDP	Класс объекта в Active Directory
<CAObjectClass>	%11	CDP/AIA	Класс объекта в Active Directory

В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной , только здесь будет указываться индекс ключевой пары ЦС.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

Опытные администраторы знают к чему приводит включение Audit Object Access — к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.

Прочие настройки

После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
• Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Если всё хорошо, тогда скопируйте содержимое папки C:\CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish path\contoso-rca.crt RootCA

Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root path\contoso-rca.crt

Установка издающего ЦС

Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки и конфигурации.

Предустановочная конфигурация

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

1. Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
2. Администраторы сами должны определять какие шаблоны будут использовать в организации.

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

; заголовок INI файла
[Version]
Signature= "$Windows NT$"

; указываем список политик, которые будут включены в сертификат ЦС. В нашем
; случае будет одна политика под названием AllIssuancePolicies.
[PolicyStatementExtension]
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
[AllIssuancePolicy]
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
[BasicConstraintsExtension]
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
[certsrv_server]
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0

Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	Enterprise CA
Тип ЦС	Subordinate CA
Автоматическая загрузка шаблонов	Нет
Сертификат
Имя сертификата	Contoso Lab Issuing Certification authority
Дополнительный суффикс	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа	RSA#Microsoft Software Key Storage Provider
Длина ключа	4096 бит
Алгоритм подписи	SHA256
Срок действия	15 лет (определяется вышестоящим ЦС)
Политики выдачи	1) Имя: All Issuance Policies OID=2.5.29.32.0 URL=http://cdp.contoso.com/pki/contoso-cps.html
Basic Constraints	isCA=True (тип сертификата — сертификат ЦС) PathLength=0 (запрещается создание других промежуточных ЦС под текущим ЦС).

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType EnterpriseSubordinateCa `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256

После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

 # отправляем запрос на ЦС.
certreq -submit 'C:\CA-01.contoso.com_Contoso Lab Issuing Certification authority.req'
# предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде
# в моём случае это номер 2
certutil -resubmit 2
# после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер
# запроса, который был указан после выполнения первой команды
certreq -retrieve 2 C:\subca.crt

Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:

certutil -installcert c:\subca.crt
net start certsvc

Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

Итоговая настройка

По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

Аналогичная таблица составляется и для издающего ЦС.

Название параметра	Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов	Максимально: 5 лет (остальное контролируется шаблонами сертификатов)
Публикация в AD (контейнеры)	AIA NTAuthCertificates
Состав CRL	Base CRL Delta CRL
Точки публикации CRT	1) По-умолчанию 2) \\IIS\PKI\contoso-pica<CertificateName>.crt
Точки распространения CRT	1) cdp.contoso.com/pki/contoso-pica<CertificateName>.crt
Точки публикации CRL	1) По-умолчанию 2) \\IIS\PKI\contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
Точки распространения CRL	1) cdp.contoso.com/pki/contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
Base CRL
Тип	Base CRL
Срок действия	1 неделя
Расширение срока действия	По умолчанию
Алгоритм подписи	SHA256
Публикация в AD	Нет
Delta CRL
Тип	Delta CRL
Срок действия	1 день
Расширение срока действия	По-умолчанию
Алгоритм подписи	SHA256
Публикация в AD	Нет

За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Issuing CA post-installation script                            ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=\\IIS\PKI\contoso-pica%%8%%9.crl
SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl
SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:%CrlLocal%\n6:%CDP%"

certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в сетевую папку
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-pica.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-pica.crt \\IIS\PKI

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
:: базовый CRL
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "weeks"

:: Delta CRL
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "days"

:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127

:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах 
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"

:: Включаем поддержку расширения OcspRevNoCheck, если планируется установка
:: сетевого ответчика (Online Responder или OCSP сервера)
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

Прочие настройки

После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
• Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку Enterprise PKI Health (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.

Рекомендации

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

Шаблоны сертификатов

Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке Certificate Templates MMC (certtmpl.msc). Рекомендации по шаблонам сертификатов:

Использование готовых шаблонов сертификатов

Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon. Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.

Версия шаблона

Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:

Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на .NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).

Успешно такие сертификаты смогут использовать приложения, которые используют не .NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.

 
Поля Subject и Subject Alternative Names

Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.

Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».

Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.

Права на шаблоны сертификатов

Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.

Обновление сертификатов ЦС

Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

• Срок жизни сертификата ЦС истекает;
• Ключ ЦС скомпрометирован;
• Необходимо изменить длину ключа или алгоритм подписи;
• Слишком большой список отзыва (больше нескольких мегабайт).

Первый вопрос, если всё идёт штатно, за какое время до истечения срока действия сертификата ЦС его нужно обновлять?

Сертификат издающего ЦС должен обновляться за максимальный срок действия издаваемых сертификатов. В нашем случае срок действия сертификата издающего ЦС 15 лет, а максимальный срок действия издаваемых сертификатов 5 лет (см. конфигурационную таблицу). Это означает, что сертификат издающего ЦС необходимо обновить через 10 лет. Если это время затянуть, то мы не сможем обеспечить необходимый срок действия для самого долгосрочного шаблона.

Порядок обновления ЦС

В нашей двухуровневой иерархии сертификаты корневого и издающего ЦС имеют одинаковый срок действия. Поэтому, когда вы принимаете решение об обновлении сертификата любого ЦС, необходимо обновлять их вместе. Первым обновляется сертификат корневого ЦС, затем сертификат издающего ЦС.

Генерация ключей при обновлении сертификатов ЦС

При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

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

• Certificate validation fails when a certificate has multiple trusted certification paths to root CAs.
• «0x80092013, CRYPT_E_REVOCATION_OFFLINEA» error message when you try to verify a certificate that has multiple chains in Windows Server 2008 or in Windows Vista.

При генерации новой ключевой пары для каждого сертификата будет гарантирован только один путь к корневому сертификату и модуль построения цепочек сертификатов уже не ошибётся.

Резервное копирование

Вопросы резервного копирования и восстановления после отказа являются отдельной темой. Здесь я лишь отмечу основные моменты, которые следует учесть при планировании стратегии резервного копирования.

Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:

• Оснастка Certification Authority MMC (certsrv.msc);
• Утилита certutil.exe с параметром -backup.

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

HKLM\System\CurrentControlSet\Services\CertSvc

При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.

Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:

• Ключи и сертификаты ЦС;
• База данных ЦС;
• Настройки ЦС из реестра;
• Предустановочный конфигурационный файл;
• Установочные и конфигурационные скрипты.

Этот список не зависит от принятой в вашей компании стратегии резервного копирования, он всегда должен быть включён в список резервных копий.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.