Генерация клиентских сертификатов VPN сертификатов на сервере OpenVPN.

Из этой статьи Вы узнаете о том, как генерировать клиентские сертификаты, отчего отталкиваться при написании клиентского файла конфигурации, как писать клиентский файл конфигурации.

Содержание статьи

1. Введение.
2. Генерация сертификатов.
3. Руководство по созданию базового файла конфигурации.
4. Создание единого файла конфигурации, содержащего все сертификаты и ключи.

Введение

Стоит начать с того, что для того, чтобы создавать клиентские ключи и сертификаты, Вам необходимо наличие функционирующего VPN сервера. В рамках данной статьи используется серверный дистрибутив на базе CentOS 6.9 совместно с OpenVPN сервером версии 2.4.6

Генерация сертификатов

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

2) Создаётся сертификат, затем производится подпись центром сертификации.

Подготовимся к созданию ключа и сертификата. Для этого перейдём в рабочую директорию easy-rsa. У меня это:

# cd /usr/share/easy-rsa/3.0.3/

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

# ./easyrsa gen-req client1 nopass      

Разберём основной синтаксис:

1. gen-req (generate request) – сгенерировать запрос, под этой командой понимается так же генерация ключа.
2. client1 – имя нашего файла (может быть любым)
3. nopass – директива, которая указывает не устанавливать пароль на клиентский сертификат, в противном случае, каждый раз, когда клиент будет пытаться подключиться, для сертификата будет запрашиваться пароль.

Когда выполнение будет начато, мы увидим:

Общий вывод такой, а теперь давайте разберём его конкретно:
Первым делом утилита уведомляет нас о том, что использует конфигурацию из файла vars.

Затем сервер генерирует клиентский ключ размерностью 2048 бит, после сразу же записывает его в директорию:

/usr/share/easy-rsa/3.0.3/pki/private/client1.key.FkMNLTEczC

Здесь мы задаём имя объекта, которому выдаётся сертификат. Т.к. нет общеупотребительного варианта перевода, смысл такой.

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

Создаётся файл client1.req – файл, хранящий запрос о сертификате, а также файл client1.key – хранящий клиентский ключ.

Следующим шагом будет создание и подпись клиентского сертификата. Для этого введите в консоль команду:

# ./easyrsa sign-req client client1

Синтаксис остаётся примерно тем же, со следующими отличиями:

1. sign-req (signature request) запрос на создание и подпись сертификата.
2. второе значение – client — говорит о типе сертификата, который нужно подписать: клиент или сервер. В нашем случае – это клиент.
3. client1 – имя файла (может быть любым).

Во время выполнения увидим следующее:

Процедура схожа с созданием запроса. Происходит обращение к файлу vars, затем сервер уведомляет нас о том, что сертификат будет сгенерирован на 3650 дней, после чего нам предлагается ввести ‘yes’, чтобы продолжить или ввести что угодно, чтобы отменить запрос.

Т.к. нам нужен подписанный сертификат, пишем ‘yes’.

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

В результате получаем следующий вывод: происходит проверка соответствия запроса требованиям центра сертификации, подпись и генерация сертификата по указанному пути: /usr/share/easy-rsa/3.0.3/pki/issued/client1.crt

По итогу мы получаем 2 файла:

1. client1.key – клиентский ключ
2. client1.crt – клиентский сертификат

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

1. ca.crt – сертификат центра сертификации
2. client1.key – клиентский ключ
3. client1.crt – клиентский сертификат

Руководство по созданию базового файла конфигурации.

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

# Первым делом, указываем тип: клиент/сервер.
client
 
# Укажите адрес VPN сервера, вместо a.b.c.d,
# к которому желаете подключиться. Через пробел можно указать порт.
# Смотрите закомментированый пример. Если указываете адрес и порт
# директивой remote, директиву port использовать не нужно.
remote a.b.c.d
;remote a.b.c.d 1194
 
# Укажите порт OpenVPN сервера. Должен быть таким же, как и на сервере.
port 1194
 
# Укажите тип интерфейса tun/tap. Зависит от конфигурации сервера.
dev tun
 
# Укажите протокол. 
# Должен быть таким, как на сервере.
proto tcp
;proto udp
    
# Укажите непривилегированного пользователя и соответствующую группу
# пользователей. Для всех клиентов, кроме Windows.
;user nobody
;group nobody
 
# persist-key – не перечитывать файлы ключей после перезапуска тоннеля.
# persist-tun – не закрывать и не перезапускать tun/tap интерфейс, так же не
# выполнять up/down скрипты. Если не указать этот параметр, то каждый раз,
# когда будет падать интернет, нужно будет вручную всё поднимать при условии, # что приложение OpenVPN работает на правах непривилегированного
# пользователя. 
persist-key
persist-tun
   
# Укажите пути к сертификатам. В моём случае сертификаты лежат в той папке,
# где и сам конфигурационный файл, т.е. путь остаётся пустым.
ca ca.crt
cert client1.crt
key client1.key
 
# Укажите ключ tls, если имеется. Генерируется на стороне сервера. Целью TLS
# ключа является повышение безопасности тоннеля и шифрование трафика.
# В моём случае не используется, потому закомментировано.
;tls-auth ta.key" 1
 
# Укажите алгоритм шифрования. Должен соответствовать серверному.
cipher AES-256-CBC
 
# Укажите: нужно ли использовать сжатие. Должно соответствовать серверу.
# У меня не используется, потому закомментировано.
;comp-lzo
 
# Укажите уровень логгирования.
verb 6

# Укажите параметр проверки доступности хоста. В данном случае:
# Посылать пакет icmp каждые 10 секунд в течение 120 секунд.
# Если хост не отвечает спустя 120 секунд, считать его недоступным и выполнять # перезапуск тоннеля.
keepalive 10 120

На данном этапе всё готово. Осталось передать архив, состоящий из четырёх файлов (ca.crt, client1.crt, client1.key, tun0.ovpn).

Создание единого файла конфигурации, содержащего все сертификаты и ключи

Следует рассказать о том, как разместить все сертификаты и конфигурацию клиента в один файл расширения .ovpn. Реализуется это следующим образом.

В конфигурационный файл вносится следующая конструкция:

<certificate>                                   

 [...]                                                 

</certificate>                                  

Указывая тэг certificate, мы сообщаем о том, что в его рамках будет находиться некое содержимое некоего сертификата. Для того, чтобы явно указать, какой сертификат нужно заключить в конфигурационный файл, в тэг <certificate> вместо слова ‘certificate’ необходимо вписать тип файла, например, вписав в тэг <cert> мы сообщаем, что в рамках тэга будет описан сертификат клиента сервера VPN.

Теперь рассмотрим на нашем примере.

У нас в данный момент есть 3 файла, сгенерированные OpenVPN сервером, это:

1. ca.crt
2. client1.crt
3. client1.key

В файле конфигурации они объявлены таким образом:

1. ca ca.crt
2. cert client1.crt
3. key client1.key

Их необходимо удалить из файла конфигурации .ovpn, затем внести в конец конфигурационного файла следующую конструкцию:

<ca>
 [...]
</ca>
<cert>
 [...]
</cert>
<key>
 [...]
</key>

После этого полностью скопируйте содержимое каждого из файлов, затем вставьте вместо […].

На данном этапе всё готово, осталось выслать клиенту готовый конфигурационный файл.