Easy rsa что это

Записки IT специалиста

Создание ключей и сертификатов для OpenVPN при помощи Easy-RSA 3

Автор: Уваров А.С.
04.12.2019

OpenVPN — популярная технология для создания защищенных частных сетей (VPN), использующих аутентификацию и шифрование на основе протокола SSL/TLS. Для упрощения процедуры создания необходимых ключей и сертификатов традиционно используется утилита Easy-RSA, которая позволяет легко управлять локальным центром сертификации (CA) инфраструктуры открытых ключей (PKI). Сегодня мы поговорим о работе с новой версией утилиты Easy-RSA 3, которая серьезно отличается по синтаксису от используемой ранее Easy-RSA 2 и входит в состав новых дистрибутивов Debian и Ubuntu.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

На первый взгляд может показаться, что разработчики Easy-RSA серьезно все поменяли, но это не так, если вы понимаете, как устроена инфраструктура открытых ключей, то вам будет ясно, что работа утилиты изменилась только по форме, но не по сути. Она стала более целостной и простой в использовании, но в тоже время приобрела ряд новых функции, свойственных более «взрослым» продуктам. В настоящий момент Easy-RSA 3 входит в состав Debian 10, а также Ubuntu 18.10 и новее.

Установка Easy-RSA и создание центра сертификации

Для установки Easy-RSA 3 выполним:

После чего убедимся, что установлена именно третья версия утилиты:

Обычно затем директорию с easy-rsa копируют в конфигурационную папку OpenVPN, но на наш взгляд CA лучше располагать отдельно, поэтому мы скопируем директорию просто в /etc, однако это ни не что не влияет, и вы можете поступить по своему разумению.

Затем изменим рабочую директорию на скопированную нами папку:

Если вас устраивают параметры по умолчанию, то следующий шаг можно пропустить и сразу перейти к созданию инфраструктуры PKI. Однако мы советуем потратить немного времени на тонкую настройку вашего CA.

Прежде всего скопируем шаблон файла настроек:

и откроем файл vars на редактирование. Строки вида #set_var содержат значения по умолчанию, для их именения строку нужно раскомментировать и указать собственное значение. Начнем с опции EASYRSA_DN, она предусматривает два режима: упрощенный cn_only, при котором сертификат содержит только CN (имя того, кому выдан сертификат) и традиционный org, при котором заполняются все реквизиты организации. Для OpenVPN можно использовать любой режим. Мы установим традиционный:

После чего раскомментируйте и заполните блок ниже своими данными (в примере указаны наши):

Заметьте, что если вы оставили cn_only, то редактировать вышеуказанные опции не имеет смысла.

Параметр EASYRSA_KEY_SIZE указывает размер ключа, на сегодняшний день безопасным считается размер начиная с 2048, если вы ставите на первое место безопасность, то можете увеличить его до 3072 или 4096. Если криптографическая стойкость не играет роли, например, туннель будет использован для доступа в интернет и предполагается использование слабых устройств, то можно уменьшить размер ключа до 1024.

Опции EASYRSA_CA_EXPIRE и EASYRSA_CERT_EXPIRE задают срок действия корневого сертификата CA и сертификатов пользователей (сервера и клиентов), их значения установлены в днях как 3650 (10 лет) и 1080 (5 лет), опция EASYRSA_CERT_RENEW задает количество дней до истечения сертификата, когда становится доступным его продление, по умолчанию это 30 дней. При необходимости вы можете изменить эти значения.

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

Данная команда инициализирует новую структуру центра сертификации с очисткой всех данных. После чего создадим файл для генерации случайных данных:

и активируем наш CA:

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

После выполнения этих команд будет выполнено создание структуры директорий CA, публичный сертификат центра сертификации ca.crt вы сможете найти в директории pki, а закрытый ключ ca.key в pki/private. Закрытый ключ является секретным и не при каких обстоятельствах не должен покидать свое расположение и тем более не должен передаваться по открытым каналам связи, доступ третьих лиц к закрытому ключу также следует ограничить.

Также не забудем сформировать файл параметров Диффи-Хеллмана dh.pem, он также будет расположен в директории pki:

На этом создание центра сертификации (CA) можно считать законченным.

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

