Active Directory Certificate Services / Argon / Blog

Что такое запрос на подпись сертификата (csr)?

Запрос на подпись сертификата (CSR – Certificate Signing Request) содержит наиболее важную информацию о вашей организации и домене. Это зашифрованный блок текста, который включает информацию о вашей организации, такую как страна, адрес электронной почты, полное доменное имя и так далее Он отправляется в центр сертификации при подаче заявки на сертификат SSL.

Обычно вы генерируете пару CSR и ключ локально на сервере, где будет установлен сертификат SSL. Однако это не строгое правило. Вы можете сгенерировать пару CSR и ключ на одном сервере и установить сертификат на другом. Однако это усложняет ситуацию. Мы рассмотрим и этот сценарий.

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

Закрытый ключ должен соответствовать CSR, с которым он был создан, и, в конечном счете, он должен соответствовать сертификату, созданному из CSR. Если закрытый ключ отсутствует, это может означать, что сертификат SSL не установлен на том же сервере, который сгенерировал запрос на подпись сертификата.

CSR обычно содержит следующую информацию:

Что такое сертификат ssl? как работает ssl?

Сертификат Secure Socket Layer (SSL) – это протокол безопасности, который защищает данные между двумя компьютерами с использованием шифрования.

Проще говоря, сертификат SSL – это файл данных, который в цифровом виде связывает криптографический ключ с сервером или доменом, а также с названием и местонахождением организации.

Как правило, сертификаты SSL используются на веб-страницах, которые передают и получают конфиденциальные данные конечного пользователя, такие как номер социального страхования, данные кредитной карты, домашний адрес или пароль. Онлайн формы оплаты являются хорошим примером и обычно шифруют вышеупомянутую деликатную информацию с использованием 128 или 256-битной технологии SSL.

Сертификаты SSL обеспечивают идентификацию удаленного компьютера, чаще всего сервера, но также подтверждают идентификацию вашего компьютера с удаленным компьютером для установления безопасного соединения. Обеспечение безопасности в Интернете всегда было улицей с двусторонним движением, и благодаря SSL-шифрованию сервер «пожимает руку» вашему персональному компьютеру, и обе стороны знают, с кем они общаются.

Apache

При использовании библиотеки OpenSSL в Apache закрытый ключ по умолчанию сохраняется в /usr/local/ssl. Запустите openssl version –a, команду OpenSSL, которая определяет, какую версию OpenSSL вы используете.

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

OpenSSL 1.0.2g  1 Dec 2021

built on: reproducible build, date unspecified

platform: debian-amd64

options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)

compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -

D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-

strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-

Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -

DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -

DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -

DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM

OPENSSLDIR: "/usr/lib/ssl"

Последняя строка OPENSSLDIR определяет путь к файлу. В приведенном примере это местоположение по умолчанию /usr/lib/ssl.

Firefox

Даже после того, как вы установите доверенный источник сертификата в хранилище, Firefox все равно будет выдавать предупреждения. Этого может не случиться в Windows 10, но почти наверняка случится в macOS. Справиться с этим достаточно просто. Firefox демонстрирует вот такой экран:

Чтобы добавить разрешения сертификату, кликните «Дополнительно…». Сразу же после этого кликните на «Принять риск и продолжить», чтобы дать понять, что вы знаете о риске.

Это нужно сделать всего один раз, но для каждого локального домена.

Macos — chrome и safari

1. Дважды кликните на корневом сертификате (ca.crt).

2. Выберите нужную связку ключей [keychain] (login, если вы хотите, чтобы сертификат считался доверенным только в вашем аккаунте, или System, если сертификат должен считаться доверенным во всей системе).

3. Добавьте сертификат.

4. Откройте «Keychain Access» (если еще не открыт).

5. Выделите keychain, который выбрали раньше.

6. Вы должны увидеть сертификат MY-CA (это будет имя, которое вы, как CN, дали вашему источнику сертификата).

7. Дважды кликните по сертификату.

8. Разверните «Доверять» и выберите опцию «Доверять всегда» в пункте «При использовании этого сертификата».

9. Закройте окно сертификата и введите свой пользовательский пароль (если требуется).

Nginx

Вы сможете найти местоположение личного ключа вашего сервера в файле виртуального хоста вашего домена.

Перейдите к местоположению корневого сервера сайта (обычно это каталог /var/www/) и откройте основной файл конфигурации сайта. Найдите директиву ssl_certificate_key, которая предоставит путь к файлу закрытого ключа.

Если вы не можете найти директиву ssl_certificate_key, возможно, существует отдельный файл конфигурации для деталей SSL. Ищите что-нибудь вроде ssl.conf.

Ru-center – часто задаваемые вопросы о ssl-сертификатах

Windows (iis)

На серверах, работающих под управлением Windows Internet Information Services, операционная система сохраняет закрытый ключ в скрытой папке, так же как любая обычная ОС Windows хранит важные системные данные.

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

1. Откройте консоль управления MMC (Microsoft Management Console).
2. Разверните дерево Сертификаты (локальный компьютер), расположенное в корне консоли.
3. Ваш сертификат находится либо в личной папке, либо в папке веб-хостинга. Вы можете идентифицировать каждый сертификат по его Common name (домену)
4. Щелкните правой кнопкой мыши сертификат, который вы хотите экспортировать, и выберите Все задачи -> Экспорт.
5. Следуйте инструкциям мастера для экспорта файла .pfx.

Теперь у вас есть то, что вам нужно, если вы хотите сохранить резервную копию или установить сертификат на другом сервере Windows.

Если вам нужно установить сертификат на другом сервере, который не работает под управлением Windows (например, Apache), вам необходимо сконвертировать файл .pfx и разделить файлы .key и .crt или .cer. Вы можете сделать это с OpenSSL.

Windows 10 — chrome, ie11 и edge

1. Дважды кликните на сертификате (ca.crt).

2. Кликните на кнопку «Установить сертификат».

3. Выберите, хотите ли вы хранить его на уровне пользователя или на уровне машины.

4. Кликните «Дальше».

5. Выберите «Разместить все сертификаты в следующем хранилище».

6. Кликните «Обзор».

7. Выберите «Доверенные корневые источники сертификатов».

8. Кликните «ОК».

9. Кликните «Дальше».

10. Кликните «Завершить».

11. Если появится подсказка, кликните «Да».

Автоматический запрос сертификатов

От центра сертификации нет толку, если клиентские компьютеры в вашей сети не имеют к нему доверия и/или не получают сертификаты. При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС и автоматический запрос сертификатов компьютера у него.

Вариант 1: создать csr

Первое, что нужно сделать, – это создать 2048-битную пару ключей RSA локально. Эта пара будет содержать как ваш закрытый, так и открытый ключ. Вы можете использовать инструмент Java key или другой инструмент, но мы будем работать с OpenSSL.

Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:

openssl req –out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key

Что эта команда означает:

• openssl – активирует программное обеспечение OpenSSL
• req – указывает, что мы хотим CSR
• –out – указывает имя файла, в котором будет сохранен ваш CSR. У нас в примере это certificatesigningrequest.csr
• –new –newkey – создать новый ключ
• rsa:2048 – cгенерировать 2048-битный математический ключ RSA
• –nodes – нет DES, то есть не шифровать закрытый ключ в PKCS#12 файл
• –keyout – указывает домен, для которого вы генерируете ключ

Далее ваша система должна запустить текстовую анкету для заполнения, которую мы описывали в таблице выше:

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

После завершения работы программы вы сможете найти файл CSR в вашем рабочем каталоге. Запрос на подпись сертификата, сгенерированный с помощью OpenSSL, всегда будет иметь формат файла .csr. Чтобы найти в папке все файлы этого формата используйте команду

ls *.csr

Тут будет список всех сертификатов, останется только найти тот, что мы только что сгенерировали.

