Как сделать корневой сертификат

Обновлено: 07.07.2024

Я хотел бы настроить свой собственный ответчик OCSP (только для целей тестирования). Это требует, чтобы у меня был корневой сертификат и несколько сертификатов, сгенерированных из него.

Мне удалось создать самозаверяющий сертификат с помощью openssl. Я хочу использовать его в качестве корневого сертификата. Следующим шагом будет создание производных сертификатов. Я не могу найти документацию о том, как это сделать, однако. Кто-нибудь знает, где я могу найти эту информацию?

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

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

Моя команда для создания корневого сертификата:

Сертификат А создается так:

Эта команда неявно зависит от корневого сертификата, для которого она находит необходимую информацию в файле конфигурации openssl.

Какую командную строку я должен использовать для создания сертификатов B и выше?

Изменить
Я нашел ответ в этой статье . Сертификат B (цепь A -> B) может быть создан с помощью этих двух команд:

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

Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):

Опция -out указывает на имя файла для сохранения, без этой опции файл будет выведен в стандартный вывод (на экран). Имя выходного файла не должно совпадать с именем входного файла.

Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.

Список поддерживаемых симметричных алгоритмов шифрования приватного ключа можно узнать в документации (раздел SUPPORTED CIPHERS):

Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):

Создание самоподписанного корневого сертификата

Здесь мы использовали наш корневой ключ для создания корневого сертификата (файл rootCA.crt), который должен распространяться на всех компьютерах, которые нам доверяют. А приватный ключ (файл rootCA.key) должен быть секретным, поскольку он будет использоваться для подписи сертификатов серверов.

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

Создание приватного ключа сертификата

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

Создание файла с запросом на подпись сертификата (csr)

Получив закрытый ключ, вы можете приступить к созданию запроса на подпись сертификата — Certificate Signing Request (CSR). Это официальный запрос к CA о подписании сертификата, который содержит открытый ключ объекта, запрашивающего сертификат, и некоторую информацию об объекте. Все эти данные будут частью сертификата. CSR всегда подписывается закрытым ключом, соответствующим открытому ключу, который он несёт.

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

Важно: имейте в виду, что при создании запроса на подпись важно указать Common Name, предоставляющее IP-адрес или доменное имя для службы, в противном случае сертификат не может быть проверен.

Я опишу здесь два способа:

Метод Б (в одну команду без запросов)

Этот метод генерирует тот же результат, что и метод A, но он подходит для использования в вашей автоматизации.

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

Проверка содержимого CSR

Создание сертификата

Если вы устанавливаете сервер TLS для своего собственного использования, вы, вероятно, не хотите идти в ЦС для покупки публично доверенного сертификата. Намного проще использовать сертификат, подписанный вашим собственным CA. Если вы являетесь пользователем Firefox, при первом посещении веб-сайта вы можете создать исключение для сертификата, после которого сайт будет защищён так, как если бы он был защищён общедоступным сертификатом.

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

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

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

Почти всякий, кто устанавливал некий веб- сайт имел дело с сертификатами SSL из общедоступного CA ( Certification Authority , Органа сертификации), но знаете ли вы, что вы можете быть собственным CA? Что вы можете выпускать сертификаты для машин в вашей сетевой среде прямо со своего собственного сервера CA? Следуя далее мы исследуем некоторые из возможностей Windows Server 2016, работающего в качестве сервера CAв вашей сети. Наша работа в данной главе охватит следующие темы:

Настройка самого первого сервера Certification Authority в сетевой среде

Построение Подчинённого сервера CA

Создание шаблона сертификата для подготовки выпуска сертификатов машин вашим клиентам

Публикация шаблона сертификата для возможности регистрации

Применение MMC для запроса нового сертификата

Применение веб- интерфейса для запроса нового сертификата

Настройка автоматической регистрации для выпуска сертификатов всем подключённым к домену системам

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

Введение

