Форум русскоязычного сообщества Ubuntu


Следите за новостями русскоязычного сообщества Ubuntu в Twitter-ленте @ubuntu_ru_loco

Автор Тема: HOW-TO: Создание собственного центра сертификации (CA - Certificate Authority)  (Прочитано 120293 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Создание центра сертификации электронных ключей на базе Ubuntu

1. Что такое электронные ключи, сертификаты, и зачем нужен центр сертификации электронных ключей

Электронный ключ - это просто очень большое, предположительно, уникальное число. (Порядок великости - нууу, примерно как отсюда до центра вселенной и обратно. Повторить несколько тысяч миллионов раз - это будет примерно одна триллионная возможных значений. В общем - дофига.) Или вы можете просто считать его набором битов, длиной от 512 до 4096 бит. Чем он, по сути, и является.
Электронные ключи применяются для защиты каналов связи, шифрования переписки и других данных, подписывания документов и исполнимого кода программ... И это только небольшая часть применения электронных ключей, хотя во многих случаях всё разнообразие способов использования можно свести к трём основным: шифрование данных, подписывание данных, аутентификация участника.
Сертификат ключа электронной подписи - это электронный (же) документ, утверждающий право владельца соответствующего электронного ключа на совершение этим ключом определённых действий. Например, на подписывание документов.
Центр сертификации (Certificate Authority) - это система, позволяющая создавать, распределять и управлять сертификатами электронных ключей.
Как вы можете заключить из вышеизложенного, Центр сертификации - штука важная и ответственная. Поэтому не удивляйтесь, что некоторые рекомендации и требования в этой статье выглядят завышенными. Это не требования завышены - это у вас оценка серьёзности предприятия занижена.

$Id: SSL-CA-HOW-TO-1-Why-CA.txt 315 2015-09-18 09:45:01Z anrdaemon $


2. Подготовительные работы

По-хорошему (или, "в идеальном случае..."), под Центр Сертификации желательно отдать отдельную машину, доступ к которой будет физически ограничен строго определённым кругом лиц. В серьёзных центрах сертификации так и поступают.
Зачастую, такая машина даже к локальной сети здания не подключена, не то что к Интернету... У нас, к счастью (или к сожалению), требования не столь жёсткие, так что постараемся обойтись наличными средствами.

2.1. Наличное средство №1: Строго изолированное рабочее пространство.
Пусть у нас нет отдельного физического сервера, это не означает, что мы можем радостно свалить всю структуру CA в /etc/ на первом подходящем компе и спать спокойно.

Варианты выхода из положения могут быть следующими:
а) Виртуальный выделенный сервер. Внимательно выбирайте, что и куда вы ставите. Решения, пригодные для VPS (такие, как OpenVZ) тут НЕ ГОДЯТСЯ - к диску контейнера OpenVZ можно тривиально получить доступ с консоли несущего сервера в обход любых возможных ограничений самого контейнера.
б) Зашифрованный домашний каталог отдельного пользователя. Вероятно, оптимальное решение, но я мало знаком с этой технологией.
в) Расположение CA на внешнем хранилище (например, на Flash-диске). Помимо находящейся под большим вопросом надёжности, этот способ вполне заслуживает внимания.
г) Гибрид указанных способов. Например, хранение на внешнем носителе только главного ключа системы, либо только пароля к нему.

Вы как хотите, а я буду использовать виртуальную машину (в частности, VirtualBox) для создания фиктивного "отдельно стоящего железа". (Во-первых, я с ним хорошо знаком, во-вторых - он у меня уже есть.)
Выгодой такого подхода является почти моментальный перенос "сервера" с места на место, при необходимости я даже могу запускать систему с общего ресурса, находящегося в сети. Скорость будет так себе, но мы же никуда не опаздываем, верно?

Надеюсь, с установкой Ubuntu server под VirtualBox вы справитесь без меня?
Не забудьте поставить (убедиться, что они поставлены) пакеты pwgen, openssl и openssh-server.

2.2. Наличное средство номер #2: Технологический пользователь для пользования полезняшками.
Это всегда хорошая идея - создать отдельного пользователя в системе для выполнения высоко ответственного, строго ограниченного круга задач.
Банальное обслуживание системы может производиться десятком операторов, это нормально. Управление главным центром сертификации должно быть возможно более обособлено. Отсюда же следует, что давать этому пользователю права sudo НЕ НАДО. Он без них нормально проживёт, и вам меньше геморроя.
Один sudo пользователь в системе уже есть - вы. Этого достаточно. Если этого НЕ достаточно, побейтесь об стену головой. Чем больше людей имеет доступ к системе CA, тем больше вероятность её компрометации, либо банального сбоя.

Создаём нового пользователя:

$ sudo -E -s
[sudo] password for anrdaemon: <*****>
# useradd -c "OpenSSL CA administrator" --home /home/.CA --shell /bin/bash --no-user-group --groups ssl-cert,www-data --create-home -p $(pwgen -scn 20) minica
#

Обратите внимание, что пароль мы задаём в формате, отличном от ожидаемого командой useradd. Таким образом, по паролю мы этим пользователем войти в систему не сможем.
Но - оно нам надо? Сразу скажу - нет, не надо.
Сделаем одну значительную поправку - исправим права на домашний каталог и маску прав по умолчанию для вновь создаваемых пользователем файлов.

# chmod -R g=X,o= /home/.CA
(Обратите внимание, следующая строчка без -R !!)
# chmod o=X /home/.CA
# nano /home/.CA/.profile

Возле самого начала файла находится закомментированная строка "umask 022"
Под ней, на новой строчке напишите

Цитировать
umask 0066

И сохраните файл (Ctrl+O, Ctrl+X)
Это предотвратит создание новых файлов с черезчур обширными правами доступа.
Теперь нам надо поработать под новым пользователем.

# sudo -u minica -i
$ pwd
/home/.CA
$

Сейчас мы под именем minica находимся в домашнем каталоге пользователя minica.
Конечно, мы не будем постоянно так делать. Мы поступим проще и скромнее.
Создадим ключ для SSH (ОБЯЗАТЕЛЬНО задайте пароль!):

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/.CA/.ssh/id_rsa):
Created directory '/home/.CA/.ssh'.
Enter passphrase (empty for no passphrase): <myveryownca>
Enter same passphrase again: <myveryownca>
Your identification has been saved in /home/.CA/.ssh/id_rsa.
Your public key has been saved in /home/.CA/.ssh/id_rsa.pub.
The key fingerprint is:
d4:fe:f3:97:f4:10:2d:44:38:29:86:c9:40:a5:a3:b1 sslca@daemon-v5
$

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

