Учебник по gnoMint

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

Мы собираемся создать VPN с помощью программного обеспечения OpenVPN, надежную систему, которая использует SSL для туннелирования коммуникации. Мы полагаем, что все ваши сервера на Linux. И вы собираетесь использовать сертификаты X.509 для аутентификации удаленных коллег, так чтоб VPN мог легко расти без особых проблем. В этом уроке мы рассмотрим, как управлять необходимой инфраструктурой открытых ключей, используя gnoMint.

Настройка Вашего CA

Прежде всего, Вы должны установить Вашу сертификацию (Certification Authority). Это правда, что OpenVPN несет свои собственные скрипты (простой rsa) для создания небольшой CA инфраструктуры, базирующейся на openssl, и, возможно, их достаточно для того, что вам нужно. Но gnoMint позволяет управлять CA в более комфортабельной форме, всегда видя текущее состояние установки. И с gnoMint можно смотреть дальше, чем просто на VPN-ориентированную CA.

Кстати: если у вас уже есть OpenSSL CA (как те, сделанные через CA сценарий openssl, в tinyCA, OpenVPN простом RSA ...), вы должны знать, что gnoMint, начиная с 0.6.0 версии, может импортировать их в базу данных gnoMint.

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

  • Мы создадим CA второго уровня для идентификации системы VPN (в этом примере фирма будет использовать OpenVPN).
  • Другой вторичный CA для идентификации сотрудников в фирме (возможно использовать для передачи сверхсекретной информации через почту).
  • И еще один для обеспечения подписания (так как Департамент разработки программного обеспечения хочет подписать все патчи безопасности, для того чтоб произведенное программное обеспечение можно было обновить только с криптографически подписанными патчами).

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

Таким образом, вы установите последнюю версию gnoMint (для следующих этому учебнику, она должна быть, по крайней мере, 0.5.3 версия). Вы можете скачать его с SourceForge, Launchpad, либо с небольшим количеством удачи, из вашего любимого хранилища распределения. После его установки, вы можете запустить его с помощью:

$ gnomint &

 

Главное окно gnoMint появится, с открытой базой данных по умолчанию (~/.gnomint/default.gnomint):

Описание: http://gnomint.sourceforge.net/?q=system/files/screenshot-gnomint1_0.png

Теперь мы создадим частный ключ и самоподписанный сертификат для CA. Для этого, в меню Сертификаты, выберите "Добавить / Добавить самозаверенный CA". Откроется окно, просящее у нас данные для нового сертификата CA.

Window for entering new CA Properties 

После завершения исходных данных для CA, нажмите кнопку Далее. На этом этапе, мы должны выбрать вид шифрования, который мы будем использовать при создании этой новой CA. Выберем RSA (хотя вы можете выбрать DSA, если вы предпочитаете). Поскольку мы хотим, чтобы это длилось в течение длительного времени (20 лет), мы будем выбирать длинный секретный ключ, с битовой длинной 4096, или даже лучше, 5120. За несколько месяцев до истечения корневого сертификата будет 20 лет: 240 месяцев.

После нажатия кнопки ОК, частный / открытый ключ корневой СА и поколение сертификата будет продлено. Через некоторое время, вы получите следующий экран:

 

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

Значок кнопки говорит, что закрытый ключ, соответствующий сертификату, находится в базе данных. Это может быть проблемой безопасности. Любой человек с доступом к копии файла базы данных gnoMint сможет генерировать сертификаты и подключить свои машины к VPN.

Защита базы данных gnoMint

Для избежания такой ситуации, gnoMint имеет две различные, не исключающих, альтернативы:

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

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

  • Другой альтернативой является сохранение секретного ключа корневого центра сертификации в парольной фразе, защищенной внешним файлом. Для повышения безопасности, этот файл может находиться во внешнем съемном устройстве, например, как маленький диск USB, который обычно хранится в безопасности и используется только тогда, когда нужно что-то подписать с сертификатом CA Root.

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

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

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

Установка правил Root-CA

ОК. Мы имеем сертификат корневого СА. Теперь мы собираемся создать свою политику: мы дважды щелкаем по нему, либо после его выбора, выбраем Свойства в меню Правка. На экране появится окно свойств сертификата. В его третьей вкладке мы можем изменить политику CA.

 

СА Root будет генерировать вторичные сертификаты СА. Таким образом, мы должны выбрать, в "использовании новых генерируемых сертификатов" раздел "Центр сертификации" и "поколение CRL".

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

Кроме того, мы установим, что эти вторичные сертификаты СА истекают через 5 лет (60 месяцев) после их создания, и будет так, что расчетное время между CRL выдачей будет 7 дней (168 часов).

Создание сертификата запросов на подписи для вторичной сертификации

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

 

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

После нажатия на кнопку Далее, мы выбираем свойства шифрования для CSR (то есть, для нового сертификата). Мы продолжаем с помощью RSA, но так, как этот сертификат истекает раньше, мы выбираем только 2048 битов для длины секретного ключа.

После этого, если база данных защищена паролем, gnoMint будет спрашивать нас пароль базы данных, так как это требуется для шифрования закрытого ключа в CSR перед сохранением в базе данных. Возможно, вы видели окно о том, что CRS был создан правильно, но вы не можете увидеть его в любом месте. В этом случае, проверьте в меню Вид, если запросы подписи сертификата проверены. Если нет, то проверьте его, и ... вуаля! Вот оно. 

ОК. Мы имеем CSR для первого вторичного СА (связанного с VPN) в базе данных. Теперь мы повторяем предыдущие шаги для создания еще двух CSR, одну для сотрудников СА, а другую для программного обеспечения и его подписания CA. Теперь все CSR для вторичных CA созданы.

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

Теперь мы собираемся подписать все CSR с сертификатом корневого центра сертификации, поэтому они станут нашими вторичными сертификатами СА.

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

После нажатия Далее, необходимо выбрать центр сертификации, который собирается подписать текущий CSR. В нашем случае, выберите только СА.

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

Следует отметить, что вы не можете изменить свойства сертификата таким образом, что не допускается политикой СА. Так, например, если политика Корневой CA допускает только сертификаты с Certification Authority и CRL подписание использования, вы не можете активировать использование цифровой подписи в новом сертификате, подписанном корневым CA

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

Теперь мы повторяем последние действия с другими двумя CSR, и тогда мы будем иметь три средних СA, по одному для каждой цели применения.

Определение вторичной политики СА

Теперь мы должны определить политику для вторичного СА.

Система CA

Во-первых, VPN систематизирует CA. Сертификаты, созданные с этим СА, должны использоваться для цифровой подписи, шифрования ключа и согласования ключей. Его разрешенные целей должны включать веб-сервер TLS, и веб-клиент TLS (так как эти биты могут быть прочитаны как "TLS сервера" и "TLS клиент", без части "веб").

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

Сотрудники CA

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

Сертификаты, созданные с этой СА должны использоваться для цифровой подписи, шифрования ключа и согласования ключей. Его включенные цели должны быть веб-клиент TLS и Защита электронной почты.

 

Программное обеспечение подписания СА

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

Сертификаты, созданные с этой СА должны быть использованы только для цифровой подписи. Его единственная цель включает подписи кода.

ОК. Мы готовы начать создавать конечные сертификаты. Давайте начнем.

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

После того как наши CA настроены, сначала мы создадим сертификаты, соответствующие системам в нашей VPN.

VPN будет сформирован центральным сервером, который будет прослушивать входящие соединения от машин, развернутых в составе делегаций по всей стране. Итак, мы собираемся создать сертификат для сервера VPN (в Мадриде, Испания), а затем два клиентских сертификатов (для делегаций Барселоны и Севильи). Таким образом, мы создадим запросы подписывающего сертификата для трех VPN узлов.

Более безопасное приближение бы сказало вам, что барселонская и севильская делегации должны создать свой собственный CSR. С gnoMint это возможно: они могут создать CSR с помощью gnoMint, экспортировать его в файл PEM (или создать CSR с любой другой программой), а затем отправить его вам по электронной почте либо любым другим способом. Поскольку CSR не содержит никакой личной информации, он может быть направлен по ненадежным каналам.

Давайте предположим, что это более безопасно, чем какая-либо возможная аппроксимация, потому что мы единственные работники в фирме с технической поддержкой. Таким образом, три CSR будут созданы нами.

Нажмите на Сертификаты / Добавить / Добавить запрос сертификата. Появится следующее окно. Мы выбираем наследовать свойства от СА Systems, так как это те, которые мы разработали для выдачи сертификатов для VPN узлов.

CA selection for the new CSRs

После нажатия на кнопку Далее, мы должны завершить тематику информации CRS. Хотя это не является обязательным, мы должны заполнить все поля правильной информацией.

New CSR subject properties

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

CSR Key pair properties

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

After creating CSR certificates for VPN nodes

Теперь мы подпишем CSR для получения сертификатов VPNузлов.

(продолжение следует...)

Статья переведена с оригинала . Сайт - http://gnomint.sourceforge.net/