SSL cертификат для Apache в Microsoft Certification Authority

SSL cертификат для Apache в Microsoft Certification Authority

В случае, если у организации поднят и настроен локальный центр сертификации CA (Инфраструктура открытых ключей, англ. Public Key Infrastructure, PKI), можно использовать его для выпуска SSL сертификатов для локальных веб серверов на базе Apache.

1. Создать запрос SSL сертификата;
2. Отправить запрос на сервер CA ;
3. Конвертировать SSL сертификат в формат понятный apache;
4. Прописать полученный SSL сертификат в apache.

New-SelfSignedCertificate: командлет PowerShell для генерации самоподписанного сертификата

Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).

Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:

Get-Command -Module PKI

Самоподписанные сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.

Для создания сертификата нужно указать значения –DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и —CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат). Командлет можно использовать для создания самоподписанного сертификата в Windows 10 (в нашем примере), Windows 8/8.1 и Windows Server 2019/2016/2012 R2.

Чтобы создать новый SSL сертификат типа SSLServerAuthentication (по умолчанию) для DNS имени test.contoso.com (указывается FQDN имя) и поместить его в список персональных сертификатов компьютера, выполните команду:

New-SelfSignedCertificate -DnsName test.contoso.com -CertStoreLocation cert:LocalMachineMy

Directory: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy
Thumbprint Subject

Если вы указали нестандартный криптографический провайдер CSPs (например, с помощью параметров -KeyAlgorithm «ECDSA_secP256r1» -Provider ‘Microsoft Smart Card Key Storage Provider’ ), убедитесь, что он установлен на компьютере (по умолчанию используется CSP Microsoft Enhanced Cryptographic Provider). Иначе появится ошибка:

По-умолчанию генерируется самоподписанный сертификат со следующим параметрами:

• Криптографический алгоритм: RSA;
• Размер ключа: 2048 бит;
• Допустимые варианты использования ключа: Client Authentication и Server Authentication;
• Сертификат может использоваться для: Digital Signature, Key Encipherment ;
• Срок действия сертификата: 1 год.

Данная команда создаст новый сертификат и импортирует его в персональное хранилище компьютера. Откройте оснастку certlm.msc и проверьте, что в разделе Personal хранилища сертификатов компьютера появился новый сертификат.

С помощью командлета Get-ChildItem можно вывести все параметры созданного сертификата по его отпечатку (Thumbprint):

Get-ChildItem -Path «Cert:LocalMachineMy» | Where-Object Thumbprint -eq DC1A0FDE0120085A45D8E14F870148D1EBCB82AE | Select-Object *

$todaydate = Get-Date
$add3year = $todaydate.AddYears(3)
New-SelfSignedCertificate -dnsname test.contoso.com -notafter $add3year -CertStoreLocation cert:LocalMachineMy

Можно создать цепочку сертфикатов. Сначала создается корневой сертификат (CA), а на основании него генерируется SSL сертификат сервера:

$rootCert = New-SelfSignedCertificate -Subject «CN=TestRootCA,O=TestRootCA,OU=TestRootCA» -KeyExportPolicy Exportable -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm ‘RSA’ -HashAlgorithm ‘SHA256’ -Provider «Microsoft Enhanced RSA and AES Cryptographic Provider» `
New-SelfSignedCertificate -CertStoreLocation cert:LocalMachineMy -DnsName «test2.contoso.com» -Signer $rootCert -KeyUsage KeyEncipherment,DigitalSignature

Для экспорта полученного сертификата c закрытым ключом в pfx файл, защищенный паролем, нужно получить его отпечаток (Thumbprint). Сначала нужно указать пароль защиты сертификата и преобразовать его в формат SecureString. Значение Thumbprint нужно скопировать из результатов выполнения команды New-SelfSignedCertificate.

$CertPassword = ConvertTo-SecureString -String “YourPassword” -Force –AsPlainText

Export-PfxCertificate -Cert cert:LocalMachineMy2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:test.pfx -Password $CertPassword

Можно экспортировать открытый ключ сертификата:

Export-Certificate -Cert Cert:LocalMachineMy2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:testcert.cer

Проверьте, что в указанном каталоге появился cer(PFX)файл сертификата. Если щелкнуть по нему правой клавишей и выбрать пункт меню Install Certificate, можно с помощью мастера импорта сертификатов добавить сертификат в корневые доверенные сертификаты компьютера.

Выберите Store location -> Local Machine, Place all certificates in the following store -> Trusted Root Certification Authorities.

Полученный открытый ключ или сам файл сертификата можно распространить на все компьютеры и сервера в домене с помощью GPO (пример установки сертификата на компьютеры с помощью групповых политик).

Одной из полезных возможностей командлета New-SelfSignedCertificate является возможность создать сертификат с несколькими различными именами Subject Alternative Names (SAN).

Если создается сертификат с несколькими именами, первое имя в параметре DnsName будет использоваться в качестве CN (Common Name) сертификата. К примеру, создадим сертификат, у которого указаны следующие имена:

• Subject Name (CN): adfs1.contoso.com
• Subject Alternative Name (DNS): web-gw.contoso.com
• Subject Alternative Name (DNS): enterprise-reg.contoso.com

Команда создания сертификата будет такой:

New-SelfSignedCertificate -DnsName adfs1.contoso.com,web_gw.contoso.com,enterprise_reg.contoso.com -CertStoreLocation cert:LocalMachineMy

Также можно сгенерировать wildcard сертификат для всего пространства имен домена, для этого в качестве имени сервера указывается *.contoso.com.

New-SelfSignedCertificate -certstorelocation cert:localmachinemy -dnsname *.contoso.com

1.4. Изготовление кросс-сертификата в иерархической модели

Изготовление кросс-сертификата в иерархической модели (сертификата подчиненного Центра Сертификации) выполняется путем выполнения штатной процедуры регистрации уполномоченного лица подчиненного удостоверяющего центра как пользователя УЦ и изготовления ему сертификата открытого ключа по запросу на сертификат. Для обеспечения возможности издания сертификата уполномоченного лица подчиненного удостоверяющего центра необходимо предварительно выполнить настройку программного обеспечения Центра Сертификации в соответствии с разделом «Настройка Центра Сертификации для выпуска сертификатов подчиненных ЦС» ЖТЯИ.00035-01 90 03. КриптоПро УЦ. Центр сертификации. Руководство по эксплуатации на платформе MS Windows Server 2003 или ЖТЯИ.00035-01 90 04. КриптоПро УЦ. Центр сертификации. Руководство по эксплуатации на платформе MS Windows 2000 Server, и программного обеспечения Центра Регистрации в соответствии с разделом «Настройка параметров Центра Регистрации для выпуска сертификатов открытых ключей уполномоченных лиц подчиненных УЦ» ЖТЯИ.00035-01 90 05. КриптоПро УЦ. Центр Регистрации. Руководство по эксплуатации.

Установка корневого центра сертификации Microsoft CA на MS Windows Server 2008 R2

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

1. Создать файл политик центра сертификации.
2. Установить автономный корневой Центр сертификации (со службой сертификации и службой регистрации в центре сертификации через Интернет) MS Windows Server 2008 R2. Настроить службу на автоматический выпуск сертификатов.
3. Настроить службу на автоматический выпуск сертификатов.
4. Включить аудит работы службы, сделать настройки безопасности.
5. Добавить ссылки на точку распространения отозванных сертификатов и корневого сертификата центра сертификации, которые будут добавляться в каждый выпущенный сертификат.

Создание файла политик CAPolicy.inf корневого ЦС

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

Содержимое файла CAPolicy.inf будет следующим:

[Version] Signature=”$Windows NT$”

Установка службы сертификации из состава MS Windows

Установка службы сертификации производится с использованием Мастера компонентов Windows в следующей последовательности:

1. Открыть окно Панели управления, выполнив команды Пуск , Панель управления .
2. В окне Панели управления открыть пункт Администрирование и выбрать Диспетчер сервера .
3. Выбрать пункт Роли . В правой части окна нажать Добавить роли и выделить пункт Службы сертификации Active Directory . В следующем окне мастера выбрать пункты Центр Сертификации — и Служба регистрации в центре сертификации через Интернет .

OU= название отдела

На сообщение о расширенной кодировке имен выбираем Да .

Настройка корневого Центра сертификации

Запускаем центр сертификации: ПускВсе программыАдминистрированиеЦентр сертификации.

Просмотреть настройки Центра сертификации — вызвать контекстное меню и выбрать Свойства .

В окне можно просмотреть выпущенный самоподписанный сертификат корневого Центра сертификации и проверить, какая информация легла в сертификат из файла политик CAPolicy.inf и при установке Центра сертификации.

Настроить Модуль политики на выдачу сертификатов в автоматическом режиме. Установить переключатель в строку Следовать параметрам…

Перейти в закладку Аудит . Включить протоколирование событий безопасности. Активировать события безопасности, кроме Сохранение и восстановление архивированных ключей и Запуск и остановка службы сертификатов Active Directory

Перейди в закладку Безопасность . Разрешите Администратору запрашивать сертификаты:

Настройка публикации списка отозванных сертификатов

Перейти в закладку Расширения . В меню Выберите расширение выбрать Точка распространения списка отзыва (CDP). Удалить точки распространения, кроме C:Windows .Добавить путь, например, http://servername /Public/Certname.crl , где servername – сервер, на котором будет настроено публичное хранилище, а Certname – название сертификата.

Включить настройки Включать в CDP-расширение выданных сертификатов и Включать в расширения IDP выданных CRL . Перезапустить центр сертификации.

В дополнение к CDP, необходимо сконфигурировать дополнение, включающее информацию о локализации сертификата ЦС AIA. Для этого в поле Выберите расширение перейти к Authority Information Access (AIA) . Удалить доступы к сведениям о центрах сертификации, кроме C:Windows…. Добавить путь, например, http://servername/Public/Certname.ce , где servername – сервер, на котором будет настроено публичное хранилище, а Certname – название сертификата.

Включить настройки Включать в AIA-расширение выданных сертификатов . Перезапустить Центр сертификации.

Поскольку значения дополнений CDP и AIA изменены, то для учета изменений необходимо выпустить и опубликовать CRL. Для публикации CRL необходимо в дереве консоли Центра сертификации нажать правой кнопкой мыши на узел Отозванные сертификаты . В появившемся меню выбрать Все задачи — Публикация

Оставить по умолчанию тип публикуемого CRL – Новый базовый CRL. Нажать кнопку ОК .

Для просмотра и изменения параметров публикации CRL в окне контекстного меню выберем Свойства .

Посмотреть выпущенные списки отозванных сертификатов можно в закладке Просмотр списков отзыва сертификатов (CRL).

Списки отозванных сертификатов размещены в папке C:WindowsSystem32CertsrvCertEnroll , куда по умолчанию публикуются списки.

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

Предполагается, что компьютер с именем 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 файлы

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

Для Windows 2008 строка будет с двумя знаками %% для переменных certutil -setreg CACRLPublicationURLs «65:%windir%system32CertSrvCertEnroll%%3%%8%%9.crln65:C:CertData%%3%%8%%9.crln2:http://pki.test.local/%%3%%8%%9.crl»
и также для certutil -setreg CACACertPublicationURLs «1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:http://pki.test.local/%%3%%4.crt»
Поскольку мы не можем управлять публикацией CRT файлов, мы его переименовываем в нужное имя и копируем в папку CertData

задаём срок действия издаваемых сертификатов равным 15 лет

Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)

Примечание: Данные параметр может быть изменены и через реестр в ветке HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration

Включаем полный аудит для сервера CA

Отключаем генерацию кросс-сертификатов

Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва

Включаем поддержку сертификатов OCSP Response Signing на Offline CA:

Публикуем новый CRL в новую локацию.

Записки IT специалиста

• Автор: Уваров А.С.
• 19.11.2010

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

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

Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

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

Центр сертификации (ЦС) может быть двух типов: ЦС предприятия и изолированный (автономный) ЦС, рассмотрим их отличительные особенности:

ЦС предприятия

• Требует наличия ActiveDirectory
• Автоматическое подтверждение сертификатов
• Автоматическое развертывание сертификатов
• Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

• Не требует наличия ActiveDirectory
• Ручное подтверждение сертификатов
• Отсутствие возможности автоматического развертывания
• Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

Для возможности использования Web-интерфейса для выдачи сертификатов нам понадобится установленный web-сервер IIS. Установим его через диспетчер сервера: Пуск — Управление данным сервером — Добавить или удалить роль.
В списке ролей выбираем роль Сервера приложений. В следующем окне устанавливаем галочку Включить ASP.NET, если IIS уже установлен данный шаг можно пропустить.

После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ — Установка компонентов Windows, где выбираем Службы сертификации.

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

Далее вводим имя ЦС (должно совпадать с именем сервера) и пути размещения файлов. В процессе установки программа предложит перезапустить IIS и, если не была включена поддержка страниц ASP.NET, предложит ее включить, с чем следует согласиться.

Windows Server 2008 R2

В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера — Роли — Добавить роли, в списке ролей выбираем Службы сертификации Active Directory.

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

Дальнейшая настройка аналогична Windows Server 2003. Вводим тип ЦС, его имя и место хранения файлов, подтверждаем выбор компонент и завершаем установку.

Проверка работы ЦС

Для первоначальной проверки работоспособности ЦС можете запустить оснастку Центр сертификации (Пуск — Администрирование — Центр Сертификации). Если все сделано правильно вы должны увидеть следующее окно:
Попробуем теперь получить сертификат для клиентского ПК. Запустим браузер, в адресной строке которого укажем адрес http://имя_сервера/certsrv, где имя_сервера — имя сервера ЦС. Вы попадете на главную страницу центра сертификации.
Прежде всего необходимо загрузить сертификат ЦС и поместить его в хранилище доверенных коренных центров сертификации. Если в вашей сети несколько ЦС следует загрузить и установить цепочку сертификатов. Для этого выбираем: Загрузка сертификата ЦС, цепочки сертификатов или CRL, затем Загрузка сертификата ЦС или Загрузка сертификата ЦС и сохраняем сертификат в любое удобное место.

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

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

При попытке создать запрос сертификата вы можете получить следующее предупреждение:

В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

Теперь на сервере откроем оснастку Центр сертификации и в разделе Запросы на ожидание найдем наш запрос и щелкнув на него правой кнопкой выберем Все задачи — Выдать.

Теперь вернемся на клиентский ПК и еще раз откроем сайт ЦС. На этот раз выберем Просмотр состояния ожидаемого запроса сертификата, вы увидите свой запрос, щелкнув на которой вы попадете на страницу Сертификат выдан и сможете сразу его установить.

Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

При установке SSL-сертификата в Мастере сертификатов IIS может появиться следующая ошибка: ожидающий запрос сертификата для этого файла ответа не найден. ( The pending certificate request for this response file was not found )

Эта ошибка указывает, что ожидающий запрос, который был создан при первоначальной регистрации или обновлении сертификата, был поврежден или удален. По-прежнему можно установить сертификат из командной строки с помощью certutil.exe.

1. Загрузите сертификат SSL из DigiCert Trust Center в формате X.509 в папку. Назовите файл sslcert.cer.
2. Загрузите правильные промежуточные сертификаты CA для сертификата SSL (полный Шаг 1 Вызовите файлы primarycacert.cer и secondarycacert.cer.
3. Откройте командную строку (нажмите «Пуск», выберите «Выполнить», введите cmd и нажмите «ОК»).
4. Перейдите к папке, используемой в шагах 1 и 2, затем выполните следующие три команды:
   certutil -addstore my sslcert.cer
   certutil -addstore ca primarycacert.cer
   certutil -addstore ca secondarycacert.cer
   

Команда должна выглядеть так:
certutil -repairstore my «00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f»

Если команда завершена успешно, появится следующее сообщение:
CertUtil: -repairstore command completed successfully.

• CertUtil: -repairstore command FAILED: 0x80090011 (-2146893807)
• CertUtil: Object was not found.
• CertUtil: -repairstore command FAILED: 0x8009000b (-2146893811)
• CertUtil: Key does not exist.

Copyright © 1997-2021 adgrafics