$ cp /home/.CA/.ssh/id_rsa.pub /home/.CA/.ssh/authorized_keys
$ exit
# cp /home/.CA/.ssh/id_rsa ~/.ssh/minica-rsa.key
# chown $SUDO_USER ~/.ssh/minica-rsa.key
#

Можно попробовать сразу и подключиться.

# ssh -i /home/anrdaemon/.ssh/minica-rsa.key minica@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is bf:d0:fe:cd:b1:cf:7d:93:61:00:c1:d9:9e:2f:6f:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
Enter passphrase for key '/home/anrdaemon/.ssh/minica.rsa': <myveryownca>
Linux daemon-v5 2.6.24-31-server #1 SMP Fri Apr 27 21:31:40 UTC 2012 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
$ exit
#

Работает?! Работает. Выходим из терминала. Совсем выходим.

# exit
$ exit

Теперь можно скачать ключ себе на машину и подключиться уже по-нормальному под нужным пользователем. Для Linux это будет что-то вроде:

$ scp username@daemon-v5:/home/profile/.ssh/minica-rsa.key ~/.ssh/minica-rsa.key
$ ssh -i ~/.ssh/minica-rsa.key minica@daemon-v5

Для Windows - сами сообразите, десять лет окошками пользуетесь, небось, научились.

$Id: SSL-CA-HOW-TO-2-Preparations.txt 315 2015-09-18 09:45:01Z anrdaemon $


3. Настройка рабочего места

Предыдущую главу мы закончили на том, что подключились к серверу под именем нашего CA-администратора.

$ ssh -i ~/.ssh/minica-rsa.key minica@daemon-v5
Сейчас нам необходимо создать несколько каталогов и создать/отредактировать несколько файлов.
Начнём с простого - установка одной переменной и создание каталогов и файлов.

$ export OPENSSL_CONF=${HOME}/ca.conf
$ mkdir -p ~/bin ~/archive ~/store/keys ~/tmp

В ~/bin мы будем держать наши скрипты.
В ~/archive будут находиться все когда-либо выданные нашим центром сертификаты.
В ~/tmp мы будем складывать временные данные.
В ~/store будем хранить запросы и сертификаты.
В ~/store/keys будем хранить ключи.

$ touch -f ~/.rnd ~/oid_list.txt ~/certdb.txt
$ echo "01" > ~/.certserial
$ echo "01" > ~/.crlserial

Файл ~/.rnd используется при работе генератора ключей.
В ~/oid_list.txt хранятся описания идентификаторов объектов (назначений) сертификатов.
В ~/certdb.txt ведётся база сертификатов (время выдачи, статус, время отзыва - и так далее).
Файл ~/.certserial содержит порядковый номер следующего сертификата.
Файл ~/.crlserial содержит порядковый номер следующего списка отзыва.

Продолжим наши мытарства. Добавим несколько переменных, чтобы программы знали, где искать настройки.

$ nano ~/.profile
Этот файл мы уже видели. Сразу после добавленной ранее строчки напишите

Цитировать
export OPENSSL_CONF=${HOME}/ca.conf
export TMPDIR=${HOME}/tmp

и сохраните файл (Ctrl+O, Ctrl+X)
Переменная OPENSSL_CONF указывает на файл с настройками openssl, мы её выставили раньше вручную, так что перезаходить на сервер сейчас нет нужды.
Переменная TMPDIR используется для поиска места, в котором должны создаваться временные файлы (например, командой mktemp).

$Id: SSL-CA-HOW-TO-3-Configuration.txt 315 2015-09-18 09:45:01Z anrdaemon $


4. Создание конфигурации центра сертификации.

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

$ nano $OPENSSL_CONF
и скопируйте в него этот текст:

--- BEGIN ca.conf ---
(Нажмите, чтобы показать/скрыть)
--- END ca.conf ---

Хотя и кажется, что тут уж больно много всего наворочено, на самом деле реальных настроек очень немного.
А после x509_base 5 секций просто ссылаются друг на друга в большинстве настроек, копируя параметры.
Основные секции, которые вы будете настраивать - это org1 и org1_dn. И то, там мало что можно настроить - основные параметры будут вводиться пользователем либо браться из сертификата/запросов.

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

$ openssl req -newkey rsa:4096 -x509 -extensions x509_ca -keyout ~/ca.key -out ~/store/ca-$(date +%Y%m%d-%H%M).crt -days 3654
Generating a 4096 bit RSA private key
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
............................++
................................................................................
................................................................................
...............................++
writing new private key to '/home/.CA/ca.key'
Enter PEM pass phrase: <myveryownca>
Verifying - Enter PEM pass phrase: <myveryownca>
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code, mandatory) [RU]:
State or province name (optional) []:Russian Federation
Locality Name (eg, city, mandatory) [Moscow]:
Organization name (optional) []:Example org.
Organizational Unit Name (eg, section) []:MiniCA
Common Name (eg, YOUR name, or a server address) []:Example org. MiniCA root authority
Email Address []:ca@example.org

Это было много-много точечек, да...
Поясню, что именно мы сделали - это поможет ориентироваться в дальнейших
командах.

openssl req - вызывается функция создания запроса сертификата
-newkey rsa:4096 - запрашивается генерация нового ключа RSA с длиной 4096 бит.
-x509 - а вот тут мы переключаемся в режим самоподписания сертификатов.
  Вместо закрытого ключа и запроса сертификата будет создан ключ и сертификат, подписанный этим ключом.
  (Сертификат ключа, подписанный этим же самым ключом, называется "самоподписанным" ("self-signed" certificate).)
-extensions x509_ca - из файла настроек загружаются расширения X.509 для CA
-keyout ~/ca.key - файл, куда сохранять ключ.
-out ~/store/ca-$(date +%Y%m%d-%H%M).crt
  - файл, куда сохранять подписанный сертификат. Файл создается с именем, включающим текущие дату и время - для большей наглядности.
-days 3654 - сертификат будет действителен примерно 10 лет, начиная от момента подписания.
  (В 10 годах не 3650 дней. Возьмите календарь, сами посчитайте.)

Но, как вы догадываетесь, оперировать столь длинным именем файла сертификата неудобно.
А мы и не будем мучиться - мы сделаем символическую ссылку...

$ ln -fs /home/.CA/store/ca-20120611-2310.crt ~/ca.crt
(Подсказка - введите "ln -s ~/store/ca-" и нажмите Tab - сохраните себе немного нервов...)

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

