TLS и SSL: Необходимый минимум знаний –

Что такое ssl и что такое tls?

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications.

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

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

SSL 1.0 — никогда не публиковалсяSSL 2.0 — февраль 1995 годаSSL 3.0 — 1996 годTLS 1.0 — январь 1999 годаTLS 1.1 — апрель 2006 годаTLS 1.2 — август 2008 года

Что такое ssl-сертификат?

Многие наверняка слышали про

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

$2.1. подготовка конфигурации и файлов для подписи сертификатов.

Создайте конфигурационный файл с именем ca.config следующего содержания.

[ ca ]
default_ca             = CA_CLIENT       # При подписи сертификатов
# использовать секцию CA_CLIENT

[ CA_CLIENT ]
dir                    = ./db            # Каталог для служебных файлов
certs                  = $dir/certs      # Каталог для сертификатов
new_certs_dir          = $dir/newcerts   # Каталог для новых сертификатов

database               = $dir/index.txt  # Файл с базой данных
# подписанных сертификатов
serial                 = $dir/serial     # Файл содержащий серийный номер
# сертификата
# (в шестнадцатиричном формате)
certificate            = ./ca.crt        # Файл сертификата CA
private_key            = ./ca.key        # Файл закрытого ключа CA

default_days           = 365             # Срок действия подписываемого
# сертификата
default_crl_days       = 7               # Срок действия CRL (см. $4)
default_md             = md5             # Алгоритм подписи

policy                 = policy_anything # Название секции с описанием
# политики в отношении данных
# сертификата

[ policy_anything ]
countryName            = optional        # Код страны - не обязателен
stateOrProvinceName    = optional        # ......
localityName           = optional        # ......
organizationName       = optional        # ......
organizationalUnitName = optional        # ......
commonName             = supplied        # ...... - обязателен
emailAddress           = optional        # ......

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

$2.3. подпись запроса на сертификат (csr) с помощью доверенного сертификата (ca).

При подписи запроса используются параметры заданные в файле ca.config (см. $2.1.)

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

Описание аргументов:

ca

Подпись запроса с помощью CA.

-config ca.config

Использовать конфигурационный файл ca.config.

-in client01.csr

CSR находится в файле client01.csr

-out client01.crt

Сохранить сертификат в файл client01.crt

-batch

Не спрашивать подтверждения подписи.

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

# openssl x509 -noout -text -in client01.crt

$2.4. подготовка данных для передачи клиенту.

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

# openssl pkcs12 -export -in client01.crt -inkey client01.key
-certfile ca.crt -out client01.p12 -passout pass:q1w2e3

Описание аргументов:

pkcs12

Работа с файлами формата PKCS#12.

-export

Экспортирование данных в файл.

-in client01.crt

Файл клиентского сертификата.

-inkey client01.key

Файл закрытого ключа.

-certfile ca.crt

Файл доверенного сертификата.

-out client01.p12

Сохранить данные в файл client01.p12.

-passout pass:q1w2e3

Установить пароль q1w2e3 на файл (пароль может быть любым, в том числе и пустым)

На этом процесс создания клиентского сертификата завершен. Теперь вам необходимо передать клиенту файл client01.p12 и пароль
к нему любым удобным безопасным способом, а также проинструктировать его о процедуре инсталяции сертификата в броузер.

Для создания новых клиентских сертификатов повторите операции с $2.2. по $2.4.

$3. настройка веб-сервера.

Для реализации процесса авторизации по клиентским сертификатам необходимо сконфигурировать веб-сервер для решения следующих
задач:

$4.3. настройка веб-сервера

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

SSLCARevocationFile /path/to/ca.crl

Описание директив:

SSLCARevocationFile /path/to/ca.crl

Абсолютный путь до файла со списком отзыва сертификатов (см. $4.1.)

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

# apachectl restart

[ ca ]

Раздел [ca] является обязательным. Заморачиваться с ним не будем и скажем ему, что хотим свою секцию по умолчанию.