Также вы можете открыть файл .csr в текстовом редакторе, например nano, чтобы просмотреть сгенерированный буквенно-цифровой код.

sudo nano your_domain.csr

После того, как вы сгенерировали CSR с парой ключей, сложно увидеть, какую информацию она содержит, поскольку она не будет в удобочитаемом формате. Вы можете легко декодировать CSR на своем сервере, используя следующую команду OpenSSL:

openssl req -in server.csr -noout -text

Далее можно декодировать CSR и убедиться, что он содержит правильную информацию о вашей организации, прежде чем он будет отправлен в центр сертификации. В Интернете существует множество CSR-декодеров, которые могут помочь вам сделать то же самое, просто скопировав содержимое файла CSR, например sslshopper.

Вариант 4: генерация самоподписанного(self-signed) сертификата

Самозаверяющий сертификат обычно используется для сред тестирования и разработки, а также в интрасети. Давайте создадим самозаверяющий сертификат, используя следующую команду OpenSSL:

openssl req -newkey rsa:2048 -nodes -keyout domain.key-x509 -days 365 -out domain.crt

Параметр –days установлен на 365, что означает, что сертификат действителен в течение следующих 365 дней. Параметр x509 указывает, что это будет самозаверяющий сертификат. Временный CSR генерируется, и он используется только для сбора необходимой информации. Если вы не хотите защищать свой закрытый ключ паролем, вы можете добавить параметр –nodes.

Центры сертификации не проверяют самоподписанные сертификаты. Таким образом, они не так безопасны, как проверенные сертификаты. Если ЦС не подписал сертификат, каждый основной браузер отобразит сообщение об ошибке «Ненадежный сертификат», как показано на рисунке ниже.

Внимание!

Особенность такого построения серверов (когда корневой сервер находится в отключенном режиме) является то, что периодически придётся вречную его запускать и выгружать обновлённый файл отозванных сервтификатов ROOT-TEST-CA.crt на общее хранилище. Для этого достаточно примерно за месяц до истечения действия текущего файла запустить сервер корневого ЦС и скопировать обновлённый файл из папки  C:CertData. Если файл автоматически не обновился при запуске сервера, то обновить его командой

certutil –CRL

Где получить сертификат ssl?

Сертификаты SSL проверяются и выдаются Центром сертификации (CA – Certificate Authorities). Вы подаете заявку, генерируя CSR (Certificate Signing Request – запрос на получение сертификата) с парой ключей на вашем сервере, которая в идеале будет содержать сертификат SSL. CSR содержит важные организационные детали, которые CA проверяет.

Доверие к сертификатам

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

Другие виды сертификатов

Напоследок хотелось бы сказать, что помимо обозначенной градации сертификатов — DV, OV, EV — существуют и другие типы сертификатов. Например, сертификаты могут отличаться по количеству доменов, на которые они выдаются. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, указываемому при покупке.

сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, но за каждое наименование, включаемое в список сверх обозначенного количества, придется доплачивать отдельно.

Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать помимо доменов несколько поддоменов.

В таких случаях стоит приобретать сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL. Отметим, что в этом случае можно также приобрести обычный мультидоменный сертификат, в котором просто указать необходимые поддомены.

Получить SSL-сертификат можно и самостоятельно: пара ключей для этого получается через любой генератор, например, бесплатный OpenSSL. Такие защищенные каналы связи можно с легкостью использовать для внутренних нужд компании: для обмена между устройствами сети или приложениями.

P.S. Несколько материалов по теме из нашего блога:

Закрытый ключ

Закрытый ключ кодируется и создается в формате PEM на основе Base-64, который не читается человеком. Вы можете открыть его в любом текстовом редакторе, но все, что вы увидите, это несколько десятков строк, которые кажутся случайными символами, заключенными в открывающие и закрывающие заголовки. Ниже приведен пример закрытого ключа:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG yY/6OBQoPKcx4Jv2h
vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB MVFHTJvKjQ eY9p
dWA3NbQusM9uf8dArm 3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB
AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa 6pO5
5bShQyQSCkxa9f2jnBorKK4 0K412TBM/SG6Zjw DsZd6VuoZ7P027msTWQrMBxg
Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w 7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM
S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B vee/q5edQA2OIaDgNmn
AurEtUaRAkEAn7/65w Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq iNWdcSE6xE
2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe
f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG
DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x
TAUq7IMYHtCHZwxkNQJBAORwE 6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5
lr  9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU=
-----END RSA PRIVATE KEY-----

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

Запрос сертификата с альтернативным именем

Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).

По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:

certutil -setreg policyEditFlags EDITF_ATTRIBUTESUBJECTALTNAME2net stop certsvcnet start certsvc

Использование сертификата

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

Вот несколько примеров:

Источник сертификата (certificate authority)

1. Создайте закрытый ключ и самоподписанный сертификат

openssl req -x509 -nodes -new -sha512 
-days 365 -newkey rsa:4096 -keyout ca.key 
-out ca.pem -subj "/C=US/CN=MY-CA"

Опционально: если необходимо, можно заменить MY-CA в CN на что-нибудь другое.

Если вам захочется проверить информацию сертификата, его содержимое можно вывести, запустив следующий код:

openssl x509 -in ca.pem -text -noout

2. Создайте файл сертификата с расширением .crt:

openssl x509 -outform pem -in ca.pem -out ca.crt

Как скопировать содержимое файла csr

Откройте каталог, в котором находится ваш CSR-файл. Введите следующую команду:

sudo cat domain.csr

Замените domain параметром FQDN вашего CSR. Эта команда отобразит содержимое файла CSR. Скопируйте весь контент, начиная с BEGIN CERTIFICATE REQUEST и заканчивая END CERTIFICATE REQUEST.

Как создать csr

Запросы на подпись сертификата (CSR) создаются с помощью пары ключей – открытого и закрытого ключа. Только открытый ключ отправляется в центр сертификации и включается в сертификат SSL, и он работает вместе с вашим личным ключом для шифрования соединения. Любой может иметь доступ к вашему открытому ключу, и он проверяет подлинность SSL-сертификата.

Закрытый ключ – это блок закодированного текста, который вместе с сертификатом проверяет безопасное соединение между двумя компьютерами. Он не должен быть общедоступным, и его не следует отправлять в ЦС.

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

Большинство пар ключей состоят из 2048 битов. Хотя пары ключей длиной 4096 бит более безопасны, они замедляют SSL-рукопожатия и создают нагрузку на серверные процессоры. Из-за этого большинство сайтов по-прежнему используют 2048-битные пары ключей.

Как создать сертификат ssl

То, как сгенерировать запрос на подпись сертификата (CSR), зависит исключительно от платформы, которую вы используете, и конкретного выбранного вами инструмента.

Мы будем генерировать CSR с использованием OpenSSL.

OpenSSL – это широко используемый инструмент для работы с CSR-файлами и SSL-сертификатами, который можно загрузить с официального сайта OpenSSL. Это инструмент реализации с открытым исходным кодом для SSL/TLS, который используется примерно на 65% всех активных интернет-серверов, что делает его неофициальным отраслевым стандартом.

Команды openssl для конвертации csr

Если вы работаете с серверами Apache, запросы на подпись сертификатов (CSR) и ключи хранятся в формате PEM. Но что, если вы хотите перенести CSR на сервер Tomcat или Windows IIS? Вам придется конвертировать стандартный файл PEM в файл PFX. Следующие команды помогут вам сделать это.

Примечание: Используйте параметр -nodes, если вы не хотите шифровать файл .key. Если вы не используете этот параметр, вам нужно будет указать пароль.

Конфигурация площадки

Домен: TEST.LOCAL

Серверы: (Автономный) RootCA; (Предприятие) SRV03.TEST.LOCAL

Сетевое хранилище DFS: \test.localSOFTPKI

WEB сервер: совмещён с сервером ЦС домена SRV03.TEST.LOCAL

Об авторе

Вадим Поданс

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

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

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

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

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

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

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

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

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

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

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

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

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

Общие представления о pki

Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:

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

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

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

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

Подготовка web сервера

На серверах DNS (в случае домана – контроллеры домена) создать запись pki.test.local ведущую на IP адрес WEB сервера (в нашем случае SRV03.TEST.LOCAL)

Создасть сайт pki.test.local на WEB сервере, указав в качестве физического сетевой путь \test.localSOFTPKI

Для возможности работы с сетевой папкой необходимо запускать сайт как сетевую службу. Для этого в разделе Пулы приложений – выбрать приложение созданого сайта PKI – Дополнительные параметры. Параметр Модель процесса – Удостоверение установить NetworkService.

Чтобы IIS сервер мог распознавать DeltaCRL необходимо добавить возможность чтения знака ” “. Для этого в оснастке IIS нужно в настройках сайта открыть Фильтрация запросов – Изменить параметры и установить Разрешить двойное преобразование

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

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

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

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

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

New-Item -ItemType Directory -Path C:InetPubwwwroot -Name PKIdata -Force
New-SmbShare -Path C:inetpubwwwrootPKIdata -Name PKI -FullAccess everyone

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

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

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

Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье:

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

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

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

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

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

Преобразовать pem csr и закрытый ключ в pkcs12 (.pfx .p12)

Файлы FKCS12 используются для экспорта или импорта сертификатов в Windows IIS.

openssl pkcs12 -inkey domain.key -in domain.crt -export -out domain.pfx

Эта команда возьмет закрытый ключ и CSR и преобразует его в один файл .pfx. Вы можете настроить экспортную фразу-пароль, но также можете оставить это поле пустым. Обратите внимание, что, объединив строки символов сертификата в конец одного файла PEM, вы можете экспортировать цепочку сертификатов в формат файла .pfx.

Проверить версию openssl

Эта команда отображает версию OpenSSL, и ее параметры, с которыми она была скомпилирована:

openssl version -a

Получим примерно такой вывод:

OpenSSL 1.0.1f 6 Jan 2021
built on: Mon Apr  7 21:22:23 UTC 2021
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Продление сертификата – не используйте старые csr повторно

То, что некоторые веб-серверы позволяют использовать старые CSR для обновления сертификатов, не означает, что вы должны их использовать. В качестве меры безопасности всегда генерируйте новый CSR и закрытый ключ при обновлении сертификата. Привязка к одному и тому же секретному ключу – это дорога, вымощенная уязвимостями безопасности.

Также рекомендуется обновить SSL-сертификат до истечения срока его действия. В противном случае потребуется покупать новый сертификат.

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

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

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку

Enterprise PKI Health

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

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

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

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

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

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

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

HKLMSystemCurrentControlSetServicesCertSvc

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

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

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

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

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

Решение

Подготовка ROOT-CA.   (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет  easy-rsa,  который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

 Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.  

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог – в котором будем хранить наш PKI

mkdir -p ~/ROOTca

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

dir /usr/share/easy-rsa/  

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/* ~/ROOTca

теперь нам необходимо создать файл ответов vars, и отредактировать его

создаем и сразу редактируем

cat > ~/ROOTca/vars

пример файла vars с описанием

собираем файл vars, у меня получилось так:

Ручная установка в панели хостинга

Чтобы установить SSL-сертификат, войдите в вашу панель управления (ISPmanager, cPanel или Plesk*) и следуйте соответствующей инструкции ниже:

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

Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации.

Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:

Сертификат доменного имени

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

1. Создайте файл расширения x509 v3:

cat > v3.ext <<-EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names 
[alt_names]
# Локальные хостинги
DNS.1 = localhost
DNS.2 = 127.0.0.1
DNS.3 = ::1 
# Перечислите доменные имена
DNS.4 = local.dev
DNS.5 = my-app.dev
DNS.6 = local.some-app.dev
EOF

Следуя этому шаблону, можно добавить сколько угодно доменных имен.

Примечание: пожалуйста, обновите DNS.4, DNS.5 и DNS.6 или удалите их, если у вас не настроены никакие локальные доменные имена.

2. Создайте закрытый ключ и запрос на подпись сертификата:

openssl req -new -nodes -newkey rsa:4096 
-keyout localhost.key -out localhost.csr 
-subj "/C=US/ST=State/L=City/O=Some-Organization-Name/CN=localhost"

Опционально: страну, штат, город и организацию можно изменять.

3. Создайте самоподписанный сертификат:

openssl x509 -req -sha512 -days 365 
-extfile v3.ext 
-CA ca.crt -CAkey ca.key -CAcreateserial 
-in localhost.csr 
-out localhost.crt

Система не извлекает закрытый ключ автоматически

Некоторые системы не автоматизируют процедуру извлечения закрытого ключа. Кроме того, если вам нужно установить существующий сертификат на другом сервере, вы, очевидно, не можете ожидать, что он получит закрытый ключ. Основная сложность здесь заключается в том, как найти точное местоположение ключа.

Уровни проверки ssl-сертификатов

Центры сертификации имеют различные уровни проверки сертификатов в ответ на растущий спрос на сертификаты. Некоторые организации используют SSL только для шифрования, в то время как другие хотят показать своим клиентам, что они являются доверенной компанией. Различные потребности привели к различным уровням проверки сертификата.

Установка openssl в debian и ubuntu

Сначала проверим, установлена ли у нас утилита OpenSSL при помощи команды:

dpkg -l |grep openssl

Если пакет OpenSSL установлен, мы получим следующий результат:

ii libgnutls-openssl27:amd64   2.12.23-12ubuntu2.4   amd64   GNU TLS library - OpenSSL wrapper

ii openssl   1.0.1f-1ubuntu2.16   amd64   Secure Sockets Layer toolkit - cryptographic utility

Если вы не видите такого результата, выполните следующую команду для установки OpenSSL:

apt-get install openssl

Установка openssl в red hat и centos

Red Hat (версия 7.0 и более поздние) должна поставляться с предустановленной ограниченной версией OpenSSL. Он предлагает только ограниченную поддержку для IDEA, RC5 и MDC2, поэтому вы можете установить недостающие функции.

Чтобы проверить, установлен ли OpenSSL на сервере yum (например, Red Hat или CentOS), выполните следующую команду:

rpm -qa | grep -i openssl

Эта команда должна вернуть следующий результат:

openssl-1.0.1e-48.el6_8.1.x86_64
openssl-devel-1.0.1e-48.el6_8.1.x86_64
openssl-1.0.1e-48.el6_8.1.i686

Если ваш формат вывода отличается, это означает, что OpenSSL не установлен на вашем сервере. Выполните следующую команду для установки OpenSSL:

yum install openssl openssl-devel

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

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

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

Установка издающих центра сертификации

После установки Центра сертификации (из стостава AD CS) необходимо её настроить.

• ЦС предприятия
  
• Подчиненный ЦС
• Создать новый закрытый ключ
• RSA#Microsoft Software Key Storage Provider; длину ключа в 2048 бит и алгоритм подписи в SHA1
• Имя ЦС: TEST-CA
• Создать запрос сертификата в файле на конечном компьютере
• Период действия сертификата = 10 лет
• Период публикации отозванных сертификатов = 3 месяца

Скопировать файл запроса на сервер RootCA и выпустить по немуц сертификат

• открыть Панель управления–Администрирование–Центр сетрификации
• выбрать сервер-все задачи–Выдать новый запрос… и выбрать файл запроса
• перейти в подраздел запросы в ожидании
• выбелить запрос, затем все задачи – выдать
• перейти в подраздел выданные сертификаты и открыть сетрификат
• на вкладке Состав нажать копировать в файл и сохратить в формате .p7b (TEST-CA.p7b)

Скопировать файл выданного сертификата (TEST-CA.p7b) и файлы из папки C:CertData (ROOT-TEST-CA.crt и ROOT-TEST-CA.crl) в сетевое хранилище \test.localSOFTPKI

После этого сервер RootCA можно выключить.

Зарегистрировать файлы с корневого ЦС на подчинённом сервере (запускать с привилегиями Администратора)

certutil –addstore Root \test.localSOFTPKIROOT-TEST-CA.crt
certutil –addstore Root \test.localSOFTPKIROOT-TEST-CA.crl
certutil -dspublish -f \test.localSOFTPKIROOT-TEST-CA.crt RootCA

Если ошибок не возникло, то установить сертификат ЦС (выданный RootCA)

• открыть Панель управления–Администрирование–Центр сетрификации
• выбрать сервер-все задачи–Установить сертификат ЦС и выбрать файл (TEST-CA.p7b)
• после успешной установки файл .p7b можно удалить

Выполнить пакетный файл настройки для дальнейшей настройки

Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.

Установка корневого центра сертификации

Предполагается, что компьютер с именем RootCA установлен, обновлён и сконфигурированы параметры безопасности. Данный компьютер будет выполнять роль корневого центра сертификации (Root Certification Authority). Поскольку корневой CA — самая важная точка в иерархии PKI, этот сервер будет нормально выключен и включаться только для следующих целей:

• Отправка новой заявки на сертификат;
• Публикация CRL;
• Обновление сертификата самого CA;
• Установка обновлений безопасности.

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

После установки Центра сертификации (из стостава AD CS) необходимо её настроить.

• Автономный ЦС
• Корневой ЦС
• Создать новый закрытый ключ
• RSA#Microsoft Software Key Storage Provider; длину ключа в 2048 бит и алгоритм подписи в SHA1
• Имя ЦС: ROOT-TEST-CA
• Период действия сертификата = 15 лет
• Период публикации отозванных сертификатов = 1 год
  

Последующая настройка выполняется с помощью коммандной строки

Создаём папку в корне диска C, где будут храниться CRT и CRL файлы

md C:CertData

Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.

Установка корневого цс

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

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

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

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

Через mmc

Открыть MMC с правами администратора » добавить оснастку Сертификаты » выбрать в качестве области Локальный компьютер » импортировать нужный сертификат в хранилище Доверенные корневые центры сертификации. Более подробно в статье TechNet Manage Trusted Root Certificates.

Через свойства сертификата

Запустить командную строку с правами админа » вызвать в ней с:pathtocert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.

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

Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке

Certificate Templates MMC

(certtmpl.msc). Рекомендации по шаблонам сертификатов:

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

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

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

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

Если у вас используются современные версии ОС (например, 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.

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

Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора.

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

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

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

Заключение

Теперь, когда сертификат создан и доверие к нему обеспечено, вы без проблем можете посещать свой локальный домен! Обслуживание приложений стало безопасным, и вы можете спокойно продолжать разработку. Возвращаясь к примеру с Express, результат на экране будет таким:

Сайт полностью загружен, и рядом с URL в Chrome теперь отображается символ безопасного соединения.

Расширенная проверка (ev ssl – extended validation)

Центр сертификации проверяет право собственности на домен и проводит тщательное расследование организации, связанной с сертификатом EV. При рассмотрении расширенного запроса проверки соблюдаются строгие правила, и центр сертификации должен проверить следующее:

1. Информация об организации соответствует официальным данным
2. Физическое, юридическое и эксплуатационное существование субъекта
3. Организация имеет исключительные права на использование домена, указанного в сертификате SSL
4. Организация надлежащим образом санкционировала выдачу сертификата EV SSL

Проверка отзыва сертификатов

Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:

Не удалось проверить, не был ли отозван этот сертификат.

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

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

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

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