$ openssl req -new -reqexts x509_client_req -keyout ~/store/keys/client.key -out ~/store/client.csr
Generating a 1024 bit RSA private key
.....................................++++++
...................++++++
writing new private key to '/home/.CA/store/keys/client.key'
Enter PEM pass phrase: <1234>
Verifying - Enter PEM pass phrase: <1234>
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code, mandatory) [RU]:
State or province name (optional) []:Russian Federation
Locality Name (eg, city, mandatory) [Moscow]:Moscow
Organization name (optional) []:Example org.
Organizational Unit Name (eg, section) []:MiniCA
Common Name (eg, YOUR name, or a server address) []:Andrey Repin
Email Address []:anrdaemon@example.org
$

Что тут делается?

openssl req - вызывается функция создания запроса сертификата
-new - запрашивается генерация нового ключа с параметрами по умолчанию
-reqexts x509_client_req - выбираются X.509 расширения запроса, подходящие для клиентского сертификата
-keyout ~/store/keys/client.key -out ~/store/client.csr
  - сохраняются результаты работы программы - ключ и файл-запрос.

Теперь подпишем наш запрос, создавая сертификат.

$ openssl ca -extensions x509_client -in ~/store/client.csr -out ~/store/client.crt
Using configuration from /home/.CA/ca.conf
Enter pass phrase for /home/.CA/ca.key: <myveryownca>
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'RU'
localityName          :PRINTABLE:'Moscow'
commonName            :PRINTABLE:'Andrey Repin'
Certificate is to be certified until Jun 12 21:05:58 2013 GMT (366 days)
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
$

openssl ca - вызываем функции центра сертификации (CA - Certificate Authority)
-extensions x509_client - загружаем расширения X.509 для клиентских сертификатов
-in ~/store/client.csr -out ~/store/client.crt
  - читаем запрос и сохраняем сертификат.

Теперь бы как-то этот сертификат передать клиенту, запросившему его... Да желательно не один сертификат, а и ключ от него, да и сертификат центра тоже бы не помешал... Это как минимум три файла, что нам теперь, как с букетом с ними бегать?
К счастью, в OpenSSL предусмотрена возможность экспорта всех необходимых данных в контейнер формата PKCS#12 (формат обмена персональными данными). За это отвечает команда pkcs12 утилиты openssl.

$ openssl pkcs12 -export -chain -CAfile ~/ca.crt -in ~/store/client.crt -inkey ~/store/keys/client.key -name "Client Certificate" -out ~/store/client.pfx
Enter pass phrase for /home/.CA/store/keys/client.key: <1234>
Enter Export Password: <1234>
Verifying - Enter Export Password: <1234>
$

openssl pkcs12 - вызываются функции PKCS#12
-export - запрашивается экспорт сертификатов (иначе - импорт из контейнера PKCS#12)
-chain - включать в вывод полную цепочку сертификатов
-CAfile ca.crt - указывается файл, содержащий цепочку сертификатов, от младшего к старшему.
-in ~/store/client.crt -inkey ~/store/keys/client.key
  - добавляются сертификат и ключ
-name "Client Certificate"
  - устанавливается так называемое "дружественное имя" сертификата в контейнере. Желательно всё таки делать его более дружественным, чем я тут указал, либо вообще не задавать этот ключ.
-out ~/store/client.pfx
  - указывается путь к контейнеру для экспорта.

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



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

$Id: SSL-CA-HOW-TO-4-Creation.txt 315 2015-09-18 09:45:01Z anrdaemon $

--- продолжение ниже ---

На создание статьи подвигла тема https://forum.ubuntu.ru/index.php?topic=78433.0 и форс-мажор на собственном сервере.
Статья неокончена. Ожидают добавления: сертификаты серверов, настройка SSL веб-сервера, ограничение доступа к серверу с использованием сертификатов, вебмордочка для выдачи сертификатов.
« Последнее редактирование: 04 Ноября 2015, 03:14:09 от AnrDaemon »
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
5. Формирование списков отзыва сертификатов.

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

А со стороны мы увидим такую замечательную картину: вся система сертификации построена прежде всего на практически безгранично наследуемом доверии.
Устанавливая в систему корневой сертификат какого-нибудь центра сертификации (ЦС), вы своими руками говорите системе - "я(ты!) доверяю владельцу этого сертификата, и считаю заслуживающими доверия все сертификаты, им выданные."
(А теперь, на минутку: в вашей системе уже установлено около сотни CA сертификатов без вашего на то согласия. Которым система безоговорочно доверяет.)

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

$ openssl ca -revoke "store/somecert.crt"
Using configuration from /home/.CA/ca.conf
Enter pass phrase for /home/.CA/ca.key: <myveryownca>
Revoking Certificate ###.
Data Base Updated
$

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

$ openssl ca -gencrl -out "ca.crl"
Using configuration from /home/.CA/ca.conf
Enter pass phrase for /home/.CA/ca.key: <myveryownca>
$

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

authorityInfoAccess = caIssuers;URI:https://${MCA_WEBSITE}/ca.cer
crlDistributionPoints = URI:https://${MCA_WEBSITE}/ca.crl

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

$Id: SSL-CA-HOW-TO-5-Revocation.txt 317 2015-09-18 11:44:06Z anrdaemon $

6. Настройка и защита SSL/TLS (HTTPS) веб-сервера на примере Apache 2.2

Защищённое соединение с веб-сервером может быть использовано для многих целей.
Подтверждение аутентичности сервера. Защита канала связи с сервером от прослушивания. Ограничение доступа только для определённых клиентов.
Если вы обратили внимание, при настройке нашего CA центра мы уже указали один адрес: сайт https://ca.example.org/ был указан как место постоянного размещения сертификатов центра и списков отзыва сертификатов.
Для работы с этими двумя файлами нам будет достаточно простого подтверждения аутентичности сервера. Для этого мы создадим сертификат сервера и настроим Apache web server на создание защищённого соединения с использованием этого сертификата.

6.1 Создание сертификата для сервера.
Вот тут у нас есть как минимум одна проблема, о которой немногие знают, и ещё меньше людей задумывается.
Чтобы понять, откуда у проблемы растут ноги, надо понять две, казалось бы, не связанные вещи.
а) Адрес http://www.example.org/ и адрес http://example.org/ указывают на ДВА РАЗНЫХ САЙТА. Даже если у них одинаковое содержимое, что часто встречается в реальном интернете, с точки зрения протокола - это разные сайты.
б) Обычное HTTPS соединение (обмен сертификатами) между клиентом и сервером устанавливается до того, как клиент получает возможность сообщить серверу, на какой адрес он желает попасть.
Из этих, казалось бы, несвязанных вещей проистекает один неочевидный вывод: нет простого способа создать несколько виртуальных хостов, использующих HTTPS, на одном адресе. Причём проблема тут не одна, а сразу несколько, проистекающих из разных точек зрения на общую ситуацию.
Проблема 1. При обмене сертификатами, сервер понятия не имеет, на какой сайт хочет попасть клиент. Т.е. он не знает, сертификат какого сайта предъявить, чтобы клиент не прервал сессию до того, как соединение окончательно установлено.
Проблема 2. Сервер до окончания обмена сертификатами не знает, на какой сайт хочет попасть клиент, и можно ли вообще его пускать туда, а если нет, то куда.
Это основные проблемы, но пока хватит и их.
Проблема №2 не решается без использования современных серверов, клиентов и расширений протоколов, таких, как SNI.
Но проблему №1 вполне возможно решить, используя только инструменты управления сертификатами. Для указания интернет-хостов, для которых выдан конкретный сертификат, последние рекомендации предлагают использовать поле сертификата subjectAltName (альтернативные имена субъекта) и форму записи DNS:<hostname>.
Поскольку для альтернативного имени субъекта допускается указание множества значений, мы можем выдать сертификат, допускающий использование на нескольких сайтах сразу.
Если вы внимательно читали комментарии к конфигурационному файлу CA центра, задать значение поля subjectAltName через параметры командной строки openssl, к сожалению, нельзя. Но можно выкрутиться из этого неприятного положения, использовав особенность openssl, возникающую при чтении конфигурационного файла. Вполне возможно указать в конфигурационном файле ссылку на переменную окружения, которая будет прочитана как значение параметра настройки.
Пользоваться такой возможностью надо исключительно осторожно, чтобы не создать предпосылок для генерации сертификатов, разрешающих всё подряд кому ни попадя.

Вручную мы создаём сертификат для сайта ca.example.org вот таким образом:

$ SSLSAN='email:copy,DNS:ca.example.org' openssl req -new -nodes -reqexts x509_server_req -keyout ~/store/keys/server.key -out ~/store/server.csr
Generating a 1024 bit RSA private key
................................................................................
..++++++
.....++++++
writing new private key to '/home/.CA/store/keys/server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code, mandatory) [RU]:
State or province name (optional) []:Russian Federation
Locality Name (eg, city, mandatory) [Moscow]:
Organization name (optional) []:Example org.
Organizational Unit Name (eg, section) []:MiniCA
Common Name (eg, YOUR name, or a server address) []:MiniCA example web server
Email Address (mandatory) []:server@example.org
$

Как обычно, короткая расшифровка. бОльшую часть этого мы уже видели ранее, когда создавали сертификат клиента. Но кое-что всё-таки надо пояснить.

SSLSAN='email:copy,DNS:ca.example.org'
 - здесь создаётся временная переменная окружения с именем SSLSAN, содержащая как стандартное значение 'email:copy', указывающее, что надо скопировать e-mail адрес субъекта из emailAddress в subjectAltName, так и новое значение 'DNS:ca.example.org', таким образом объявляя, что не только письма с адреса, указанного как emailAddress, но и интерактивные сервисы, располагающиеся на адресе, которому соответствует доменное имя 'ca.example.org', могут быть подписаны ключём, соответствующим этому сертификату.
-nodes - закрытый ключ сохраняется БЕЗ ШИФРОВАНИЯ. Это необходимо для работы веб-сервера в автономном режиме. В противном случае при каждом старте веб-сервера будет запрашиваться пароль ключа. Иногда это полезно, но чаще считается излишним.
-reqexts x509_server_req
  - запрашиваются расширения X.509, характерные для веб-сервера.

Здесь надо сделать важное отступление. Во времена давние, теперь почти былинные, рекомендовалось вписывать адрес сервера в поле Common Name (CN).
В соответствии с современными рекомендациями, такая практика считается неудачной, если не предосудительной.
Неудачные и предосудительные практики необходимо изживать. Сервера и клиенты, неспособные прочесть имена сервера из subjectAltName, идут лесом.

Подпишем наш запрос.

$ openssl ca -extensions x509_server -in ~/store/server.csr -out ~/store/server.crt
Using configuration from /home/.CA/ca.conf
Enter pass phrase for /home/.CA/ca.key: <myveryownca>
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'RU'
localityName          :PRINTABLE:'Moscow'
commonName            :PRINTABLE:'MiniCA example web server'
Certificate is to be certified until Jun 21 19:34:23 2013 GMT (366 days)
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
$

Здесь всё то же самое, что и с клиентским сертификатом, с поправкой на сервер.

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

$ openssl pkcs12 -export -chain -CAfile ~/ca.crt -in ~/store/server.crt -inkey ~/store/keys/server.key -out ~/store/server.pfx
Enter Export Password: <1234>
Verifying - Enter Export Password: <1234>
$

Как видите, и здесь всё то же самое, что мы делали для клиента.
Поскольку ключ у нас не зашифрован, пароль для ключа у нас не спросили.

6.2 Настройка веб-сервера Apache
Если система у вас достаточно новая, то в поставке уже должен быть файл хоста default-ssl - достаточно его подправить и включить.
Но сразу он, вероятно, не заработает. Потому что модуль SSL не включён. :)

6.2.1 Создание окружения веб-сервера
Под именем CA-администратора, создайте каталоги:

$ mkdir --parent ~/htdocs ~/logs ~/ssl
Исправьте права доступа и смените группу-владельца каталогов веб-сервера. Проверьте результаты операции.

$ chgrp www-data ~/htdocs ~/logs
$ chmod g=rsX,o= ~/htdocs
$ chmod g=rwsX,o= ~/logs
$ chgrp ssl-cert ~/ssl
$ chmod g=x,o= ~/ssl
$ ls -ld ~/ ~/htdocs ~/logs ~/ssl
drwx--x--x 8 minica users    4096 2012-06-21 01:44 /home/.CA/
drwxr-s--- 5 minica www-data 4096 2012-06-21 01:44 /home/.CA/htdocs
drwxrws--- 5 minica www-data 4096 2012-06-21 01:44 /home/.CA/logs
drwx--x--- 5 minica ssl-cert 4096 2012-06-21 01:44 /home/.CA/ssl
$

Теперь надо установить сертификаты. Для этого воспользуемся всё той же командой pkcs12 утилиты openssl.

$ openssl pkcs12 -in ~/store/server.pfx -out ~/ssl/server.pem -nokeys
Enter Import Password: <1234>
MAC verified OK
$ openssl pkcs12 -in ~/store/server.pfx -out ~/ssl/server.key -nocerts -nodes
Enter Import Password: <1234>
MAC verified OK
$ ls -lA ~/ssl/
total 12
-rw-r----- 1 minica users 1011 2012-06-21 02:13 server.key
-rw-r----- 1 minica users 5067 2012-06-21 02:13 server.pem
$

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

$ chgrp ssl-cert ~/ssl/*
$ ls -lA ~/ssl/
total 12
-rw-r----- 1 minica ssl-cert 1011 2012-06-21 02:13 server.key
-rw-r----- 1 minica ssl-cert 5067 2012-06-21 02:13 server.pem
$

Да, не www-data, как кто-то может предположить. В группу ssl-cert входят пользователи, которым нужен доступ к ключам системы. Кстати, о пользователях...
Пользователь www-data в эту группу почему-то не входит. Что несколько... как бы это помягче сказать... туповато-с. Поправим это чуть позже.

Создадим заглушку для домашней странички сайта.

$ nano ~/htdocs/index.html
-- BEGIN index.html ---
(Нажмите, чтобы показать/скрыть)
-- END index.html ---

На этом подготовка взлётно-посадочной площадки закончена, пора готовить летальный аппарат.

6.2.2 (До)настройка SSL-хоста
Зайдите в систему под именем администратора и перейдите в рутовую консоль.

$ sudo -E -s
#

Первым делом, нам необходимо проверить доступность файлов и каталогов будущего сайта для веб-сервера. Самый простой способ сделать это - прикинуться шла... простите, веб-сервером. А точнее, пользователем, от имени которого сервер запущен.
Но сначала поправим самого пользователя. Как уже было сказано раньше, пользователь www-data не добавлен в группу ssl-cert.

# usermod -aG ssl-cert www-data
# sudo -u www-data -s
$ head -4 /home/.CA/ssl/server.key
Bag Attributes
    localKeyID: 49 2A F0 F9 C2 D8 E2 5E 11 14 50 D1 83 45 75 74 95 FB 02 4C
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
$ head -4 /home/.CA/ssl/server.pem
Bag Attributes
    localKeyID: 49 2A F0 F9 C2 D8 E2 5E 11 14 50 D1 83 45 75 74 95 FB 02 4C
subject=/C=RU/ST=Russian Federation/L=Moscow/CN=MiniCA example web server
issuer=/C=RU/ST=Russian Federation/L=Moscow/O=Example org./OU=MiniCA/CN=Example org. MiniCA root authority/emailAddress=ca@example.org
$ head -4 /home/.CA/htdocs/index.html
<html>
<head>
<title>example.org CA center</title>
</head>
$ exit
#

Если на какую-то команду вы получите в ответ ошибки, значит, либо вы неправильно указываете пути к файлам, либо необходимо исправить права доступа. Вернитесь к предыдущему шагу и всё внимательно проверьте.

Откройте файлик SSL-хоста на редактирование.

# nano /etc/apache2/sites-available/default-ssl
По умолчанию, этот файл выглядит как-то так.
Необходимо внести сюда несколько изменений.
Во-первых, исправьте строчку "ServerAdmin webmaster@localhost", чтобы она гласила

 
Цитировать
ServerAdmin server@example.org

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

Сразу после этой строки, добавьте имя нашего сайта

 
Цитировать
ServerName ca.example.org

Исправьте расположение файлов вашего сайта на диске

 
Цитировать
DocumentRoot /home/.CA/htdocs

Уберите все блоки <Directory></Directory> к чёртовой матери. Помимо того, что эти блоки дают доступ непонятно кому неясно куда, использовать <Directory> для описания веб-сайта в 21-м веке как минимум глупо. Структура любого мало-мальски приличного сайта давно уже не имеет прямого отображения на файловой системе.
Создайте один блок Directory и блок Location:

Цитировать
  <Directory />
    AllowOverride None
  </Directory>
  <Location />
    Options -Indexes
  </Location>

Уберите строку "ScriptAlias ..."
Исправьте строку "ErrorLog ${APACHE_LOG_DIR}/error.log" до

 
Цитировать
ErrorLog /home/.CA/logs/error.log

Исправьте строку "CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined" до

 
Цитировать
CustomLog /home/.CA/logs/access.log combined

Удалите строку "Alias /doc/ ..."
Исправьте строки SSLCertificateFile и SSLCertificateKeyFile до

Цитировать
  SSLCertificateFile    /home/.CA/ssl/server.pem
  SSLCertificateKeyFile /home/.CA/ssl/server.key

Раскомментируйте и исправьте строку SSLCertificateChainFile до

 
Цитировать
SSLCertificateChainFile /home/.CA/ssl/server.pem

Есть смысл поправить строки SSLCACertificateFile и SSLCARevocationFile до

Цитировать
  #SSLCACertificateFile /home/.CA/ssl/ca.pem
  #SSLCARevocationFile /home/.CA/ssl/ca.crl

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

--- BEGIN default-ssl ---
(Нажмите, чтобы показать/скрыть)
--- END default-ssl ---

Сохраните файл (Ctrl+O/Ctrl+X)
Проверьте файл /etc/apache2/ports.conf - в нём должен быть блок

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Если по каким-то причинам его там нет - добавьте.
Теперь самое время включить сайт. Но, как говорилось выше, нам так же понадобится и сам модуль SSL, так что включаем и его тоже.

# a2enmod ssl
Module ssl installed; run /etc/init.d/apache2 force-reload to enable.
# a2ensite default-ssl
Site default-ssl installed; run /etc/init.d/apache2 reload to enable.
#

Для проверки синтаксиса конфигурации, запустите

# apache2ctl -MS
вам нужны строки, относящиеся к настраиваемым нами компонентам:

Цитировать
*:443                  is a NameVirtualHost
         default server ca.example.org (/etc/apache2/sites-enabled/default-ssl:2)
         port 443 namevhost ca.example.org (/etc/apache2/sites-enabled/default-ssl:2)

...
 ssl_module (shared)
...
Syntax OK

Если они есть и выглядят похоже на правду, можно попробовать перезапустить
сервер.

# service apache2 restart
 * Restarting web server apache2
   ...done.
#

Добавьте связь "адрес-имя" для ca.example.org в свой DNS сервер либо в локальный файл hosts вашего рабочего компьютера, если ещё не сделали этого.
(Для файла hosts запись будет вида "192.168.56.5 ca.example.org")
Теперь можно открыть ваш любимый браузер и попробовать перейти на сайт

https://ca.example.org/
Если вы делали инструкцию последовательно, не пропуская шагов, сайт должен открыться сразу (разве что вы используете Firefox или Opera, тогда вам придётся вручную устанавливать сертификаты, поскольку эти чудеса инженерной мысли не используют встроенную библиотеку сертификации системы - дикари-с.)
Если же корневой сертификат вашего центра в системе не установлен, то единственное, о чём должен предупреждать вас браузер, это о том, что сертификат сайта не имеет подписи доверенного центра сертификации.
Не должно быть сообщений о том, что сертификат выдан на другое имя сайта, либо что срок действия сертификата истёк или не наступил.
(Хотя с последним сообщением мне пришлось столкнуться самому, т.к. по необъяснимой причине время на сервере и на десктопе отличалось более чем на 12 минут.)

Всё... Если вы видите замочек напротив адреса сайта и текст "This is example.org CA website." в окошке браузера, ваш SSL-сайт работает.

$Id: SSL-CA-HOW-TO-6-Securing-web-server.txt 315 2015-09-18 09:45:01Z anrdaemon $
« Последнее редактирование: 19 Сентября 2015, 18:08:39 от AnrDaemon »
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
7. PEM vs. DER. Публикация данных ЦС.

Если вы ещё не забыли, я раньше упоминал о том, что формат файлов сертификата и списка отзыва не годится для публикации в Интернет. Всё дело в кодировке.
По умолчанию, OpenSSL создаёт (почти) все файлы в кодировке PEM - "Privacy-Enhanced Mail". Но стандарт публикации требует, чтобы файлы были в кодировке DER - "Distinguished Encoding Rules".
На самом деле это не проблема, ибо формат PEM является base64-кодированной версией формата DER (плюс некоторые дополнительные заголовки) и OpenSSL вполне способен конвертировать данные между этими двумя форматами.
Поскольку DER-кодированные файлы нужны нам только для рапространения через веб-сервер, сделаем сразу перекодирование и публикацию.

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

Приступим.

$ mktemp --tmpdir="$HOME/htdocs"
/home/.CA/htdocs/tmp.E0SefOIDL5
$ openssl x509 -in ~/ca.crt -out /home/.CA/htdocs/tmp.E0SefOIDL5 -outform DER
$ mv /home/.CA/htdocs/tmp.E0SefOIDL5 ~/htdocs/ca.cer

$ mktemp --tmpdir="$HOME/htdocs"
/home/.CA/htdocs/tmp.A3dIcLah3n
$ openssl crl -in ~/ca.crl -out /home/.CA/htdocs/tmp.A3dIcLah3n -outform DER
$ mv /home/.CA/htdocs/tmp.A3dIcLah3n ~/htdocs/ca.crl

$ ls -l ~/htdocs/
total 12
-rw-r----- 1 minica www-data 1889 Sep 15 15:50 ca.cer
-rw-r----- 1 minica www-data 1116 Sep 16 21:58 ca.crl
-rw-r----- 1 minica www-data  135 Sep 16 22:00 index.html
$

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

Проверьте, что оба файла доступны через веб - зайдите на https://ca.example.org/ и попробуйте скачать файлы по обеим ссылкам.

$Id: SSL-CA-HOW-TO-7-Present-yourself.txt 320 2015-09-18 14:38:22Z anrdaemon $


8. Фейс-контроль. Ограничение доступа по клиентскому сертификату.

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

Итак, задача: Дан сайт http://www.example.org/ с админкой. Администраирование ограничено привязкой к IP адресу клиента.
Необходимо: Обеспечить администраторам безопасный, контролируемый доступ с любых адресов, при этом сам форум трогать не представляется возможным.
Описание решения: Необходимо настроить на этом же сервере второй сайт, который будет работать через HTTPS и служить обратным прокси для первого. Авторизация клиентов будет обеспечиваться через сертификаты. Без дополнительной настройки, первый сайт будет видеть клиентов, приходящих через обратный прокси, как клиентов с локальным IP прокси, что решает задачу ограничения администрирования через постоянный IP адрес.

8.1. Создание и установка сертификата для обратного прокси.

От имени администратора ЦС:

$ SSLSAN='email:copy,DNS:test.example.org,DNS:www.example.org' openssl req -new -nodes -reqexts x509_server_req -keyout ~/store/keys/server2.key -out ~/store/server2.csr
Generating a 2048 bit RSA private key
....+++
....+++
writing new private key to '/home/.CA/store/keys/server2.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code, mandatory) [RU]:
State or province name (optional) []:Russian Federation
Locality Name (eg, city, mandatory) [Moscow]:
Organization name (optional) [Example org.]:
Organizational Unit Name (eg, section) [MiniCA]:
Common Name (eg, YOUR name, or a server address) []:Administration proxy server
Email Address (mandatory) []:server@example.org
$ openssl ca -extensions x509_server -in ~/store/server2.csr -out ~/store/server2.crt
Using configuration from /home/.CA/ca.conf
Enter pass phrase for /home/.CA/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'RU'
stateOrProvinceName   :PRINTABLE:'Russian Federation'
localityName          :PRINTABLE:'Moscow'
organizationName      :PRINTABLE:'Example org.'
organizationalUnitName:PRINTABLE:'MiniCA'
commonName            :PRINTABLE:'Administration proxy server'
Certificate is to be certified until Sep 19 16:06:45 2016 GMT (366 days)
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
$ cp ~/store/keys/server2.key ~/ssl/server2.key
$ cp ~/store/server2.crt ~/ssl/server2.pem
$ cat ~/ca.crt >> ~/ssl/server2.pem
$ cp ~/ca.crt ~/ssl/ca.pem
$ cp ~/ca.crl ~/ssl/ca.crl
$ chmod g=r ~/ssl/*
$ chgrp ssl-cert ~/ssl/*
minica@xca-https:~$ ls -l ssl
total 36
-rw-r----- 1 minica ssl-cert 1535 Sep 19 19:26 ca.crl
-rw-r----- 1 minica ssl-cert 2614 Sep 19 19:26 ca.pem
-rw-r----- 1 minica ssl-cert 1708 Sep 19 19:26 server2.key
-rw-r----- 1 minica ssl-cert 9863 Sep 19 19:25 server2.pem
-rw-r----- 1 minica ssl-cert 1704 Sep 19 19:43 server.key
-rw-r----- 1 minica ssl-cert 7112 Sep 19 19:41 server.pem
$

На этот раз нам нужен не только сертификат для сервера, но и отдельно сертификат ЦС и списки отзыва. Причём в оригинальной PEM кодировке.
Сертификат создаём для двух доменных имён, с расчётом на использование в тестовом режиме перед вводом в эксплуатацию.

8.2. Настройка прокси.

От рута:

# nano /etc/apache2/ports.conf
В блоке <IfModule mod_ssl.c> добавьте строчку:

 
Цитировать
NameVirtualHost *:443

(Не обращайте внимания на бред, написанный в комментарии блока мейнтейнерами Дэбиан, ничего в default-ssl править не надо, наоборот, подобной правкой вы сломаете нормальную работу Апача!)

# cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/rproxy
# nano /etc/apache2/sites-available/rproxy

Исправьте строку <VirtualHost ...> до

Цитировать
<VirtualHost *:443>

Исправьте строку ServerName до

 
Цитировать
ServerName test.example.org

Удалите строку DocumentRoot.
Блок <Location> измените до

Цитировать
  <Location />
    Options -Indexes
    ProxyPass "http://www.example.org/"
  </Location>

Да, вот оно - ключевое слово!
Впрочем, продолжим.
Измените параметры логирования:

Цитировать
ErrorLog /home/.CA/logs/rproxy.error.log
CustomLog /home/.CA/logs/rproxy.access.log combined

Измените пути к сертификатам и ключам сайта:

Цитировать
SSLCertificateFile    /home/.CA/ssl/server2.pem
SSLCertificateKeyFile /home/.CA/ssl/server2.key
SSLCertificateChainFile /home/.CA/ssl/server2.pem

Проверьте, не забыли ли вы чего, не осталось ли неучтённых строчек.
Сохраните файл. (Ctrl+O,Ctrl+X)

Включите модуль проксирования и собственно хост, перезагрузите веб-сервер.

# a2enmod proxy proxy_http
# a2ensite rproxy
# service apche2 restart

Проверьте работу проксирования, зайдя на сайт https://test.example.org/. Естественно, DNS должен быть настроен соответствующим образом.

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

Снова откройте на редактирование файл виртуального хоста:

# nano /etc/apache2/sites-available/rproxy
Раскомментирйте (и измените, если ещё не) строки:

Цитировать
SSLCACertificateFile /home/.CA/ssl/ca.pem
SSLCARevocationFile /home/.CA/ssl/ca.crl
SSLVerifyClient require
SSLVerifyDepth  10

"SSLCACertificateFile" устанавливает сертификат ЦС, которому сайт будет доверять выдачу клиентских сертификатов. Это может быть любой ЦС, не обязательно тот же, что выдал сервтификат серверу.
"SSLCARevocationFile" указывает на список отзыва сертификатов. Список перечитывается нечасто, поэтому при установке нового списка веб-сервер лучше сразу перезагрузить. Либо использовать OCSP сервер поставщика сертификатов. Но это тема для другого раза.
"SSLVerifyClient require" указывает, что от клиента требуется предъявление сертификата для доступа к сайту. "Нет бумажки - нет печеньки!"
"SSLVerifyDepth  10" для нас величина некритичная, эта настройка указывает, сколько (максимум) вышестоящих сертификатов клиента проверять, прежде чем сдаться и отказать в доступе.

Результат должен быть примерно таким:

--- BEGIN rproxy ---
(Нажмите, чтобы показать/скрыть)
--- END rproxy ---

Сохраните настройки и перезагрузите веб-сервер. Теперь при входе на сайт https://test.example.org/ вас попросят предъявить сертификат, если вы уже устанавливали его раньше (см. часть 4. Создание ЦС). Если клиентский сертификат у вас не установлен, вы получите ошибку установления защищённого соединения.

В работе разрешающего и блокирующего механизмов мы убедились, давайте посмотрим, как работает запрещающий механизм.

Создайте новый клиентский сертификат для пользователя "Revoked User", упакуйте его в контейнер, перенесите себе на машину, установите в браузер и убедитесь, что вас пускает на сайт по этому сертификату.

После этого отзовите сертификат, обновите и установите списки отзыва. Не забудьте перезагрузить веб-сервер.
Теперь при входе на сайт с использованием сертификата "Revoked User" у вас должна выходить ошибка соединения. При этом вход с использованием вашего первого сертификата должен проходить без проблем.

Если всё работает по описанию, значит, ваша система готова к эксплуатации. Проверьте, под каким IP адресом ваш прокси виден на вашем основном сайте, поправьте права доступа в админку и пользуйтесь!

$Id: SSL-CA-HOW-TO-8-Face-control.txt 328 2015-09-19 20:54:25Z anrdaemon $


A. Важные замечания.

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

Каталог ключа системы:
-rw---x--- root:ssl-cert /etc/ssl/privateКлюч системы:
-rw-r----- root:ssl-cert /etc/ssl/private/hostname.keyСертификат системы:
-rw-r--r-- root:root /etc/ssl/hostname.crtСертификат ЦС:
-rw-r--r-- root:root /etc/ssl/certs/CA-name.crt
Каталог /etc/ssl/certs ДОЛЖЕН БЫТЬ проиндексирован утилитой c_rehash.

# c_rehash /etc/ssl/certs
Запихивать сертификаты ЦС в сертификат сервера нет необходимости (если только приложение, использующее сертификаты, не совершенно тупое, но в этом случае придётся пихать оба сертификата в ключ). Обычно можно указать все три части по отдельности. Ключ, сертификат собственно хоста и цепочку сертификатов ЦС, от младшего к старшему.

2. Об ограничении доступа.
Сертификат ЦС, используемый для авторизации клиентов, должен лежать отдельно от цепочки собственных сертификатов! Даже если это один и тот же сертификат.

3. О резервном копировании.
Не включайте в копию ключи системы, если они хранятся без защиты паролем.
Сохраните защищённый паролем PKCS#12 и бэкапьте его.

4. IE и HTTPS.
IE <= 8 не поддерживает SNI. Для нормальной работы в Internet под Windows XP используйте более другие браузеры.
IE в Windws 7 и выше не поддерживает одновременное использование SSLv2 и TLSv1.2 при работе с клиентскими сертификатами. Для нормальной работы HTTPS SSLv2 необходимо отключить. Ref: http://support.microsoft.com/kb/2851628

$Id: SSL-CA-HOW-TO-A-Necessary-notes.txt 329 2015-09-19 21:27:50Z anrdaemon $



Большая просьба, если у кого-то есть минимальный интерес, проделайте всё это сами и отпишите, пожалуйста, ваши ощущения, вопросы, замечания.
Понимаю, что текста много, но писалось всё буквально на одном дыхании и делается это по сути тоже почти моментально.
Если будет достаточно отзывов, перенесу всё на вики.
« Последнее редактирование: 20 Сентября 2015, 00:39:31 от AnrDaemon »
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн Дмитрий Бо

  • Погонщик серверов
  • Модератор раздела
  • Старожил
  • *
  • Сообщений: 3549
  • Я не техподдержка, я за порядком слежу
    • Просмотр профиля
Я бы начал разбираться, но все глобальные криптозадачи выполняются возложены на другой отдел.

Мне это поможет подписать HTTPS в интрасети? и репозиторий в ней же?

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Мне это поможет подписать HTTPS в интрасети? и репозиторий в ней же?
HTTPS - да. Любое TLS соединение, если на то пошло - да. HTTPS, SMTPS, IMAPS, POP3S, etc. В случае с SMTPS/POP3S так же будет работать в случае использования StartTLS (по сути, там TLS соединение просто запускается в текущей сессии). Вероятно, это же верно для IMAPS.
Репозитарий (не важно чего) - если подписывание осуществляется через сертификаты, а не через PGP ключи (APT), да.

P.S.
https://ca.rootdir.org/
Как раз создан за время экспериментов.
Единственно, там, возможно, не отдаётся вся цепочка сертификатов в ответе сервера.
Если будет запрашивать клиентский сертификат - игнорируй, оно там стоит как опциональное требование.
Я пока экспериментирую с этими параметрами, для дописывания фака.
« Последнее редактирование: 25 Июня 2012, 21:27:38 от AnrDaemon »
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн censor

  • Старожил
  • *
  • Сообщений: 1126
    • Просмотр профиля
Спасибо. Добавил с закладки, в отпуске почитаю.

Оффлайн Karl500

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 2267
    • Просмотр профиля
Чтобы не пропало (а тут, кмк, пригодится).

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

Интереснее вопрос, что делать, когда истекает срок выдачи корневого сертификата. К счастью, здесь все достаточно просто.
Главное - иметь первоначальный закрытый ключ корневого сертификата (ни в коем случае не удаляйте его!)

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

Проверим:

1. Сгенерим корневой сертификат

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes
2. Сгенерим клиентский сертификат

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

3. Подпишем клиентский сертификат

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -set_serial 01 -out cert.pem
rm cert.csr

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

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

5. Предположим, что прошло 10 лет. Сгенерим новый сертификат CA с использованием старого закрытого ключа

openssl req -new -x509 -key root.key -out newroot.pem -days 3650 -nodes

6. Проверим валидность выданного ранее пользовательского ключа

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

Аналогично и с серверными сертификатами - они остаются валидными, если новый корневой сертификат создается с использованием старого закрытого ключа.

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Обновление сертификата CA - почти верно.
Правильное слово полностью:
openssl req -new -x509 -extensions x509_ca -key /home/.CA/ca.key -out /home/.CA/ca-$( date +%Y%m%d-%H%M ).crt -days 3653(В 10 годах не 3650 дней, а ~3652,5.)
« Последнее редактирование: 07 Июня 2013, 20:11:05 от AnrDaemon »
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

delovoy

  • Гость
Много полезного в теме, поэкспериментирую в выходные ;)

Оффлайн ArcFi

  • Старожил
  • *
  • Сообщений: 15189
    • Просмотр профиля
    • aetera.net
Я свой зоопарк в XCA держу.
Ключи, запросы, сертификаты, шаблоны.
Больше сотни объектов набирается.
Удобно связи и валидность мониторить.

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Я всё помню, но у меня возник конфликт между реальным и предполагаемым сценарием использования, и пока я не решу его, обновлений гайда не предвидится.
Извините...
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн gordei3000

  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
Создал самоподписанный корневой сертификат УЦ, создал закрытый ключ и запрос на сертификат для пользователя, подписал запрос и получил сертификат для пользователя описанным выше способом, всё упаковал в *.pfx

В MS WINDOWS не получается установить файл *.pfx - "Произошла внутренняя ошибка. Для импорта закрытого ключа требуется поставщик криптографии, который не установлен".
Хотя по отдельности сертификат УЦ и сертификат пользователя устанавливаются в нужные места спокойно.

Как же установить набор закрытый ключ + подписанный сертификат пользователя на его машину?

Каким софтом в дальнейшем можно подписывать файлы для их передачи?

Заранее благодарен за любые советы :)

Оффлайн ArcFi

  • Старожил
  • *
  • Сообщений: 15189
    • Просмотр профиля
    • aetera.net
всё упаковал в *.pfx
Что именно упаковали?
И каким способом?

Оффлайн AnrDaemon

  • Автор темы
  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
В MS WINDOWS не получается установить файл *.pfx - "Произошла внутренняя ошибка. Для импорта закрытого ключа требуется поставщик криптографии, который не установлен".
Хотя по отдельности сертификат УЦ и сертификат пользователя устанавливаются в нужные места спокойно.
Сертификаты не содержат закрытый ключ. Внимательнее читайте сообщение об ошибке (тем более написанное на русском языке).
И показывайте, как чего делаете, как вас уже попросили выше.

Цитировать
Каким софтом в дальнейшем можно подписывать файлы для их передачи?
Любым, работающим с системными функциями криптографии. На ваш выбор.
У меня купленный Crypto Pro CSP на работе стоит.

P.S.
Лучше всего будет создать новый топик для решения вашей проблемы.
И дайте ссылку на него здесь, чтобы мы его долго не искали.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн gordei3000

  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
упаковал 3 файла: ca.crt - сертификат УЦ, client1.crt - сертификат клиента, подписанный УЦ, client1.key - закрытый ключ клиента

openssl pkcs12 -export -chain -Cafile ca.crt -in client1.crt -inkey client1.key -out client1.pfx

далее файл client1.pfx скинул на комп с WinXP - попробовал установить - запустился мастер импорта сертификатов, а в конце вылезла ошибка

Ключи создавал по алгоритму gost2001 paramset:A

Пользователь решил продолжить мысль 18 Ноября 2013, 13:27:57:
перенесено в https://forum.ubuntu.ru/index.php?topic=233842.0
« Последнее редактирование: 18 Ноября 2013, 13:27:57 от gordei3000 »

 

Страница сгенерирована за 0.087 секунд. Запросов: 22.