Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру

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

Сделаем это, выполнив на клиенте следующую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/truststore.jks -storepass secret -noprompt


На сервере выполним такую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.

Выполним на клиенте такую команду:

keytool -v -delete -alias server -keystore client/src/test/resources/truststore.jks -storepass secret

Вот — команда для сервера:

keytool -v -delete -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret


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

$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.3. альтернативные способы настройки веб-сервера.

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

Пример 1.

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

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

SSLRequire %{SSL_CLIENT_I_DN_O} eq “First CA Inc.”
Требует чтобы организацией поставщика клиентского сертификата являлась “First CA Inc.”. Аналогичным способом можно
проверять любые другие параметры клиентского сертификата или его поставщика. Более подробную информацию о директиве
SSLRequire и именах переменных смотрите в документации по mod_ssl.

Пример 2.

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

[ 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_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 = support@CertService.info

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

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

Запуск сервера


Для того чтобы организовать работу сервера — нам понадобится следующее:

  1. Java 11
  2. Maven 3.5.0
  3. Eclipse, Intellij IDEA (или любой другой текстовой редактор вроде VIM)
  4. Доступ к терминалу
  5. Копия этого проекта

Если вы хотите приступить к экспериментам и при этом ничего не устанавливать — можете

вышеупомянутый проект в онлайновой среде разработки Gitpod.

В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.

Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.

git checkout tags/java-8-compatible

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

Сервер можно привести в рабочее состояние, вызвав метод main класса App или выполнив следующую команду в корневой директории проекта:

cd server/ && mvn spring-boot:run


Вот команда, рассчитанная на Maven-обёртку:

cd server-with-spring-boot/ && ./../mvnw spring-boot:run

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

Собственный доверенный сертификат (Certificate Authority – далее CA) необходим для подписи клиентских сертификатов и для их проверки при вторизации клиента веб-сервером.

Похожее:  EMV - EMV - abcdef.wiki

openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 5000 -subj /C=RU/ST=Msk/L=Msk/O=My Inc/OU=Sale/CN=bla/emailAddress=usr@dom.ru -out ca.crt

Описание аргументов:
   –req
Запрос на создание нового сертификата.
   -new
Создание запроса на сертификат (Certificate Signing Request –
далее CSR).
   -newkey rsa:1024
Автоматически будет создан новый закрытый RSA ключ длиной 1024
бита. Длину ключа можете настроить по своему усмотрению.
-nodes
Не шифровать закрытый ключ (См. примечание выше).
   -keyout ca.key
Закрытый ключ сохранить в файл ca.key.
   -x509
Вместо создания CSR (см. опцию -new) создать самоподписанный
сертификат.
   -days 5000
Срок действия сертификата 5000 дней. Размер периода действия
можете настроить по своему усмотрению. Не рекомендуется вводить
маленькие значения, так как этим сертификатом вы будете
подписывать клиентские сертификаты.
   -subj /C=RU/ST=Msk/L=Msk/O=My
Inc/OU=Sale/CN=bla/emailAddress=usr@dom.ru

Данные сертификата, пары параметр=значение, перечисляются через
‘/’. Символы в значении параметра могут быть “подсечены” с
помощью обратного слэша “”, например “O=My Inc”. Также можно
взять значение аргумента в кавычки, например, -subj
“/xx/xx/xx”.
Описание параметров:
С – Двухсимвольный код страны (Country). Необязательный
параметр.
ST – Название региона/области/края/республики/… (State
Name). Необязательный параметр.
L – Название города/поселка/… (Locality Name).
Необязательный параметр.
O – Название организации (Organization Name).
Необязательный параметр.
OU – Название отдела (Organization Unit). Необязательный
параметр.
CN – Имя сертификата, при создании серверных сертификатов
используется доменное имя сайта, для клиентских
сертификатов может быть использовано что угодно (Common
Name). Обязательный параметр. Максимальная длина 64
символа.
emailAddress – почтовый адрес (E-mail address).
Необязательный параметр. Максимальная длина 40 символов.
Необязательные параметры могут быть пропущены, например,
/C=RU/CN=blabla/emailAddress=user@domain.ru.
   -out ca.crt
Сертификат сохранить в файл ca.crt.

   В результате выполнения команды появятся два файлаca.key и ca.crt.

   Просмотреть данные закрытого ключа и сертификата вы можете с помощью
команд:
        # openssl rsa -noout -text -in ca.key              (для ключа)
        # openssl x509 -noout -text -in ca.crt             (для сертификата)

Создание удостоверяющего центра

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

keytool -v -genkeypair -dname "CN=Root-CA,OU=Certificate Authority,O=Thunderberry,C=NL" -keystore root-ca/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias root-ca -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,keyCertSign -ext BasicConstraints=ca:true,PathLen:3

Ещё можно воспользоваться

удостоверяющим центром.

Создание файла запроса на подпись сертификата


Для того чтобы подписать сертификат — нужен .csr-файл (Certificate Signing Request, файл запроса на подпись сертификата). Создать его можно с помощью особой команды.

Вот её вариант для сервера:

keytool -v -certreq -file shared-server-resources/src/main/resources/server.csr -keystore shared-server-resources/src/main/resources/identity.jks -alias server -keypass secret -storepass secret -keyalg rsa

Вот — эта команда для клиента:

keytool -v -certreq -file client/src/test/resources/client.csr -keystore client/src/test/resources/identity.jks -alias client -keypass secret -storepass secret -keyalg rsa

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

Подписание сертификата с помощью запроса на подпись сертификата


Вот соответствующая команда для клиента:

keytool -v -gencert -infile client/src/test/resources/client.csr -outfile client/src/test/resources/client-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Вот команда для сервера:

keytool -v -gencert -infile shared-server-resources/src/main/resources/server.csr -outfile shared-server-resources/src/main/resources/server-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth -ext SubjectAlternativeName:c=DNS:localhost,IP:127.0.0.1

Аутентификация клиента (двусторонний TLS)

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

client-auth

, сообщив серверу о том, что ему нужно проверять клиентов.

Приведём файл сервера application.yml к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    client-auth: need

Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

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

keytool -v -genkeypair -dname "CN=Suleyman,OU=Altindag,O=Altindag,C=NL" -keystore client/src/test/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias client -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth


Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

keytool -v -exportcert -file client/src/test/resources/client.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret -rfc

Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

keytool -v -importcert -file client/src/test/resources/client.cer -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

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

Приведём файл application.yml клиента к такому виду:

client:
  ssl:
    one-way-authentication-enabled: false
    two-way-authentication-enabled: true
    key-store: identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: truststore.jks
    trust-store-password: secret

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл

application.yml

к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: classpath:truststore.jks
    trust-store-password: secret
    client-auth: need


Если снова запустить клиент — можно будет убедиться в том, что тест завершается успешно, и что клиент получает данные от сервера в защищённом виде.

Примите поздравления! Только что вы настроили двусторонний TLS!

Замена неподписанного сертификата подписанным

В хранилище идентификационных данных сервера и клиента всё ещё хранится неподписанный сертификат. Сейчас можно заменить его на подписанный. У инструмента

keytool

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

identity.jks

Экспортируем подписанный сертификат:

keytool -v -exportcert -file root-ca/root-ca.pem -alias root-ca -keystore root-ca/identity.jks -storepass secret -rfc

Выполним на клиенте следующие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file client/src/test/resources/client-signed.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret

На сервере выполним такие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file shared-server-resources/src/main/resources/server-signed.cer -alias server -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret

Генерируем ключи с помощью ssh-keygen

Для начала необходимо сгенерировать ключи с помощью команды

ssh-keygen

Выполнять данную команду надо без sudo и под тем пользователем, для которого вам необходимо реализовать авторизацию через ssh без пароля. Sudo можно использовать если настраивается доступ для рута. Но в этом случае я бы использовал sudo su.

ssh-keygen предложит вам папку по умолчанию, в которую сохранит ключи. В обычной ситуации стоит оставить этот путь.

Когда ssh-keygen предложит ввести пароль для файла ключей, поле необходимо оставить пустым. Введение пароля хоть и увеличит безопасность и без того надёжного способа авторизации, придётся вводить этот пароль каждый раз. Это излишняя мера для авторизации внутри сети. Но в случае если SSH порт сервера доступен из публичной сети, этот способ может оказаться очень кстати.

В конце ssh-keygen покажет куда сохранены открытый и закрытый ключи, отпечаток ключа и рандомную картинку ключа.

Теперь необходимо установить открытый ключ на наш сервер. Используем для этого ssh-copy-id

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

Для корневого сертификата у нас секция будет называться 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 – что может делать сертификат;
Похожее:  Почему не происходит редирект при авторизации? — Хабр Q&A

Значение ключа 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, и также рекомендую создать расширение для таких сертификатов с параметром равным нулю.

Настраиваем авторизацию в iis по сертификатам используя onetoone

Всем доброго времени суток. Так уж получилось, на работе необходимо было настроить сервер с IIS, да не просто настроить, но повесить авторизацию на разные сервисы с использованием только определенного сервису сертификата. Данная проблема может быть решена использованием нескольких центров генерации, но не будем все усложнять и приступим к настройке «ОдинКОдному» нашего IIS.

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

Переходим к делу:
1) Устанавливаем IIS и необходимые компоненты. Обязательно отмечаем «Проверка подлинности с сопоставлением сертификата клиента IIS».

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