Когда я получаю известие, что частью моего задания дня является новый пользователь или сеть, я обычно нахожу, что истиной будет одна из двух вещей. Либо у них нет никакого сервера CA, либо они имеют его, но совсем ни для чего не применяют. Большинство людей знают, что сертификаты понадобятся и востребованы, а также что постоянно выпускаются новые технологии, которые требуют довольно большого количества сертификатов. Такие технологии как Lync, SharePoint, System Center, DirectAccess или даже простое построение веб- сайта почти всегда требуют применения сертификата в сегодняшнем мире. Прыгнув в проект по размещению практически любой новой системы в эти дни быстро приводит вас к пониманию, что знание сертификатов становится обязательным. Даже места, в которых они не требуются, они обычно всё- таки рекомендуются чтобы иметь решение более безопасным или придерживающимся распространённой практики.

Совместными усилиями мы собираемся построить среду PKI ( Public Key Infrastructure , инфраструктуры общедоступных ключей) внутри нашей сетевой среды и применить её для некоторых распространённых задач выпуска сертификата. К концу данной главы вы должны лишиться напряжённости при создании PKI в вашей собственной среде, что подготовит вас к любым запросам с которыми вы можете встретиться при работе с технологиями, основанными на сертификатах.

Настройка первого сервера Сертификационной авторизации в сети

Самый первый барьер, который необходимо преодолеть когда вы хотите начать работу с сертификатами, состоит в помещении такого сервера на место. Существует множество справедливых вопросов на которые необходимо ответить. Нужен ли вам выделенный сервер для этой задачи? Мог ли я совмещать эту роль на существующем сервере? Нужно ли мне устанавливать Корпоративный (Enterprise) или автономного (stand-alone) CA (Органа сертификации)? Я слышал термин отключённого (offline) корня, но что он означает? Давайте начнём с основ и предположим, что вам нужно построить самый первый сервер CA в вашем окружении.

В сетевой среде домена AD наиболее полезными серверами CA является разновидность Корпоративных (Enterprise). Серверы корпоративного CA интегрированы с AD, что делает их видимыми для машин в такой сетевой среде и автоматически заслуживают доверие (trusted) у компьютеров, которые присоединены к данному домену. Существуют различные мнения по природе наилучшего использования при установке последовательностей серверов CA. Например, существует хорошее руководство тестовой лаборатории (ссылка на который приводится в конце данного рецепта), опубликованное Microsoft, которое проводит вас через настройку автономного (stand-alone) Корневого (Root) CA, Подчинённого Корпоративного (Subordinate Enterprise) CA, с последующим изъятием в выключенное состояние автономного корня (stand-alone root offline). Преимущество этого состоит в том, что сертификаты выпускаются из подчинённого CA, а не напрямую из корня и, тем самым, если ключи сертификата каким- то образом скомпрометированы в данном окружении, Корневой CA полностью отключён и недоступен с тем, чтобы быть скомпрометированным. В подобной ситуации вы можете вычистить Подчинённого и опубликованные им сертификаты, поднять отключённый Корень, построить нового Подчинённого и вернуться к делу публикации сертификатов без какой- бы то ни было повторной генерации нового сервера Корня CA.

С учётом предыдущего практического опыта, или как это определено тем или иным образом, удивительно, что я крайне редко вижу Корневой CA отключённым на практике. На самом деле, практически никогда. А в некоторых имевшихся у меня случаях наличие отключённого Корня CA вызывало проблемы. Просто для примера, при размещении инфраструктуры DirectAccess с возможностями одноразового пароля (OTP, one-time-password) в среде заказчика, было обнаружено, что чтобы заставить такие OTP работать правильно, отключённый Корень CA должен быть приведён назад в рабочее состояние. Это не было самым насущным интересом нашего варианта для создания PKI, и поэтому взамен мы реализовали вторую среду сертификата с автономным корнем и и двумя промежуточными чтобы поддерживать отключённым Корень CA для данной цели сертификатов OTP. Это вызвало большие задержки в нашем проекте, так как мы должны были построить три новых сервера, необходимых просто для получения публикации сертификатов правильным образом, что впоследствии привело к намного более сложной инфраструктуре сертификации.

Если предыдущее описание смутило вас, хорошо - так как это разновидность неаккуратной настройки. Если бы компания вместо этого работала с функционирующим сервером Корня CA в самом первом месте, никакая такая дополнительная работа не была бы нужна. Я не защищаю то, что Корпоративный Корень CA, который постоянно остаётся во включённом состоянии является наилучшим способом выдачи сертификатов, однако он вызывает наименьшее число проблем и существует множество компаний, которые работают в своих промышленных средах CA в точности таким образом.

Другое практическое наблюдение состоит в том, что большая часть компаний малого и среднего размера не выбирают подход с отключённым Корнем CA. На самом деле я обнаруживаю, что многие малые компании вынуждены совмещать серверы чтобы сберегать ресурсы и имеют свои CA роли установленными на серверы, которые также выполняют некоторые прочие задачи. Зачастую роль CA устанавливается в Контроллере домена. Хотя на поверхностном уровне рассмотрения это кажется не лишённым смысла, так как службы Корпоративного CA настолько тесно интегрируются с AD, в действительности это плохая мысль. Microsoft рекомендует чтобы вы никогда не совмещали роль CA в Контроллере домена, поэтому удерживайтесь в стороне от такого сценария по мере возможности. Как уже было сказано, я наблюдал десятки компаний, которые в точности делали это и никогда не имели с этим проблем, поэтому я предполагаю, что это просто ваш выбор насколько близко вы хотите придерживаться Пути Microsoft . Не забудьте ознакомиться со ссылками, приводимыми в конце данного рецепта, так как они снабдят вас информацией, которая будет полезна чтобы принять верное решение по поводу того какая настройка сервера сертификата наилучшим образом удовлетворяет вашей сетевой среде.

Подготовка

Я создал новый Windows Server 2016 с именем CA1 , причём он является участником домена, на котором мы будем включать нашу новую инфраструктуру сертификации.

Но возникает вопрос: откуда берутся цифровые сертификаты безопасности и кто отвечает за их надежность? Есть несколько основных доверенных центров сертификации, которые выдают сертификаты SSL и Code Signing. Они проверяют, действительно ли клиент, запросивший SSL имеет доступ к домену или является представителем запрашивающей организации. Кроме того, именно центры сертификации несут ответственность за конфиденциальность передаваемой информации. Массовое применение сертификатов SSL привело к большому количеству сертификационных центров, каждый из которых подписывает предоставляемые решения своим именем. Чтобы браузер пользователя мог отличать поставщиков SSL друг от друга, а также определить их надежность, в нем применяется список доверенных центров сертификации.

Cтруктура SSL сертификатов

Корневой сертификат ЦС Comodo : AddTrustExternalCARoot
Промежуточные сертификаты: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA
В самом низу изображены SSL сертификаты для отдельных доменов .

Для чего нужен корневой сертификат SSL?

Что же касается таких доверительных центров сертификации, как Comodo, Symantec, Thawte, GeoTrust и GlobalSign, то данные об их корневых сертификатах в обязательном порядке добавляются во все современные браузеры. Их список в настройках обозревателя выглядит следующим образом:

Но для правильного распознавания SSL для Вашего личного доменного имени, необходимо создать так называемую цепочку доверия (trust chain) из доменного, промежуточного и корневого сертификатов SSL. Для этого необходимо установить корневой, а также промежуточный сертификаты на своем сервере. Процесс установки производится по разному, в зависимости от Вашего программного обеспечения. Для наиболее известного ПО на нашем сайте можно найти инструкции по установке SSL. Заметьте, что в отдельных случаях для правильного распознавания необходимо создать ca-bundle – файл, в котором содержится информация корневого и промежуточного сертификатов.

Как получить корневой сертификат SSL?

Ваш личный (с номером заказа)
корневой
промежуточный.

Можно ли создать корневой сертификат самому?

Для этого необходимо зарегистрироваться в качестве центра сертификации, что требует больших временных и финансовых затрат. Поэтому рациональнее воспользоваться услугами всем известных доверенных центров сертификации, например, Thawte, Comodo, Verisign, GeoTrust, GlobalSign, которые без проблем распознаются практически всеми браузерами.

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

Читайте также: