Авторизация с помощью сертификата ssl на nginx + Let’s Encrypt

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

Это копия моей статьи с Хабра Авторизация с помощью сертификата ssl на nginx + Let’s Encrypt.

В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом, так же можно использовать 1С WEB клиент. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и т.д.), тут на глаза попались статьи про доступ по ssl сертификату. 

Исходные данные:

Сервер с учетной программой + web интерфейс находятся в DMZ;
WEB-server на nginx, на него проброшены порты http(80) и https(443);
На web-server настроен proxy_pass на сервер с учетной программой, доступ только по порту 8080 и только с IP web-server, большего доступа с серверу нет(обычная безопасность);
На сайт для доступа установлен сертификат от Let’s Encrypt.

Переходим к самому процессу создания сертификата пользователя:

Для сертификатов будем использовать каталог "/etc/ssl/crm.example.ru"

Создаём структуру каталогов:

# mkdir /etc/ssl/crm.example.ru
# cd /etc/ssl/crm.example.ru
# mkdir db
# mkdir db/certs
# mkdir db/newcerts
# touch db/index.txt
# echo "01" > db/serial
# chmod 700 ./

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

/etc/ssl/crm.example.ru/ca.conf"

[ ca ]
default_ca               = CA_CITENAME           # Секция по умолчанию для подписи сертификатов

[ CA_CITENAME ]
droot                    = /etc/ssl/crm.example.ru # Корневой каталог хранилища
dir                      = $droot/db             # Каталог базы хранилища
certs                    = $dir/certs            # Каталог сертификатов
new_certs_dir            = $dir/newcerts         # Каталог для новых сертификатов (pem)

database                 = $dir/index.txt        # Файл базы сертификатов
serial                   = $dir/serial           # Файл серийного номера

# Файл доверенного сертификата
certificate              = $droot/ca.crt
# Закрытый ключ доверенного сертификата
private_key              = $droot/ca.key

default_days             = 365                   # Срок действия нового сертификата (дни)
default_crl_days         = 7                     # Срок действия списка отозванных сертификатов
default_md               = md5                   # Использовать алгоритм MD5

policy                   = policy_citename       # Политика секции

[ policy_citename ]
countryName              = optional              # Необязательный параметр
stateOrProvinceName      = optional              # .......................
localityName             = optional              # .......................
organizationName         = optional              # .......................
organizationalUnitName   = optional              # .......................
commonName               = supplied              # обязательный параметр
emailAddress             = supplied              # .....................

[ req_distinguished_name ]
countryName                     = Название страны (2-буквенный код)
countryName_default             = RU
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = Название области (полное название)
stateOrProvinceName_default     = Tyumen region

localityName                    = Название местности (например, город)
localityName_default            = Tyumen

0.organizationName              = Название организации
0.organizationName_default      = EXAMPLE

organizationalUnitName          = Название организационной единицы (например, отдел)

commonName                      = Ваше имя
commonName_max                  = 64

emailAddress                    = Email адрес
emailAddress_max                = 64

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

# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 \r
-subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=crm.example.ru/emailAddress=crm@example.ru" \r
-out ca.crt

Либо, если хотите всё вводить вручную.
 

# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 -out ca.crt

Просмотреть данные закрытого ключа и сертификата вы можете с помощью команд:

# openssl rsa -noout -text -in ca.key              (для ключа)
# openssl x509 -noout -text -in ca.crt             (для сертификата)

Создание клиентского закрытого ключа и запроса на сертификат (CSR):

# openssl req -new -newkey rsa:2048 -nodes -keyout client01.key \r
-subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=User example1/emailAddress=user@example1.ru" \r
-out client01.csr

Либо, если хотите всё вводить вручную.

#openssl req -new -newkey rsa:2048 -nodes -keyout client01.key -out client01.csr

За место User example1 можно указать почту клиента, а за место EXAMPLE компанию клиента, это поможет отслеживать сертификаты.

В результате выполнения команды появятся два файла client01.key и client01.csr. Просмотреть данные закрытого ключа и запроса на сертификат (CSR) вы можете с помощью команд:

# openssl rsa -noout -text -in client01.key             (для ключа)
# openssl req -noout -text -in client01.csr             (для запроса)

Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).
При подписи запроса используются параметры заданные в файле ca.config

# openssl ca -config ca.config -in client01.csr -out client01.crt -batch

Подготовка данных для передачи клиенту.
Для передачи полученных в результате предыдущих операций файлов клиенту, обычно используется файл в формате PKCS#12. В этот файл упаковывается и защищается паролем вся информация необходимая клиенту для инсталляции сертификата в броузер.

# openssl pkcs12 -export -in client01.crt -inkey client01.key \r
-certfile ca.crt -out client01.p12 -passout pass:123ewqasdcxz

Выставляем права доступа на ключи.

# chmod 600 /etc/ssl/crm.example.ru/client*.crt
# chmod 600 /etc/ssl/crm.example.ru/client*.key

Переместим все созданные файлы в каталог db/certs на хранение.

# mv ./client01.* db/certs/

В nginx надо установить:

            ssl_client_certificate      /etc/ssl/crm.example.ru/ca.crt;
ssl_verify_client           on;
ssl_verify_depth            1;

Для того чтобы клиент смог подключиться по сертификату ему необходимо отправить файл client01.p12 и ca.crt, а так же сообщить пароль для установки сертификата. ca.crt необходим, так как мы не используем его для сертификации сервера, для этомо используеться Let’s Encrypt.

Процесс выдачи сертификатов можно автоматизировать, написать просто скрип не составит труда. У нас таких клиентов не много, около 15, так что вбить всё руками не составило проблем.

В подготовке материала помогли статьи:
«Авторизация клиентов в nginx посредством SSL сертификатов» 
«Авторизация по SSL сертификатам»
«Авторизация с помощью клиентских SSL сертификатов. (ssl crypt mod_ssl apache)» 
«Великий и могучий Google»

P.S. Проверка проводилась на Google Chrome.