В Easy-RSA 3 все «по-взрослому», сначала нам нужно создать запрос на сертификат:

где ovpn-server — имя вашего сервера, nopass означает, что закрытый ключ следует создать без пароля. При выполнении данной команды будет создан запрос на сертификат и сгенерирован закрытый ключ сервера ovpn-server.key, который будет располагаться в pki/private. Закрытый ключ является секретным и не должен передаваться по открытым каналам связи и доступ к нему также должен быть ограничен.

Для выпуска сертификата выполните:

Опция server обозначает выпуск сертификата для сервера. Для подтверждения выпуска вам нужно будет явно выразить свое согласие указав yes в ответ на соответствующий запрос, любый иные действия приведут к отмене действия. Затем потребуется ввести пароль закрытого ключа центра сертификации.

Выпущенные сертификаты будут располагаться в pki/issued.

Теперь скопируем необходимые сертификаты и ключи в конфигурационную директорию OpenVPN, предварительно создав там папку keys:

Дальнейшая настройка OpenVPN-сервера ничем не отличается от описанной нами ранее, и вы можете воспользоваться любой нашей инструкцией, смотрите блок Дополнительные материалы внизу статьи.

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

Точно также начнем с формирования запроса на сертификат:

где ivanov_ivan — имя клиента, а nopass предписывает создать закрытый ключ без пароля. Мы рекомендуем давать клиентам осмысленные имена, чтобы потом не пришлось долго гадать, кто именно скрывается под псевдонимом типа client123.

На основании запроса выпустим сертификат:

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

Для передачи на клиент вам потребуется скопировать в доступную пользователю директорию закрытый ключ, сертификат клиента и сертификат CA. В нашем случае файлы будут скопированы в домашнюю директорию пользователя andrey.

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

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

Списки отзыва и отзыв сертификатов

Если вы используете OpenVPN для организации связи между офисами или доступа в интернет, то вряд ли у вас возникнет потребность в отзыве сертификата. Другое дело, если вы предоставляете удаленный доступ к корпоративной сети с домашних ПК сотрудников, подрядчикам или аутсорсерам. Здесь может возникнуть масса ситуаций, когда доступ отдельных лиц следует прекратить: сотрудник уволился, истек срок договора с подрядчиком, сменили аутсорсера и т.д. и т.п.

Прежде всего создадим список отозванных сертификатов (CRL):

Затем создадим символьную ссылку на список в директории с ключами OpenVPN:

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

После чего сервер OpenVPN потребуется перезапустить.

Теперь отзовем какой-либо сертификат:

Где horns_and_hooves — имя сертификата клиента (СN), после отзыва следует повторно опубликовать список отозванных сертификатов:

Посмотреть список сертификатов можно командой:

Действующие сертификаты имеют статус V в начале строки, отозванные — R.

Как видим, работа с Easy-RSA 3 не представляет каких-либо сложностей и надеемся, что данная статья будет вам полезна.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Easy-RSA 3

This document explains how Easy-RSA 3 and each of its assorted features work.

If you are looking for a quickstart with less background or detail, an implementation-specific Howto or Readme may be available in this (the doc/ ) directory.

Easy-RSA Overview

Easy-RSA is a utility for managing X.509 PKI, or Public Key Infrastructure. A PKI is based on the notion of trusting a particular authority to authenticate a remote peer; for more background on how PKI works, see the Intro-To-PKI document.

The code is written in platform-neutral POSIX shell, allowing use on a wide range of host systems. The official Windows release also comes bundled with the programs necessary to use Easy-RSA. The shell code attempts to limit the number of external programs it depends on. Crypto-related tasks use openssl as the functional backend.

Feature Highlights

Here’s a non-exhaustive list of the more notable Easy-RSA features:

Easy-RSA is able to manage multiple PKIs, each with their own independent configuration, storage directory, and X.509 extension handling.
Multiple Subject Name (X.509 DN field) formatting options are supported. For VPNs, this means a cleaner commonName only setup can be used.
A single backend is used across all supported platforms, ensuring that no platform is ‘left out’ of the rich features. Unix-alikes (BSD, Linux, etc) and Windows are all supported.
Easy-RSA’s X.509 support includes CRL, CDP, keyUsage/eKu attributes, and additional features. The included support can be changed or extended as an advanced feature.
Interactive and automated (batch) modes of operation
Flexible configuration: features can be enabled through command-line options, environment variables, a config file, or a combination of these.
Built-in defaults allow Easy-RSA to be used without first editing a config file.