2) Для привязки нам понадобится клиентский сертификат в кодировке base64, его очень просто экспортировать из остнастки (certmgr.msc) «Сертификаты» или из «Свойства обозревателя».

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

3) Полученный сертификат открываем в текстовом редакторе и выстаиваем в одну линию, предварительно удалив строчки «BEGIN CERTIFICATE» и «END CERTIFICATE».

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

С подготовкой закончили переходим к серверу.

4) Запускаем остнастку (inetmgr) «Диспетчер служб IIS», и устанавливаем сертификат сервера. В моём случае CN сертификата Localhost.

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

5) После этого мы можем привязать этот сертификат к сервисам. Идем в привязки и выбрав Https указываем необходимый порт и сертификат.

6) В параметрах SSL отмечаем «Требовать SSL» и сертификат клиента «требовать».

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

7) Теперь любой сертификат выпущенный нашим УЦ подойдет для авторизации, но цель данной статьи как раз показать следующий шаг когда клиентов с сертификатами необходимо разделить. Идем в «Редактор конфигураций» по адресу: «system.webServer/security/authentication/iisClientCertificateMappingAuthentication».

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

8) Здесь предстоит сделать выбор или мы пускаем по конкретным сертификатам или по определенному полю в сертификате (например уникальный OID).

9) Рассмотрим параметр «oneToOneCertificateMappingsEnabled». Установив его значении в «True» мы сможем привязать конкретный сертификат к пользователю.

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