[ ca ] 
default_ca = CA_default

[ ca_default ]

В секции [CA_default] зададим значения по умолчанию. Сначала пропишем пути основных директорий

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге
# (чтоб не редактировать в ста местах)
dir = /root/ca/RootCA
certs = $dir/certs
new_certs_dir = $certs
private = $dir/certs
crl_dir = $dir/crl
serial = $dir/serial 
database = $dir/index.txt
RANDFILE = $dir/private/.rand

• dir – это исключительно наша переменная, для того, чтоб сэкономить нам время. Тут мы укажем пусть до основной директории того ЦС, для которого конфигурация будет предназначена;
• certs – эта переменная для сертификатов, ей мы указываем нашу папку;
• new_certs_dir – аналогично certs (в разных версиях OpenSSL разные переменные для сертификатов), поэтому указываем обе;
• private – в эту переменную передаем место нашей приватной директории, в описании директорий, мы уже говорили, что тут храним приватные ключи;
• crl_dir – как уже говорили, тут будет путь к директории отозванных сертификатов;
• serial – указываем наш файл serial;
• database – текстовая база данных, наш index.txt;
• RANDFILE – случайный файл для случайных данных.

Идем дальше и укажем теперь определенные параметры

# Сертификат и ключ, которым будет подписан другой сертификат,
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key = $private/RootCA.key.pem
certificate = $certs/RootCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber = $dir/crlnumber
crl = $crl_dir/RootCA.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

# используемый алгоритм хеширования
default_md = sha256

name_opt = ca_default
cert_opt = ca_default

default_days = 365
preserve = no
policy = policy_root

policy
policy — в разных конфигурациях мы укажем разные значения. У нас их будет несколько: policy_root, policy_intermediate_person, policy_intermediate_server, policy_intermediate_code.
policy_root — будет в конфигурации для корневого сертификата, и у него будет заданы жесткие правила для подписи промежуточных.
policy_intermediate — а эта секция правил будет в конфигурации промежуточных, и правила подписи будут не такими строгими.

Параметры:

Напишем политики, о которых мы сказали в примечании

[ policy_root ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ policy_intermediate_person ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional

[ policy_intermediate_code ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ policy_intermediate_server ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = supplied

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

[ req ]

Параметры из раздела [req] применяются при создании сертификатов или запросов на подпись сертификата.

[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha256

# Расширение при использовании опции -x509.
x509_extensions = root_ca

Что можно сказать тут:

[ req_distinguished_name ]

Как мы уже сказали, тут перечислим поля, которые нам нужны для сертификата.

[ req_distinguished_name ]
countryName = Country Name (2 letter code) (C)
countryName_min = 2
countryName_max = 2
countryName_default = RU

stateOrProvinceName = State or Province Name (S)
stateOrProvinceName_default = Krasnoyarskiy kray

localityName = Locality Name (L)
localityName_default = Norilsk

0.organizationName = Organization Name (O)
0.organizationName_default = CertService

organizationalUnitName = Organizational Unit Name (OU) organizationalUnitName_default = CertService. IT-Department.

commonName = Common Name (CN)
#commonName_default = CertService.info

emailAddress = Email Address
emailAddress_max = 60
#emailAddress_default = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

С этим все, теперь идем дальше.

«прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент.

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

Где купить ssl-сертификат?

Приобретают сертификаты обычно не напрямую у удостоверяющего центра, а через партнёров. В России продажей сертификатов известных удостоверяющих центров (УЦ), таких как Comodo, Geotrust, GoDaddy, GlobalSign, Symantec и прочих, занимается множество компаний.

Для конечных сертификатов

Клиентские (для аутентификации и почты)

Для корневого сертификата

Для корневого сертификата у нас секция будет называться root_ca.

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

• subjectKeyIdentifier – идентификатор субъекта. Может быть шестнадцатеричной строкой (hex), либо хешем (hash);
• authorityKeyIdentifier – этот параметр допускает всего два значения keyid и issuer. Keyid – копирует идентификатор ключевого слова из родительского, если не получается получить и стоит always, то вернется ошибка. Issuer копирует issuer(подписанта) и серийный номер из сертификата, которым подписан. Он работает, только в том случае, если не работает keyid;
• basicConstraints – CA – если true, то разрешает быть issuer’ом, false – нет (для уточнения: issuer – эмитет (подписант), т.е. может подписывать сертификаты);
• keyUsage – что может делать сертификат;

Значение ключа keyUsage|Описание
— — serverAuth Аутентификация веб-сервера SSL / TLS.
clientAuth Аутентификация веб-клиента SSL / TLS.
codeSigning Подписание кода.
emailProtection Защита электронной почты (S / MIME).
timeStamping Доверенная отметка времени.
msCodeInd Microsoft Индивидуальная подмена кода (аутентификация).
msCodeCom Microsoft Подписание коммерческого кода (аутентификация).
msCTLSign Microsoft Доверенный лист подписей.
msSGC Microsoft Сервер криптографической защиты.
msEFS Microsoft Шифрование файловой системы.
nsSGC Netscape Server Gated Crypto.

Для промежуточных сертификатов

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

Важное замечание:
Параметр basicConstraints содержит «pathlen:0». pathlen указывает максимальное количество ЦС, которые могут появляться ниже этого в цепочке. Поэтому, если у вас есть ЦС с нулевой точкой, он может использоваться только для подписывания сертификатов конечных пользователей, а не для дальнейших ЦС.

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

Запрос на подпись (csr, certificate sign request)

Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.

Защита для бизнеса и клиентов

Каким же сайтам нужна защита SSL? Да практически всем. Особенно тем, которые в наибольшей степени подвержены атакам: ресурсам финансовых учреждений, крупных брендов, сайтам, работающим с персональными данными и платёжной информацией.

Как происходит авторизация клиентов?

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

Яркий пример такой авторизации – это платежная система WebMoney Transfer с ее клиентом WM Keeper Light. Подобная схема авторизации является очень надежной, поэтому она активно применяется в банковской сфере.

Чтобы реализовать процесс авторизации по клиентским SSL сертификатам, необходимо выполнить следующее:

1. Получить свой собственный доверенный сертификат Certificate Authority, чтобы потом с его помощью подписывать и верифицировать клиентские сертификаты.
2. Создать клиентские сертификаты, которые затем будут передаваться клиентам. Такие сертификаты должны быть подписаны доверенным сертификатом.
3. Настроить сервер, чтобы он должным образом запрашивал и верифицировал клиентские SSL-сертификаты.

Работа с ключами обычно осуществляется при помощи утилиты OpenSSL, про которую мы писали в следующей статье.

Клиентский SSL-сертификат вы всегда можете приобрести в компании ЛидерТелеком, выбрав для себя подходящий вариант по оптимальной цене.

Корневой сертификат

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

Настройка apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

# Директория, содержащая корневые сертификаты для проверки клиентов
SSLCARevocationPath /etc/apache2/ssl.crl/
# или файл, содержащий сертификаты
SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Опция верификации клиента. Возможные варианты:
# none, optional, require and optional_no_ca
SSLVerifyClient require
# Глубина просмотра цепочки подписей. По умолчанию 1
SSLVerifyDepth  2

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

Настройка nginx на использование клиентских сертификатов

Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:

# Корневой сертификат(ы), которым(и) подписан клиентский
ssl_client_certificate /etc/nginx/certs/clientroot.pem;
# Возможные варианты: on | off | optional | optional_no_ca
ssl_verify_client optional;
# Глубина проверки цепочки сертификатов, которыми подписан клиентский
ssl_verify_depth 2;

После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

Работаем с сертификатами

Создаем корневой приватный ключ

openssl genrsa -aes256 -out /root/ca/RootCA/private/RootCA.key.pem 4096 chmod 400 /root/ca/RootCA/private/RootCA.key.pem

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

openssl req -config /root/ca/config/RootCA.cnf 
-key /root/ca/RootCA/private/RootCA.key.pem 
-new -x509 -days 7300 -sha256 -extensions root_ca 
-out /root/ca/RootCA/certs/RootCA.cert.pem
chmod 444 /root/ca/RootCA/certs/RootCA.cert.pem

Проверяем валидность сертификата

openssl x509 -noout -text -in /root/ca/RootCA/certs/RootCA.cert.pem

Создаем промежуточные и подписываем их корневым

#Создаем приватный ключ 
openssl genrsa -aes256 
-out /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem 4096
chmod 400 /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem
#Создаем запрос
openssl req -config /root/ca/config/PersonIntermediateCA.cnf -new -sha256 
-key /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem 
-out /root/ca/PersonIntermediateCA/csr/PersonIntermediateCA.csr.pem #Создаем подписанный сертификат
openssl ca -config /root/ca/config/RootCA.cnf -extensions intermediate_ca 
-days 3650 -notext -md sha256 
-in /root/ca/PersonIntermediateCA/csr/PersonIntermediateCA.csr.pem 
-out /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem

Using configuration from /root/ca/config/RootCA.cnf
Enter pass phrase for /root/ca/RootCA/private/RootCA.key.pem: secret

Check that the request matches the signature
Signature ok
Certificate Details:
...
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

chmod 444 /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem

Проверяем валидацию

openssl verify -CAfile /root/ca/RootCA/certs/RootCA.cert.pem  /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem
#result: /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem: OK

Идем дальше и создаем certificate chain

certificate chain — эта цепочка нам нужна, когда у клиента нет корневого, или промежуточного сертификата.

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

cat /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/PersonIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/PersonIntermediateCA/certs/ca-chain.cert.pem

cat /root/ca/CodeIntermediateCA/certs/CodeIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/CodeIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/CodeIntermediateCA/certs/ca-chain.cert.pem cat

/root/ca/ServerIntermediateCA/certs/ServerIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/ServerIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/ServerIntermediateCA/certs/ca-chain.cert.pem

Расширения

Следующие несколько секций — это расширения, которые могут использоваться при создании сертификатов. К примеру, при передаче аргумента командой -extensions root_ca будет применяться секция [ root_ca ].

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ2) Сгенерировать запрос на подпись3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата

Создадим по одному сертификату для каждого подразделения

Клиент (используем -extensions

Структура директорий на сервере ca

Наша основная директория /root/ca. А вот у нее внутри уже видим следующее:

Уровни проверки ssl-сертификатов

Существуют сертификаты разных уровней проверки. Для защиты персональных данных пользователей подойдёт сертификат с упрощённой проверкой — DV (Domain validation). Сертификат с проверкой доменов — самый низкий и недорогой уровень. Он доступен физическим и юридическим лицам, выдаётся владельцу или администратору доменного имени и просто подтверждает это доменное имя.

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

Для более качественной проверки компании и её полномочий на приобретение сертификатов используются так называемые сертификаты с расширенной проверкой — EV (Extended validation). Это самый престижный вид сертификатов. Такие сертификаты вызывают больше всего доверия.

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

Эта схема показывает доли сертификатов DV, OV и EV у основных удостоверяющих центров. Сертификаты DV составляют около 70% от сертификатов всех типов, на EV приходится менее 5%.

Бывают сертификаты для одного, нескольких доменов (SAN) и сертификаты для всех прямых поддоменов выбранного домена (Wildcard).

Установка ssl/tls-сертификата на сервер с apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

Установка ssl/tls-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

Уходим в консоль

Базовую конфигурацию мы подготовили, теперь можно и в консоль идти 🙂

Создаем рабочие директории

mkdir -p /root/ca/config
mkdir -p /root/ca/{RootCA,PersonIntermediateCA,ServerIntermediateCA,CodeIntermediateCA}/{certs,crl,newcerts,private}
mkdir -p /root/ca/{PersonIntermediateCA,ServerIntermediateCA,CodeIntermediateCA}/csr

Выставим всем private права 400

chmod 400 /root/ca/RootCA/private
chmod 400 /root/ca/PersonIntermediateCA/private
chmod 400 /root/ca/ServerIntermediateCA/private
chmod 400 /root/ca/CodeIntermediateCA/private

Создаем файлы конфигурации

touch /root/ca/config/RootCA.cnf
touch /root/ca/config/PersonIntermediateCA.cnf cp
touch /root/ca/config/ServerIntermediateCA.cnf cp 
touch /root/ca/config/CodeIntermediateCA.cnf

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/RootCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/RootCA.key.pem
certificate       = $certs/RootCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/RootCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_root

[ policy_root ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/PersonIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/PersonIntermediateCA.key.pem
certificate       = $certs/PersonIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/PersonIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_person

[ policy_intermediate_person ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ user_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "Client certificates"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment 
extendedKeyUsage = clientAuth, emailProtection

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/ServerIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/ServerIntermediateCA.key.pem
certificate       = $certs/ServerIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/ServerIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_server

[ policy_intermediate_server ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = supplied

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
# Серверный
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/CodeIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/CodeIntermediateCA.key.pem
certificate       = $certs/CodeIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/CodeIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_code

[ policy_intermediate_code ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = [email protected]

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ code_cert ]
# Для подписи кода
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "Code Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = digitalSignature
extendedKeyUsage = codeSigning, msCodeInd, msCodeCom

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Создадим наши недо-базы данных

Цепочка действий по генерации сертификатов

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

Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.

$4.2. отзыв сертификата.

Для того чтобы отозвать клиентский сертификат необходимо пометить его в базе данных сертификатов db/index.txt как отозванный, тогда
при следующем обновлении списка отзыва, этот сертификат будет в него включен. Для пометки сертификата как отозванного используйте
приведенную ниже команду.

# openssl ca -config ca.config -revoke client01.crt

Описание аргументов:

-revoke client01.crt

Отозвать сертификат находящийся в файле client01.crt

$4.1. создание списка отзыва (crl).

При создании списка отзыва используется тот же конфигурационный файл и таже структура файлов, что и при подписи сертификатов (см. $2.1.),
поэтому при выполнении следующей команды вы должны находиться в том же каталоге. sexe24.ch

# openssl ca -gencrl -config ca.config -out ca.crl

Описание аргументов:

ca

При создании CRL также используется этот аргумент.

-gencrl

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

-config ca.config

Использовать конфигурационный файл ca.config.

-out ca.crl

Сохранить созданный список отзыва в файл ca.crl

В результате будет создан список отзыва, основанный на базе данных подписанных сертификатах db/index.txt. Так как на данный момент
ни один из сертификатов в базе данных не помечен как отозванный, то созданный список будет пустым. Просмотреть данные списка отзыва
вы можете с помощью следующей команды.

# openssl crl -in ca.crl -text -noout

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

Заключение.

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

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

В openssl не предусмотрен механизм блокирования одновременного доступа к ресурсам, то есть, если две программы одновременно будут
осуществлять подпись сертификата, то корректность содержимого текстовой базы данных, файла с серийным номером, как впрочем и самого
результата не гарантируется. Поэтому необходимо использовать внешний механизм блокировки, например, так это можно реализовать на языке
Perl.

open ( LOCK, ">/tmp/cert-sign.lck" ) or error_handling();
flock ( LOCK, 2 ) or error_handling();

# ... код, реализующий подпись сертификата ...

close( LOCK );

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

$4. отзыв сертификатов.

Результат проверки веб-сервером клиентского сертификата будет успешным на весь срок действия сертификата. Возникает вопрос, что делать
в случае если вы хотите отказать какому-либо клиенту в доступе по его клиентскому сертификату. Для решения этой проблемы создается
список отзыва сертификатов (Certificate Revocation List – CRL).