Obtaining and Using Easy-RSA

Download and extraction (installation)

Easy-RSA’s main program is a script, supported by a couple of config files. As such, there is no formal «installation» required. Preparing to use Easy-RSA is as simple as downloading the compressed package (.tar.gz for Linux/Unix or .zip for Windows) and extract it to a location of your choosing. There is no compiling or OS-dependent setup required.

You should install and run Easy-RSA as a non-root (non-Administrator) account as root access is not required.

Running Easy-RSA

Invoking Easy-RSA is done through your preferred shell. Under Windows, you will use the EasyRSA Start.bat program to provide a POSIX-shell environment suitable for using Easy-RSA.

The basic format for running commands is:

where command is the name of a command to run, and cmd-opts are any options to supply to the command. Some commands have mandatory or optional cmd-opts. Note the leading ./ component of the command: this is required in Unix-like environments and may be a new concept to some Windows users.

General usage and command help can be shown with:

When run without any command, general usage and a list of available commands are shown; when a command is supplied, detailed help output for that command is shown.

Configuring Easy-RSA

Easy-RSA 3 no longer needs any configuration file prior to operation, unlike earlier versions. However, the vars.example file contains many commented options that can be used to control non-default behavior as required. Reading this file will provide an idea of the basic configuration available. Note that a vars file must be named just vars (without an extension) to actively use it.

Additionally, some options can be defined at runtime with options on the command-line. A full list can be shown with:

Any of these options can appear before the command as required as shown below:

For experts, additional configuration flexibility is available by way of env-vars and custom X.509 extensions. Consult the EasyRSA-Advanced documentation for details

Getting Started: The Basics

Some of the terms used here will be common to those familiar with how PKI works. Instead of describing PKI basics, please consult the document Intro-To-PKI if you need a more basic description of how a PKI works.

Creating an Easy-RSA PKI

In order to do something useful, Easy-RSA needs to first initialize a directory for the PKI. Multiple PKIs can be managed with a single installation of Easy-RSA, but the default directory is called simply «pki» unless otherwise specified.

To create or clear out (re-initialize) a new PKI, use the command:

which will create a new, blank PKI structure ready to be used. Once created, this PKI can be used to make a new CA or generate keypairs.

The PKI Directory Structure

An Easy-RSA PKI contains the following directory structure:

private/ — dir with private keys generated on this host
reqs/ — dir with locally generated certificate requests (for a CA imported requests are stored here)

In a clean PKI no files will exist until, just the bare directories. Commands called later will create the necessary files depending on the operation.

When building a CA, a number of new files are created by a combination of Easy-RSA and (indirectly) openssl. The important CA files are:

ca.crt — This is the CA certificate
index.txt — This is the «master database» of all issued certs
serial — Stores the next serial number (serial numbers increment)
private/ca.key — This is the CA private key (security-critical)
certs_by_serial/ — dir with all CA-signed certs by serial number
issued/ — dir with issued certs by commonName

After Creating a PKI

Once you have created a PKI, the next useful step will be to either create a CA, or generate keypairs for a system that needs them. Continue with the relevant section below.

Using Easy-RSA as a CA

Building the CA

In order to sign requests to produce certificates, you need a CA. To create a new CA in a PKI you have created, run:

Be sure to use a strong passphrase to protect the CA private key. Note that you must supply this passphrase in the future when performing signing operations with your CA, so be sure to remember it.

During the creation process, you will also select a name for the CA called the Common Name (CN.) This name is purely for display purposes and can be set as you like.

Importing requests to the CA

Once a CA is built, the PKI is intended to be used to import requests from external systems that are requesting a signed certificate from this CA. In order to sign the request, it must first be imported so Easy-RSA knows about it. This request file must be a standard CSR in PKCS#10 format.

Regardless of the file name to import, Easy-RSA uses a «short name» defined during import to refer to this request. Importing works like this:

The nameOfRequest should normally refer to the system or person making the request.

Signing a request

Once Easy-RSA has imported a request, it can be reviewed and signed. Every certificate needs a «type» which controls what extensions the certificate gets Easy-RSA ships with 3 possible types: client , server , and ca , described below:

client — A TLS client, suitable for a VPN user or web browser (web client)
server — A TLS server, suitable for a VPN or web server
ca — A subordinate CA, used when chaining multiple CAs together

Additional types of certs may be defined by local sites as needed; see the advanced documentation for details.

Revoking and publishing CRLs

If an issue certificate needs to be revoked, this can be done as follows:

To generate a CRL suitable for publishing to systems that use it, run:

Note that this will need to be published or sent to systems that rely on an up-to-date CRL as the certificate is still otherwise valid.

Using Easy-RSA to generate keypairs & requests

Easy-RSA can generate a keypair and certificate request in PKCS#10 format. This request is what a CA needs in order to generate and return a signed certificate.

Ideally you should never generate entity keypairs for a client or server in a PKI you are using for your CA. It is best to separate this process and generate keypairs only on the systems you plan to use them.

Easy-RSA can generate a keypair and request with the following command:

You will then be given a chance to modify the Subject details of your request. Easy-RSA uses the short name supplied on the command-line by default, though you are free to change it if necessary. After providing a passphrase and Subject details, the keypair and request files will be shown.

In order to obtain a signed certificate, the request file must be sent to the CA for signing; this step is obviously not required if a single PKI is used as both the CA and keypair/request generation as the generated request is already «imported.»

Name already in use

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

easy-rsa is a CLI utility to build and manage a PKI CA. In laymen’s terms, this means to create a root certificate authority, and request and sign certificates, including intermediate CAs and certificate revocation lists (CRL).

If you are looking for release downloads, please see the releases section on GitHub. Releases are also available as source checkouts using named tags.

For 3.x project documentation and usage, see the README.quickstart.md file or the more detailed docs under the doc/ directory. The .md files are in Markdown format and can be converted to html files as desired for release packages, or read as-is in plaintext.

Getting help using easy-rsa

Currently, Easy-RSA development co-exists with OpenVPN even though they are separate projects. The following resources are good places as of this writing to seek help using Easy-RSA:

The openvpn-users mailing list is a good place to post usage or help questions.

You can also try libera.chat IRC network, in channels #openvpn for general support or #easyrsa for development discussion.

The easy-rsa master branch is currently tracking development for the 3.x release cycle. Please note that, at any given time, master may be broken. Feel free to create issues against master, but have patience when using the master branch. It is recommended to use a release, and priority will be given to bugs identified in the most recent release.

The prior 2.x and 1.x versions are available as release branches for tracking and possible back-porting of relevant fixes. Branch layout is:

LICENSING info for 3.x is in the COPYING.md file

Code style, standards

We are attempting to adhere to the POSIX standard, which can be found here:

Собственная инфраструктура открытых ключей на базе EasyRSA

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

Ожидается, что читатель знает достаточно про TSL/SSL, в состоянии заполучить выделенный сервер с установленной операционной системой Ubuntu 18.04 LTS (для экспериментов используйте промо-код на сто долларов), а также владеет навыками ее администрирования.

Составляющие инфраструктуры

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

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

Например, для доступа к VPN сотрудник использует именно сертификат, а не имя пользователя и пароль. При установлении соединения сервер и клиент проверяют подлинность сертификатов друг друга; если проверки завершены успешно — коммуникация продолжается.

Проверка подлинности, в основном, проводится по трем параметрам:

сертификат должен быть подписанудостоверяющим центром2 ;
сертификат должен иметь неистекший срок действия;
сертификат не должен содержаться в специальном отзывном листе3 , указывающем о явном его аннулировании.

Короче говоря, инфраструктура состоит из удостоверяющего центра и удостоверенных им сущностей.

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

Преимущества и недостатки

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

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

К тому же, с реализацией отзыва есть существенные проблемы 4 .

Приготовления

В вашем распоряжении должен быть выделенный сервер с Ubuntu 18.04 — для настройки удостоверяющего центра. С его помощью вы сможете обрабатывать запросы на подписание сертификата 5 .

Технически вы можете произвести настройку хоть на локальном компьютере, но существует множество причин, по которым этого делать не стоит.

Соглашение

Чтобы придать инструкции большую осмысленность, сыграем в сетевого инженера компании Goldfinch. У нас есть домен goldfinch.im , сервер удостоверяющего центра имеет DNS-имя rca01.goldfinch.im и позволяет использовать систему от имени пользователя support с правами sudo .

Настройка удостоверяющего центра

С помощью SSH подключитесь к целевому серверу:

Скачайте актуальную версию EasyRSA, распакуйте и переименуйте директорию во что-то осмысленное:

Создайте копию файла примера конфигурации:

Конфигурирование EasyRSA

Прочитайте и проверьте файл vars до выполнения дальнейших действий. (Весьма полезными окажутся содержащиеся в нем комментарии.)

X.509 Distinguished Name

EASYRSA_DN — параметр, определяющий процедуру генерации сертификатов.

Свежие версии по умолчанию используют упрощенный формат cn_only (common name only), требующий ввода только универсального имени.

При использовании «классического» значения org (organization), генератор, помимо универсального имени, потребует указать дополнительные атрибуты: страну, регион, город, название организации и ее подразделения, а также адрес электронной почты.

Мы выберем «классический» вариант из-за большей наглядности результата. Переопределите значение:

Укажите значения следующих параметров (они будут использоваться по умолчанию при выпуске сертификатов):

Размер файлов ключей

Параметр EASYRSA_KEY_SIZE определяет размер генерируемых ключей. По умолчанию используется 2048 бит, чего во многих случаях достаточно.

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

Срок действия сертификатов

EASYRSA_CA_EXPIRE устанавливает срок действия ключа удостоверяющего центра (3650 дней), EASYRSA_CERT_EXPIRE — для остальных выпускаемых сертификатов (1080 дней).

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

Инициализация инфраструктуры

Генерация корневого сертификата удостоверяющего центра

Генератор попросит указать семь атрибутов для нового сертификата; для шести из них будет предложено значение по умолчанию. Остается придумать универсальное имя 6 . (Например, Goldfinch Trusted Network CA .)

Чтобы оставить значение какого-либо атрибута пустым используйте символ точки .

Обратите внимание, что в примере указан необязательный параметр nopass , благодаря которому EasyRSA не будет запрашивать пароль при каждом вызове.

Будут созданы сертификат pki/ca.crt и секретный ключ pki/private/ca.key .

Использование готовой инфраструктуры

В любой непонятной ситуации используйте подсказки EasyRSA. Посмотреть список поддерживаемых команд можно вызовом ./easyrsa help (информация по отдельно взятой команде — ./easyrsa help COMMAND ).

Описание процесса

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

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

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

Практикум

Самое время составить запрос на выдачу первого сертификата. Предположим, что у нашей компании есть подрядчик — организация Acme, сотрудники которой должны получить доступ в нашу сеть.

NB! Важная особенность

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

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

Инфраструктура открытых ключей Acme

Сетевому инженеру Acme предстоит выполнить уже известные шаги:

настроить выделенный сервер;
скачать EasyRSA;
отредактировать конфигурационный файл;
инициализировать инфраструктуру;
сгенерировать корневой сертификат собственного удостоверяющего центра;
сгенерировать запросы (по одному на каждого сотрудника, нуждающегося в доступе) на получение сертификата у компании—клиента.

Параметры конфигурации Acme могут выглядеть следующим образом:

В качестве универсального имени для сертификата удостоверяющего центра можно использовать Acme Trusted Network CA .

Со стороны Acme

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

Обратите внимание, что некоторые атрибуты (отдел, электронная почта) сертификата Алисы могут быть указаны вручную и отличаться от значений по умолчанию:

После этого сетевой инженер Acme передает файл alice.req сетевому инженеру Goldfinch.

Со стороны Goldfinch

Сетевой инженер Goldfinch принял файл запроса. Прежде всего, он должен загрузить его на сервер удостоверяющего центра:

После выполнить на сервере удостоверяющего центра процедуру импорта и подписания: