Хроники IT-отдела

Зададим себе вопрос — а что такое, собственно, промежуточный ЦС и зачем это вообще нужно? Промежуточный ЦС — это некий авторитетный источник, с помощю которого мы можем создавать свои собственные SSL сертификаты в инфраструктуре открытого ключа (PKI). Промежуточный ЦС зависит от корневого ЦС, явлющимся «верхушкой» в цепочке доверия. Основная мысль состоит в том, что если вдруг промежуточный ЦС каким-либо образом окажется скомпрометированным или же будет принято решение отозвать все ранее выданные сертификаты пользователей, то это можно будет легко сделать с помощью корневого ЦС без причинения неудобства пользователю (им нужен будет корневой ЦС, установленный в браузере и т.п.).

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

У меня же практическая реализация данной схемы была вызвана необходимостью использования удаленных VPN клиентов (на базе OpenVPN), в связи с чем понадобилось перечисленное абзацем выше. В Интерентах на эту тему много не написано, обычно создается корневой ЦС и он используется для выдачи сертификатов. Но, как кто-то сказал, мы не ищем легких путей. Итак, приступим.

Для работы я использую FreeBSD 7/8, но реализация openssl такова, что пакеты можно найти для любой используемой вами платформы. Прежде всего нам нужен корневой ЦС (если уже есть, то эту часть можно пропустить). Установку openssl мы так же опускаем, подразумевая что пакет openssl уже установлен в системе.

Настройка корневого ЦС

# mkdir /usr/rootca

# cd /usr/rootca

# mkdir certs crl newcerts private

# echo "01" > serial

# cp /dev/null index.txt

(нахождение дефолтного конфига зависит от настроек переменных окружения)

# cp /usr/local/openssl/openssl.cnf .

Может потребоваться изменение некоторых настроек в openssl.cnf для того, что бы упросить процедуру выдачи сертификатов не вбивая каждый раз отднотипные данные: default_bits, countryName, stateOrProvinceName, 0.organizationName_default, organizationalUnitName and emailAddress и т.п..

Теперь создаем ЦС:

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

Генерируем личный ключ и сертификат корневого ЦС

# openssl req -days 3650 -nodes -new -newkey rsa:1024 -sha1 \

-x509 -keyout ca.key -out ca.crt -config openssl.cnf && \

chmod 0600 ca.key

Все, корневой ЦС готов. Теперь настроим промежуточный ЦС.

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

Создадим следующую структуру папок:

# cd /usr/rootca

# mkdir ca2010

# cd ca2010

# cp ../openssl.cnf .

# mkdir certs crl newcerts private

# echo "01" > serial

# cp /dev/null index.txt

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

# openssl req -days 3650 -nodes -new -newkey rsa:1024 \

-keyout private/interca.key -out interca.csr -config openssl.cnf && \

openssl ca -days 3650 -out private/interca.crt" -in inter.csr -extensions v3_ca \

-md sha1 -config openssl.cnf && \

chmod 0600 private/interca.key

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

Для этого в браузере (или на сервере OpenVPN и у его клиентов) нужно установить цепочку сертификатов — сертификат, содержащий в текстовом виде все серитфикаты «от и до». В нашем случае получается всего два уровня (но, естественно, таковых может быть и больше). Цепочка создается так:

# сначала сертификат промежуточного ЦС

cat interca.crt > chain.crt

# затем серитфикат корневого ЦС

cat ../ca.crt >> chain.crt

И уже этот файл устанавливается на сервер и клиентам.

Важно так же указать участникам обмена сертификатами кто является сервером, для этого серверной машине нужно создать серверный сертификат (в openssl.cnf не забываем указать interca.crt в качестве корневого сертификата):

openssl req -days 3650 -nodes -new -newkey rsa:1024 \

-keyout private/srv.key -out srv.csr -config openssl.cnf && \

openssl ca -days 3650 -out private/srv.crt" -in srv.csr -extensions server \

-md sha1 -config openssl.cnf && \

chmod 0600 private/srv.key

Затем по безопасному каналу копируем получившиеся .key и .crt на сервер и настраиваем его на работу с ними.

Схема распределения ключей и сертификатов

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

А можно обойтись без безопасного канала, скажете вы? Конечно да, скажу я вам, мои маленькие любознательные друзья! Для упрощения процесса все делается на одной машине, а вообще же можно было бы на каждом клиенте генерировать ключ, создавать запрос CSR, передавать его на сервер, отдавать сертификат клиенту. Но это слишком длительная процедура, поэтому файлы распространяются либо по безопасному каналу, либо на каком-либо носителе.

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