Как сделать свой центр сертификации
Добавил пользователь Валентин П. Обновлено: 05.10.2024
В этой статье мы рассмотрим что такое сертификаты, какими они бывают, разберем подробно создание сертификата OpenSSL. Причем рассмотрим каждый этап, чтобы вам было легче понять что и как происходит.
Что такое сертификаты?
В этой инструкции мы будем иметь дело с такими видами ключей:
- .pem, .crt, .cer - готовый, подписанный центром сертификации сертификат, расширения разные, но означают одно и то же. Если совсем просто, то сертификат, это подписанный открытый ключ, плюс немного информации о вашей компании;
- .key - закрытый или открытый ключ;
- .csr - запрос на подпись сертификата, в этом файле хранится ваш открытый ключ плюс информация, о компании и домене, которую вы указали.
А теперь рассмотрим как создать сертификат openssl, как его подписать и что для этого нужно сделать. Генерация ключей openssl - это довольно простая задача, если во всем разобраться.
Создание закрытого ключа и запроса на подпись
Вам необязательно подписывать сертификаты в центре сертификации CA, вы можете подписать их сами, но об этом потом. Весь процесс вам так и так придется пройти. Сначала рассмотрим как создать закрытый ключ с нуля, и указать необходимую информацию. Это CN, где должно быть указанно ваше доменное имя, для которого вы собираетесь использовать сертификат, также можно указать дополнительную информацию о вашей компании, адресе и организации, но это уже необязательно.
Чтобы создать закрытый ключ и запрос на подпись открытого ключа выполните такую команду:
openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
Опция -newkey указывает, что нужно создать новую пару ключей, а в параметрах мы сообщаем тип rsa и сложность 2048 байт. Опция -nodes указывает, что шифровать ключ не нужно, опция -new указывает что нужно создать запрос csr. Если у вас уже есть закрытый ключ, то вы можете создать для него csr запрос такой командой:
openssl req -key domain.key -new -out domain.csr
Во время создания вам нужно будет указать всю необходимую информацию для csr, это в первую очередь домен и организация. Можно создавать закрытый ключ отдельно:
openssl genrsa -des3 -out domain.key 2048
openssl x509 -in domain.crt -signkey domain.key -x509toreq -out domain.csr
Параметр -x509toreq указывает, что нужно использовать сертификат для X509 для получения CSR. X509, это сертификаты, подписанные сами собой. Обычно сертификат подписывается другим сертификатом, а этот был подписан сам собой. Если вы получили сертификат от CA, то этот параметр не нужен.
Подпись сертификатов OpenSSL
Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:
openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt
С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:
openssl req -newkey rsa:2048 -nodes -keyout domain.key
-x509 -days 365 -out domain.crt
Или создаем самоподписанный сертификат openssl из существующего закрытого ключа без csr:
openssl req -key domain.key -new -x509 -days 365 -out domain.crt
Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL - подписать его с помощью собственного CA, центра сертификации.
Вот вы сейчас думаете что это что-то такое сложное, да? А нет, это обычная папка, в которой лежит защищенный паролем закрытый ключ, с помощью которого мы будем подписывать все другие ключи. А открытая пара этого ключа должна быть добавлена во все браузеры, которые будут ему доверять.
Вообще, центр сертификации в крупных корпорациях находится на отдельных компьютерах, которые даже к сети не подключены. Но для примера мы разместим папку в нашей файловой системе /etc/:
Дальше нужно создать самоподписанный сертификат openssl для нашего CA:
openssl req -newkey rsa:4096 -x509 -extensions x509_ca -keyout /etc/ca/certs/ca.key -out /etc/ca/certs/ca.crt -days 3654
Параметр -extensions загружает необходимые расширения для создания сертификата центра сертификации. Мы устанавливаем долгий строк действия - десять лет. Осталось подписать наш сертификат, созданный ранее:
openssl ca -extensions x509_client -in ~/domain.csr -out ~/domain.crt
Готово, теперь наш сертификат подписан. Но теперь, чтобы браузеры ему доверяли нужно добавить сертификат CA в список доверенных браузера.
Просмотр сертификатов
Сертификаты сохраняются в формате pem, а это значит, что вы не сможете их открыть как текстовый файл и нужно использовать специальные команды для просмотра информации о них. Сначала смотрим содержимое csr:
openssl req -text -noout -verify -in domain.csr
Смотрим содержимое сертификата в режиме обычного текста:
openssl x509 -text -noout -in domain.crt
Проверяем действительно ли сертификат подписан нужным CA:
openssl verify -verbose -CAfile ca.crt domain.crt
Просмотр закрытого ключа:
openssl rsa -check -in domain.key
Чтобы проверить связаны ли между собой закрытый ключ, сертификат и открытый ключ можно подсчитать сумы md5 для этих ключей, если значения совпадут, то есть вероятность что это ключи из одной пары:
openssl rsa -noout -modulus -in domain.key | openssl md5
$ openssl x509 -noout -modulus -in domain.crt | openssl md5
$ openssl req -noout -modulus -in domain.csr | openssl md5
Выводы
В этой статье мы рассмотрели как выполняется генерация сертификата openssl, какие бывают сертификаты, ключи и как все эти понятия связаны между собой. Это очень сложная и обширная тема, и недостаточно одной статьи чтобы все охватить, но, надеюсь, что теперь вам намного понятнее как это все работает.
Центры сертификации (CA) выдают цифровые сертификаты. Цифровые сертификаты — это верифицируемые файлы данных, которые содержат сведения, чтобы помочь веб-сайтам, людям и устройствам подтвердить свою идентификацию в сети (ее подлинность проверяется центром сертификации). Центры сертификации играют важнейшую роль в работе интернета и в выполнении прозрачных и надежных онлайн-транзакций. Центры сертификации выдают миллионы цифровых сертификатов каждый год, и эти сертификаты используются для защиты информации, шифрования миллиардов транзакций и обеспечения безопасного обмена данными.
Сертификат SSL — это популярный тип цифрового сертификата, который привязывает информацию о владельце веб-сервера (и веб-сайта) к ключу шифрования. Эти ключи используются в ючу шифрования. Эти ключи используются в протоколе SSL/TLS для создания безопасной сессии между браузером и веб-сервером, на котором расположен SSL-сертификат. Чтобы браузер мог доверять SSL-сертификату и выполнял сессию SSL/TLS без предупреждений безопасности, SSL-сертификат должен содержать доменное имя веб-сайта, использующего этот сертификат, должен быть выдан надежным центром сертификации и быть действующим.
Как при таком обилии SSL-сертификатов определить, какому центру сертификации можно доверять?
Перед выпуском цифрового сертификата центр сертификации выполнит множество проверок идентификации заявителя. Эти проверки зависят от класса и типа сертификата, на который подана заявка. Например, для выпуска SSL-сертификата с проверкой домена будет проверяться право владения доменом, отражаемое в сертификате, а сертификат SSL с расширенной проверкой будет включать дополнительную информацию о компании, которая будет проверяться центром сертификации многими разными методами.
Более подробная информация о разных классах SSL-сертификатов содержится в статье: Классы сертификатов и примеры их использования.
PKI и иерархии доверия
Браузеры и устройства доверяют центру сертификации, принимая корневой сертификат в свое хранилище — специальную базу данных об утвержденных центрах сертификации, которая предустановлена в браузерах и на устройствах. Windows поддерживает свое хранилище корневых сертификатов, так же поступают Apple и Mozilla (для своего браузера Firefox). Многие операторы мобильной связи также имеют собственное хранилище.
Хранилище Apple OSX доверенных корневых сертификатов
Центры сертификации используют эти предустановленные корневые сертификаты для выдачи промежуточных корневых сертификатов и цифровых сертификатов конечным объектам. Центры сертификации получают запросы на сертификаты, проверяют заявки, выпускают сертификаты и публикуют текущий статус проверки выпущенных сертификатов, так что каждый, кто пользуется сертификатом, имеет полное представление о действительности этого сертификата.
Обычно центры сертификации создают множество корневых сертификатов промежуточных центров сертификации (ICA), которые выдают сертификаты конечным пользователям, в том числе SSL-сертификаты. Это называется иерархией доверия и выглядит следующим образом:
Центры сертификации не должны выдавать цифровые сертификаты напрямую из корневого сертификата, передаваемого операторам, а только через один или несколько промежуточных центров сертификации (ICA). Центры сертификации обязаны выполнять рекомендации по безопасности чтобы свести к минимуму уязвимость корневого центра сертификации для хакерских атак. GlobalSign — один из немногих центров сертификации, которые всегда (с 1996 года) использовали ICA.
Что входит в работу центра сертификации?
Центры сертификации служат оплотом доверия в интернете и поэтому несут особую ответственность. Работа центра сертификации с соблюдением всех требований к аудиту является сложной задачей. Инфраструктура центров сертификации включает в себя значительное количество операционных элементов, аппаратного и программного обеспечения, политик отправителей и положений о правилах, проверок, элементов инфраструктуры безопасности и персонала. В совокупности эти элементы называются доверенной инфраструктурой открытого ключа (PKI).
Сертификаты бывают разных форматов и поддерживают не только SSL, а еще и аутентификацию людей и устройств, а также заверяют подлинность кода и документов. Посетите раздел Продукты GlobalSign для получения более подробной информации.
Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.
OpenSSL — это криптографическая библиотека со свободным и открытым исходным кодом, которая предоставляет несколько инструментов командной строки для работы с цифровыми сертификатами. Некоторые из этих инструментов могут быть использованы в качестве центра сертификации.
Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.
В некоторых случаях имеет больше смысла выступать в качестве вашего собственного центра сертифкации, чем платить центрам сертификации, таким как DigiCert. Например, обеспечение безопасности вебсайта в интранете или для выдачи собственных сертификатов клиентам, чтобы позволить им проверять подлинность сервера (Apache, OpenVPN).
Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.
Подготовка каталогов
Выберите каталог для хранения всех ключей и сертификатов. К примеру, /root/ca (все производится на Ubuntu 14.04.3 LTS)
Создадим структуру каталогов. Файлы index.txt и serial будут выступать в качестве плоской базы для отслеживания подписанных сертификатов.
Подготовка конфигурационных файлов
Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf , скопируем в него следующее содержимое root-config.txt.
Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default] :
Раздел [CA_default] содержит ряд значений по умолчанию:
Policy_strict будет применяться для всех подписей корневого центра сертификации, и корневой центр сертификации будет использоваться только для создания промежуточных центров сертификации.
Применим policy_loose для всех подписей промежуточных центров серфтификации, так как промежуточные центры сертификации это подписывающие серверы, и клиентские сертификаты могут приходить от различных третьих лиц.
Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.
Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.
Следующие несколько секций являются расширениями, которые могут применять при подписывании сертификатов. Например, при указании аргумента командной строки -extensions v3_ca будут применены расширения из секции [ v3_ca ] . Эти расширения будут применяться при создании корневого сертификата.
При создании сертификата промежуточного центра сертификации будут применяться расширения из v3_ca_intermediate . Параметр pathlen:0 указывает, что не может быть никаких дальнейших центров сертификации ниже промежуточного центра сертификации.
Расширение usr_cert будет применяться при подписывании клиентских сертификатов, таких, которые используются для аутентификации удаленных пользователей.
Расширение server_cert будет применяться при подписывании серверных сертификатов, таких, которые используются для веб-серверов.
Расширение crl_ext будет автоматически применяться при создании списков отзыва сертификатов (CRL — certificate revocation lists).
Расширение ocsp будет применяться при подписывании сертификата OCSP (Online Certificate Status Protocol, онлайн протокол статуса сертификатов).
Создание корневого ключа
Создадим корневой ключ (ca.key.pem), который следует хранить защищенно. Любой, владеющий корневым ключом, может выдавать доверенные сертификаты. Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем. Следует использовать 4096 битное шифрование для ключей корневого и промежуточных центров сертификации. Серверные и клиентские сертификаты возможно подписывать шифрованием с меньшей битностью.
Создание корневого сертификата
Для создания корневого сертификата (ca.cert.pem) используется корневой ключ (ca.key.pem). Следует указать длинный срок годности сертификата, например, 20 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными. Всякий раз при использовании утилиты req следует указывать файл конфигурации для использования с опцией –config , в противном случае OpenSSL будет использовать по умолчанию конфигурационный файл /etc/pki/tls/openssl.cnf !
Проверка корневого сертификата
- Используемый алгоритм Signature Algorithm
- Даты периода действия сертификата Validity
- Длину публичного ключа Public-Key
- Эмитент сертификата Issuer, который является объектом, который подписал сертификат
- Предмет Subject, который относится к самому сертификату.
Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.
Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca , и опции из секции [ v3_ca ] отражены в выводе.
Промежуточным центомр сертификации является объект, который может подписывать сертификаты от имени корневого центра сертификации. Корневой центр сертификации подписывает промежуточный сертификат, образуя цепочку доверия.
Подготовка каталогов
Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.
Создадим точно такую же структуру каталогов, которая используется для корневого центра сертификации. Также удобно создать каталог csr для хранения запросов на подпись сертификатов.
Добавим файл crlnumber к дереву каталогов промежуточного центра сертификации. Crlnumber будет использоваться для отслеживания списков отзывов сертификатов.
Создадим конфигурационный файл /root/ca/intermediate/openssl.cnf , скопируем в него следующее содержимое intermediate-config.txt. В нем изменены пять опций, по сравнению с конфигурационным файлов корневого центра сертификации:
Создание промежуточного ключа
Создадим промежуточный ключ (intermediate.key.pem). Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем.
Создание промежуточного сертификата
Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци ( intermediate/openssl.cnf ).
Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации ( /root/ca/openssl.cnf ).
V 250408122707Z 1000 unknown . /CN=Alice Ltd Intermediate CA
Проверка промежуточного сертификата
Как мы делали с корневым сертификатом, убедимся, что детали промежуточного сертификата корректны.
Сверим промежуточный сертификат с корневым сертификатом. ОК показывает, что цепочка доверия не повреждена.
Создание файла цепочки сертификатов
Когда приложение (например, веб-браузер) пытается проверить сертификат, подписанный промежуточным центром сертификации, оно также должно проверить промежуточный сертификат от корневого центра сертификации. Для выполнения проверки цепочки доверия создадим цепочку сертификатов центра сертификации для предоставления приложениям.
Чтобы создать цепочку сертификатов требуется объеденить промежуточные и корневые сертификаты вмете. Позже мы будем использовать этот файл для проверки сертификатов подписанных промежуточным центром сертификации.
Наш файл цепочки сертификатов должен содержать корневой сертификат, потому что клиентские приложения ничего не знают о нем. Лучшим вариантом, особенно, если вы администратор сети, является установка корневого сертификата на каждом клиенте, которому требуется подключаться к приложению.
Подпишем сертификаты используя наш промежуточный центр сертификации. Эти подписанные сертификаты можно использовать в различных ситуациях, таких как защищать соединения к веб серверу или аутентифицировать клиентов, присоединяющихся к сервису.
Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.
Создание ключа
Наши корневая и промежуточная пары 4096 бит. Серверный и клиентский сертификат обычно истекают после одного года, поэтому мы можем безопасно использовать 2048 бит.
Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.
Создание сертификата
Для создания сертификата воспользуемся промежуточным центром сертификации для подписи CSR. Если сертификат будет использоваться на сервере, используйте расширение server_cert . Если сертификат будет использоваться для аутентификации клиентов, то используйте расширение usr_cert . Сертификаты обычно даются сроком на один год, на центре сертификации обычно дают несколько дней для удобства.
Файл intermediate/index.txt должен содержать строку, которая относится к этому сертификату
Проверка сертификата
Issuer сертификата наш промежуточный центр сертификации. Subject относится к самому сертификату.
Вывод также покажет расширения X509V3. При создании сертификата можно использовать расширения server_cert или usr_cert . Варианты о соответствующем разделе конфигурации будут отражаться в выводе.
Используя файл цепочки сертификатов центра сертификации, который мы создали ранее (ca-chain.cert.pem) для проверки того, что новый сертификат имеет действительную цепочку доверия.
Установка сертификата
Теперь можно установить новый сертификат на сервере, или распространить сертификат на клиентов. При установке на серверное приложение (к примеру, Apache), понадобятся следующие файлы:
Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.
Подготовка файла конфигурации
Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert .
Создание CRL
Секция CRL OPTIONS в man ca содержит больше информации о том, как создавать CRL.
Можно проверить содержимое CRL с помощтю утилиты crl.
Пока еще не было отозванных сертификатов, поэтому в выводе указано:
No Revoked Certificates.
Необходимо пересоздавать CRL на регулярной основе. По умолчанию, CRL истекает через 30 дней. Это настраивается опцией default_crl_days в секции CA_default .
Отзыв сертификата
Давайте разберем пример. Алиса запустила веб-сервер Apache и имеет личную папку с сердцу трогательными милыми картинками котят. Алиса хочет предоставить своему другу, Бобу, доступ к этой коллекции.
Боб создает запрос частного ключа и запрос на подпись сертификата (CSR).
Боб посылает свой CSR Алисе которая затем подписывает его.
Алиса проверяет, что сертификат действителен:
Файл index.txt должен содержать новую запись.
Алиса посылает Бобу подписанный сертификат. Боб устанавливает сертификат в своем веб-браузере и теперь у него есть доступ к фотографиям котят Алисы. Ура!
К сожалению, выясняется, что Боб себя плохо вел. Боб отправил фотографии котят Алисы в Hacker News, заявляя, что они его и теперь набирает огромную популярность. Алиса это узнает и нуждается в немедленном отзыве его доступа.
Строка в index.txt, которая относится к сертификату Боба теперь начинается с буквы R. Это означает, что он был отозван (Revoked).
После отзыва сертификата Боба, Алисе необходимо пересоздать CRL.
Ипользование CRL на сервере
Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.
В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify , и можно блокировать клиентов, чьи сертификаты были отозваны.
Использование CRL клиентами
Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.
Если сертификат был подписан с расширением, которое включает crlDistributionPoints , клиентское приложение может прочитать эту информацию и получить CRL из указанного места.
Точки распространения CRL видны в спецификациях X509v3 сертификата.
Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.
Например, когда веб-браузеру предоставлен сертификат сервера, он посылает запрос на адрес сервера OCSP, указанном в сертификате. По этому адресу OCSP слушает запросы и отвечает статусом отзыва сертификата.
Рекомендуется использовать OCSP вместо CRL, где это возможно, хотя реально, как правило, OCSP нужен только для сертификатов веб-сайтов. Некоторыми веб-браузерами поддержка CRL считается устаревшей, или вообще убрана.
Подготовка конфигурационного файлы
Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert .
Создание пары OCSP
Ответчик OCSP нуждается в криптографической паре для подписывания ответа, который посылается запрашивающей стороне. Криптографическая пара OCSP должна быть подписана на том же центре сертификации, на котором проверяется подписанный сертификат.
Создадим частный ключ и зашифруем его алгоритмом AES-256.
Создадим запрос на создание сертификата (CSR). Детали должны, как правило, совпадать с подписывающим центром сертификации. Common Name, однако, должен быть полным доменным именем.
Подпишем CSR промежуточным центром сертификации.
Проверим, что сертификат содержит коррестные расширения X509v3.
Отзыв сертификата
Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.
Создадим серверный сертификат для тестирования.
Запустим ответчик OCSP на локальной машине. Вместо того, чтобы хранить статус отзыва в отдельном CRL файле ответчик OCSP напрямую читает файл index.txt. Ответ подписывается криптографической парой OCSP (используя опции –rkey и –rsigner).
В другом терминале пошлем запрос к OCSP ответчику. Опция –cert указывает сертификат для запроса.
Начало вывода показывает следующее:
- был ли получен положительный ответ (OCSP Response Status)
- идентичность ответчика (Responder Id)
- статус отзыва сертификата (Cert Status)
Как и раньше, запускаем ответчик OCSP в другом терминале и шлем запрос. В этот раз вывод показывает "Cert Status: revoked" и "Revocation Time" .
В этой статье я подробно расскажу о процессе установки и настройки Active Directory Certificate Services.
Служба сертификации Active Directory создает центр сертификации, предназначенный для выдачи сертификатов пользователям. Служба может быть настроена и работать через веб-интерфейс.
В примере я разбираю Active Directory Certificate Services на операционной системе Windows Server 2012.
Первым делом нам нужно установить службу сертификации Active Directory.
Установка службы сертификации Active Directory
Для этого нужно запустить диспетчер сервера.
Выбираем пункт установка ролей или компонентов, а затем выбираем наш сервер.
В следующем окне выбираем пункт службы сертификатов Active Directory.
В окне выбора компонентов жмем далее.
В окне служба ролей выбираем пункт центр сертификации.
Запускаем процесс установки.
После этого по аналогии устанавливаем веб-службу регистрации сертификатов.
Установка завершена. Перейдем к настройке.
Настройка службы сертификатов Active Directory
Заходим в настройки.
Выбираем службу центр сертификации.
Вариант установки – центр сертификации предприятия.
Тип центра сертификации – корневой. Это необходимо для того, что бы в дальнейшем мы могли самостоятельно выдавать и подписывать сертификаты.
В следующем окне нужно выбрать пункт создать новый закрытый ключ.
Затем необходимо указать параметры шифрования. Вы можете указать свои параметры, или параметры как у меня на рисунке ниже.
В следующем окне указывается имя центра шифрования.
Затем указывается срок действия центра сертификации. По умолчанию он равен 5 годам. Так и оставим.
После нажатия кнопки далее вам нужно будет указать физическое место на жестком диске для хранения базы данных.
Перейдем к настройке web-службы регистрации сертификатов.
Настройка web-службы регистрации сертификатов
Тип проверки подлинности – имя пользователя и пароль.
Учетная запись службы CES – использовать встроенное удостоверение пула приложений.
В окне выбора сертификата проверки подлинности сервера выберите существующий сертификат, затем нажмите кнопку настроить.
Выберите тип проверки подлинности – имя и пароль пользователя.
Включите режим обновления на останове ключей. Этот режим позволяет автоматически обновлять сертификаты ключей для компьютеров, которые не подключены к внутренней сети.
Установка и настройка удостоверяющего центра
Запустите консоль управления Microsoft (пуск, выполнить, mmc).
Далее нажмите файл, а затем добавить или удалить оснастку.
В появившемся окне выбрать пункт учетной записи компьютера.
В следующем окне ничего не меняем и нажимаем кнопку готово. Оснастка добавлена.
Появится окно перед началом работы. Жмем далее.
Теперь нам нужно связать сертификат с веб-сервером. Для этого нужно запустить диспетчер служб IIS.
В левой части окна нажать сайты, default web site, изменить привязки.
В появившемся окне нажмите добавить и введите данные как на изображении ниже.
Сохраните изменения и закройте окно.
Управление шаблонами сертификата
Откроем шаблоны в главном окне консоли. Создадим новый шаблон.
Сначала нужно выбрать любой шаблон сертификата и нажать скопировать его.
Настроим шаблон. Выберите совместимость шаблона сертификата.
Задайте общие свойства шаблона.
Параметры достоверности по умолчанию и периода обновления для сертификатов, выдаваемых службами сертификатов Active Directory (AD CS), предназначены удовлетворить большинство требований безопасности. Однако для сертификатов, используемых определенными группами пользователей, может потребоваться указать другие параметры достоверности и обновления, такие как более короткие срок действия или периоды обновления.
Обработка запроса. Цель имеет 4 возможных параметра:
Настраиваемый список управления доступом необходим в случае, если учетная запись службы, которой требуется доступ к закрытому ключу, не включена в разрешения по умолчанию.
Вкладка шифрование. Определяется максимальный размер ключа. Я оставлю его без изменений.
Безопасность можно настроить по вашему усмотрению.
Шаблон сертификата готов.
На этом статья подходит к концу. Мы установили и настроили Active Directory Certificate Services.
Обучаю HTML, CSS, PHP. Создаю и продвигаю сайты, скрипты и программы. Занимаюсь информационной безопасностью. Рассмотрю различные виды сотрудничества.
2 комментариев к записи “ Установка и настройка Active Directory Certificate Services ”
Ну одноуровневый CA без изолированного корневого CA — так себе затея.
Настройка шаблонов практически не рассмотрена, настройки публикации CRL тоже нет. Хлипенький CA получился(
Эта статья предназначена для общего понимания. Она не претендует на подробное руководство по развертыванию полноценного центра сертификации. Так как у всех есть свои задачи, и написать универсальную статью, которая подойдет всем практически невозможно, да и времени столько у меня нет.
Если есть желание помочь людям – вы можете стать соавтором, поделитесь опытом.
Читайте также: