Инфраструктура открытых ключей в Windows Server 2016. Часть 1. Предварительный этап
Внедрение собственной инфраструктуры открытых ключей часто становится одной из задач, которую приходится решать ИТ-отделам предприятия
Причины этого вполне объяснимы: тут и вопросы безопасной аутентификации, защиты передаваемых и хранимых данных, потребность в использовании электронной цифровой подписи и другое. Далеко не всегда эти задачи могут быть решены средствами внешних поставщиков, несмотря на очевидную тенденцию развития облачных решений.
Как бы там ни было, задача внедрения и поддержания собственных инфраструктур осталась, а раз так, то стоит разобраться с особенностями ее внедрения. Впрочем, прежде чем говорить о внедрении, имеет смысл обсудить вопросы правильного использования и проектирования. Журнал не раз затрагивал эту тему в своих публикациях, поэтому мы можем просто сослаться на ранее опубликованную статью, которая поможет читателю ознакомиться с этой темой [1]. Великолепным источником является руководство Брайана Комара [3], которое поможет получить глубокие знания предмета.
Кроме того, разумно ознакомиться и с первоисточником, если мы говорим о внедрении решения на основе PKI Microsoft, так как разработчик предлагает полное руководство по проектированию [2].
Мы же продолжим эту тему рассказом о внедрении инфраструктуры открытых ключей для некоторой организации и предложим читателю некоторый бизнес-кейс из реальной практики, который поможет лучше понять процедуру внедрения и пройти все ее шаги.
Типовой сценарий
Пусть у нас есть организация, имеющая два основных центра обработки данных и несколько филиалов. Современные тенденции ведения бизнеса предполагают наличие не только стационарных пользователей, но и мобильных. Многие сотрудники компании применяют в своей работе не только обычные рабочие места, но и мобильные устройства. Предполагается необходимость взаимодействия с партнерами и заказчиками, с предоставлением им доступа к некоторым ресурсам компании. Служба каталога предприятия традиционно использует службу каталога на основе Microsoft Active Directory Domain Services. Структурная схема типового ЦОД предприятия может выглядеть так, как это показано на рис. 1. Конечно, говоря о центре обработки данных, мы делаем некоторое преувеличение, скорее здесь мы можем говорить о штаб-квартире и крупных филиалах. Поддержка собственного дата-центра в настоящем понимании этого термина оказывается под силу далеко не всем, но в некотором приближении будем считать, что говорим о ЦОД.
Внедрение корпоративной PKI обусловлено ростом потребности в обеспечении безопасности внутри предприятия. Подобное краткое описание нередко оказывается типовой историей для многих компаний. Так как же внедрить PKI для такой организации?
Как я уже упоминал выше, с проектированием решения можно познакомиться в статьях [1] и [2]. Обычно в подобной ситуации мы будем говорить о двухуровневой иерархии, состоящей из корневого отключенного от сети центра сертификации (Stand-Alone Root CA) и подчиненного издающего корпоративного центра сертификации. Не исключено, а скорее всего обязательно будет присутствовать потребность в использовании и публичных удостоверяющих центров, например, для обеспечения возможности работы внешних клиентов компании.
Разумеется, возможны и другие варианты, которые мы обсудим в этом цикле статей, но в качестве, скажем так, типового и наиболее часто встречающегося имеет смысл рассматривать именно этот. Более сложные иерархии с использованием дополнительных уровней иерархии с использованием промежуточных серверов политик Policy CA встречаются только для крупных компаний, где требования к политикам сертификатов могут варьироваться, что и приводит к усложнению структуры. Таким образом, типовая структурная схема может выглядеть так, как это показано на рис. 2.
Предварительный этап
Этап подготовки развертывания, с точки зрения практических аспектов, будет состоять из настройки точек распространения (Distribution Point), добавления дополнительной записи на сервере DNS и подготовки файлов capolicy.inf, определяющих начальную настройку и параметры работы серверов сертификатов. Наиболее часто используемыми точками распространения являются HTTP и LDAP. Первый вариант обусловлен его универсальностью для любого типа клиента, второй – удобством поиска и доступа для типового клиента Active Directory. Соответственно, администратор сталкивается с задачами:
- настройки места хранения файлов сертификатов, списка отзыва и заявления поставщика, прав доступа на этот или эти ресурсы;
- установки и настройки сервера веб для выполнения роли Distribution Point для PKI;
- добавления специальной записи на корпоративном DNS-сервере, которая обеспечит поиск необходимых ресурсов;
- обеспечения отказоустойчивости и доступности как самих издающих серверов сертификатов, так и точек распространения, причем, говоря о них, не следует забывать о необходимости своевременной синхронизации данных между веб-серверами, выполняющими эту роль. Например, публикация нового CRL-файла означает необходимость предоставления доступа к нему с помощью любого сервера веб-фермы, выполняющего роль Distribution Point, но к этому мы еще вернемся несколько позже.
Администратору необходимо создать каталог для хранения вышеуказанных файлов и предоставить к нему доступ требуемым группам пользователей, то есть если предполагается «внутреннее» использование, то выбираются соответствующие группы, обычно речь идет о группе Users, поскольку, как правило, работают с сертификатами все пользователи компании, если же мы говорим о необходимости работы внешних пользователей, то придется использовать группу everyone.
Кроме того, встроенной группе Cert Publishers [4] необходимо предоставить права для изменений внутри этой папки. Это требуется для правильного подхода при построении строгой ролевой модели.
На веб-сервере создается виртуальный каталог, указывающий на соответствующий ресурс в хранилище. Необходимо удостовериться в том, что активна опция Directory Browsing (см. рис. 3), и если предусматривается использование разностных списков отзыва (Delta CRL), которые в имени файлов используют символ «+», то потребуется обеспечить так называемый Double Escaping, что также подразумевает дополнительную настройку на веб-сервере (см. рис. 4).
Наконец, необходимо создать на сервере DNS запись CNAME [5], которая позволит клиенту находить требуемый ресурс (см. рис. 5).
Следующий шаг предварительного этапа настройки – подготовка файла начальной конфигурации удостоверяющего центра – capolicy.inf [6].
Файл capolicy.inf
Если нас не устраивают параметры по умолчанию, а обычно они нас не устраивают, нам нужно создать файл capolicy.inf на всех удостоверяющих центрах еще до развертывания самой службы сервера сертификатов. Именно этот файл и будет определять параметры начальной настройки, а также параметры поведения при обновлении сертификата самого сервера сертификатов. Этот файл обязательно должен быть размещен в папке %Systemroot% (обычно это C:\Windows) еще до установки сервиса. Использование иного имени или места размещения приведет к игнорированию этого файла, и сервер сертификатов будет установлен с параметрами «по умолчанию».
Рассмотрим структуру и внутреннее содержание файла. Capolicy.inf состоит из нескольких разделов.
- Version – семейство используемой операционной системы удостоверяющего центра
- PolicyStatementExtension – заявление поставщика
- BasicConstrainsExtension – ограничение глубины иерархии УЦ
- EnhancedKeyUsageExtension – ограничение на выдаваемые типы сертификатов
- Certsrv_server – параметры обновления сертификата, настройки сертификата УЦ, параметры обновления и срок жизни сертификата, период публикации списка отзыва
Version
Первый раздел [Version] содержит одну строку, говорящую о том, что используется формат Windows NT, он-то нам и нужен, если мы базируемся на Windows Server. Эта строка будет всегда присутствовать в файле, и неважно какой УЦ (корневой или подчиненный) мы разворачиваем.
PolicyStatementExtention
В этом разделе указан путь к заявлению поставщика (Certification Practice Statement или CPS) и определены политики, которые служат для безопасности.
Certification Practice Statement – просто документ, который можно загрузить по заданной ссылке, чтобы с ними ознакомиться. В нашем примере это файл cps.txt.
Обычно в нем указывается, какие меры обеспечения безопасности работы сервиса предприняты его владельцем. В сущности, это своего рода соглашение между потребителем и владельцем сервиса. Наличие этого раздела необязательно с точки зрения функционирования сервера, но правила хорошего тона подразумевают необходимость что-то рассказать о себе.
Notice=»Legal Policy Statement»
Внутри политики содержится Object identifier (OID). Мы не будем останавливаться на этом подробно. С OID вы можете познакомиться по следующей ссылке: https://www.networkworld.com/article/2231566/microsoft-subnet/obtaining-an-oid-for-a-certificate-issuing-policy—capolicy-inf—-.html .
EnhancedKeyUsageExtension
В разделе EnhancedKeyUsageExtension можно ограничить применимость сертификатов, издаваемых центром сертификации. Пример такого раздела представлен ниже.
OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
OID = 1.3.6.1.5.5.7.3.4 ; Secure Email
Перечисляется, какие сертификаты может выдавать данный центр сертификации.
В сертификате это выглядит так, как это представлено на рис. 6.
Дополнительную информацию по данному разделу можно найти по ссылке: https://technet.microsoft.com/en-us/library/cc725621%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 описание Application Policies.
Конечно, этот раздел не обязателен, по умолчанию центр сертификации может выпускать любые типы сертификатов.
BasicConstraintsExtension
В разделе BasicConstraintsExtension можно ограничить глубину иерархии центров сертификации, так, например, раздел может иметь следующий вид:
Это означает, что после этого центра сертификации может быть только один уровень подчиненных. Если ограничение иерархии не требуется, то раздел BasicConstraintsExtension должен иметь вид:
Не стоит ограничивать глубину иерархии удостоверяющих центров на корневом, поскольку это приводит к снижению гибкости инфраструктуры. Время жизни инфраструктуры обычно весьма значительно, и за этот период многое может измениться. В трехуровневой иерархии центров ее глубина может быть ограничена, например, на втором уровне, и, если даже раздел BasicConstraintsExtension будет отсутствовать в файле УЦ capolicy.inf третьего уровня (издающем), выдать сертификат еще одному УЦ с него будет нельзя. При попытке обработать запрос нижестоящего центра сертификации на получение им сертификата будет выдаваться сообщение об ошибке.
В разделе certsrv_server представлены параметры сертификата самого удостоверяющего центра.
- RenewalKeyLength=4096 – указатель размера ключа центра сертификации, в нашем случае 4096 бит.
- RenewalValidityPeriodUnits=20 – устанавливается срок действия сертификата УЦ (20 лет).
- RenewalValidityPeriod=Years – устанавливаются единицы измерения для параметра RenewalValidityPeriodUnits.
- CRLPeriodUnits=26 – устанавливается периодичность публикации CRL-сертификата УЦ (в представленном примере 26 недель).
- CRLPeriod=Weeks – устанавливаются единицы измерения для параметра CRLPeriodUnits.
- CRLOverlapUnits=2 – устанавливается время, в течение которого CRL еще действительны, после наступления момента публикации следующего CRL. Дополнительное время действия CRL, а следовательно, валидности сертификата.
- CRLOverlapPeriod=Weeks – устанавливаются единицы измерения для параметра CRLOverlapUnit.
- CRLDeltaPeriodUnits=0 – устанавливается периодичность публикации Delta CRL, 0 означает, что публикация производиться не будет.
- CRLDeltaPeriod=Hours – устанавливаются единицы измерения для параметра CRLDeltaPeriodUnits
- LoadDefaultTemplates=0 – 0 означает, что не нужно производить публикацию шаблонов сертификатов, а следовательно, не будет производиться выдача сертификатов на основе этих шаблонов (в том числе автоматическая).
- AlternateSignatureAlgorithm=1 – настройка УЦ для включения улучшенного алгоритма шифрования, включение поддержки стандарта PKCS#1 V2.1 [7], используемого при подписи сертификата и создании запросов. Нужно учитывать, что данный стандарт не поддерживается старыми операционными системами, такими как Windows 2000, Windows XP, Windows Server 2003.
CAPolicy.inf Syntax
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016
The CAPolicy.inf is a configuration file that defines the extensions, constraints, and other configuration settings that are applied to a root CA certificate and all certificates issued by the root CA. The CAPolicy.inf file must be installed on a host server before the setup routine for the root CA begins. When the security restrictions on a root CA are to be modified, the root certificate must be renewed and an updated CAPolicy.inf file must be installed on the server before the renewal process begins.
The CAPolicy.inf is:
Created and defined manually by an administrator
Utilized during the creation of root and subordinate CA certificates
Defined on the signing CA where you sign and issue the certificate (not the CA where the request is granted)
Once you have created your CAPolicy.inf file, you must copy it into the %systemroot% folder of your server before you install ADCS or renew the CA certificate.
The CAPolicy.inf makes it possible to specify and configure a wide variety of CA attributes and options. The following section describes all the options for you to create an .inf file tailored to your specific needs.
CAPolicy.inf File Structure
The following terms are used to describe the .inf file structure:
Section – is an area of the file that covers a logical group of keys. Section names in .inf files are identified by appearing in brackets. Many, but not all, sections are used to configure certificate extensions.
Key – is the name of an entry and appears to the left of the equal sign.
Value – is the parameter and appears to the right of the equal sign.
In the example below, [Version] is the section, Signature is the key, and «$Windows NT$» is the value.
Version
Identifies the file as an .inf file. Version is the only required section and must be at the beginning of your CAPolicy.inf file.
PolicyStatementExtension
Lists the policies that have been defined by the organization, and whether they are optional or mandatory. Multiple policies are separated by commas. The names have meaning in the context of a specific deployment, or in relation to custom applications that check for the presence of these policies.
For each policy defined, there must be a section that defines the settings for that particular policy. For each policy, you need to provide a user-defined object identifier (OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. The URL can be in the form of an HTTP, FTP, or LDAP URL.
If you are going to have descriptive text in the policy statement, then the next three lines of the CAPolicy.inf would look like:
If you are going to use a URL to host the CA policy statement, then next three lines would instead look like:
Multiple URL and Notice keys are supported.
Notice and URL keys in the same policy section are supported.
URLs with spaces or text with spaces must be surrounded by quotes. This is true for the URL key, regardless of the section in which it appears.
An example of multiple notices and URLs in a policy section would look like:
CRLDistributionPoint
You can specify CRL Distribution Points (CDPs) for a root CA certificate in the CAPolicy.inf. After installing the CA, you can configure the CDP URLs that the CA includes in each certificate issued. The root CA certificate shows the URLs specified in this section of the CAPolicy.inf file.
Some additional information about this section:
Does not support HTTPS URLs.
Quotes must surround URLs with spaces.
If no URLs are specified – that is, if the [CRLDistributionPoint] section exists in the file but is empty – the CRL Distribution Point extension is omitted from the root CA certificate. This is usually preferable when setting up a root CA. Windows does not perform revocation checking on a root CA certificate, so the CDP extension is superfluous in a root CA certificate.
CA can publish to FILE UNC, for example, to a share that represents the folder of a website where a client retrieves via HTTP.
Only use this section if you are setting up a root CA or renewing the root CA certificate. The CA determines the subordinate CA CDP extensions.
AuthorityInformationAccess
You can specify the authority information access points in the CAPolicy.inf for the root CA certificate.
Some additional notes on the authority information access section:
Multiple URLs are supported.
HTTP, FTP, LDAP and FILE URLs are supported. HTTPS URLs are not supported.
This section is only used if you are setting up a root CA, or renewing the root CA certificate. Subordinate CA AIA extensions are determined by the CA which issued the subordinate CA’s certificate.
URLs with spaces must be surrounded by quotes.
If no URLs are specified – that is, if the [AuthorityInformationAccess] section exists in the file but is empty – the Authority Information Access extension is omitted from the root CA certificate. Again, this would be the preferred setting in the case of a root CA certificate as there is no authority higher than a root CA that would need to be referenced by a link to its certificate.
certsrv_Server
Another optional section of the CAPolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed. None of the keys in this section are required. Many of these settings have default values that are sufficient for most needs and can simply be omitted from the CAPolicy.inf file. Alternatively, many of these settings can be changed after the CA has been installed.
An example would look like:
RenewalKeyLength sets the key size for renewal only. This is only used when a new key pair is generated during CA certificate renewal. The key size for the initial CA certificate is set when the CA is installed.
When renewing a CA certificate with a new key pair, the key length can be either increased or decreased. For example, if you have set a root CA key size of 4096 bytes or higher, and then discover that you have Java apps or network devices that can only support key sizes of 2048 bytes. Whether you increase or decrease the size, you must reissue all the certificates issued by that CA.
RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of the new root CA certificate when renewing the old root CA certificate. It only applies to a root CA. The certificate lifetime of a subordinate CA is determined by its superior. RenewalValidityPeriod can have the following values: Hours, Days, Weeks, Months, and Years.
CRLPeriod and CRLPeriodUnits establish the validity period for the base CRL. CRLPeriod can have the following values: Hours, Days, Weeks, Months, and Years.
CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period of the delta CRL. CRLDeltaPeriod can have the following values: Hours, Days, Weeks, Months, and Years.
Each of these settings can be configured after the CA has been installed:
Remember to restart Active Directory Certificate Services for any changes to take effect.
LoadDefaultTemplates only applies during the install of an Enterprise CA. This setting, either True or False (or 1 or 0), dictates if the CA is configured with any of the default templates.
In a default installation of the CA, a subset of the default certificate templates is added to the Certificate Templates folder in the Certification Authority snap-in. This means that as soon as the AD CS service starts after the role has been installed a user or computer with sufficient permissions can immediately enroll for a certificate.
You may not want to issue any certificates immediately after a CA has been installed, so you can use the LoadDefaultTemplates setting to prevent the default templates from being added to the Enterprise CA. If there are no templates configured on the CA then it can issue no certificates.
AlternateSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1 signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes the PKCS#1 V2.1 signature format.
ForceUTF8 changes the default encoding of relative distinguished names (RDNs) in Subject and Issuer distinguished names to UTF-8. Only those RDNs that support UTF-8, such as those that are defined as Directory String types by an RFC, are affected. For example, the RDN for Domain Component (DC) supports encoding as either IA5 or UTF-8, while the Country RDN (C) only supports encoding as a Printable String. The ForceUTF8 directive will therefore affect a DC RDN but will not affect a C RDN.
EnableKeyCounting configures the CA to increment a counter every time the CA’s signing key is used. Do not enable this setting unless you have a Hardware Security Module (HSM) and associated cryptographic service provider (CSP) that supports key counting. Neither the Microsoft Strong CSP nor the Microsoft Software Key Storage Provider (KSP) support key counting.
Create the CAPolicy.inf file
Before you install AD CS, you configure the CAPolicy.inf file with specific settings for your deployment.
Prerequisite: You must be a member of the Administrators group.
On the computer where you are planning to install AD CS, open Windows PowerShell, type notepad c:\CAPolicy.inf and press ENTER.
When prompted to create a new file, click Yes.
Enter the following as the contents of the file:
Click File, and then click Save As.
Navigate to the %systemroot% folder.
Ensure the following:
File name is set to CAPolicy.inf
Save as type is set to All Files
Encoding is ANSI
Click Save.
When you are prompted to overwrite the file, click Yes.