10) Полученный на втором пункте сертификат вставляем в поле «certificate». Поля «userName» и «password» заполняем учетной записью, которую предварительно создали.

11) Теперь при предъявлении занесенного клиентского сертификата мы получим доступ с правами указанной учетной записи. Однако все остальные сертификаты продолжат преспокойно работать и получать анонимный доступ, что бы этого избежать необходимо в iis, отключить анонимную проверку подлинности.

Шпаргалки Админа: Аутентификация по клиентским SSL сертификатам в Apache

На этом этапе авторизация должна проходить только по заданному сертификату.

Код для appcmd:

appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/iisClientCertificateMappingAuthentication /enabled:"True" /oneToOneCertificateMappingsEnabled:"True"  /commit:apphost

appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/iisClientCertificateMappingAuthentication / "oneToOneMappings.[userName='22',password='22',certificate='текст сертификата в кодировке base64']" /commit:apphost

appcmd.exe set config "Default Web Site" -section:system.webServer/security/access /sslFlags:"Ssl, SslNegotiateCert, SslRequireCert"  /commit:apphost

Общая схема аутентификации по сертификатам

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

  1. Пользователь запрашивает доступ к некоторой сетевой службе;
  2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
  3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
  4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
  5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
  6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

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

  1. Клиент запрашивает установку безопасного канала;
  2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
  3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
  4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
  5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
  6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

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


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

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

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

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

Похожее:  25 советов по кладоискательству для начинающих

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

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
RootCA.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          = support@CertService.info

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

PersonIntermediateCA.cnf

[ 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          = support@CertService.info

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

ServerIntermediateCA.cnf

[ 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          = support@CertService.info

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

CodeIntermediateCA.cnf

[ 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          = support@CertService.info

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

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

Заключение.

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

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

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

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

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

close( LOCK );

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

$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.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector