В приведенном ниже примере используется версия OpenSSL для ОС Linux. В примере продемонстрированы шаги для создания трех сертификатов в формате PEM:
корневой сертификат - используется для подписи других сертификатов (ca.cer);
сертификат сервера - используется сервером для проверки сертификатов пользователей (server.cer);
сертификат клиента - предоставляется пользователем для проверки на сервере (client.cer).
Возможны два варианта конфигурации:
настольное приложение > драйвер WEB Service > HTTPS > Сервер безопасности (PP.SOM.SomSec) > СУБД;
браузер > HTTPS > веб-приложение на сервере Apache2 > HTTPS > BI-сервер (PP.SOM.Som) > драйвер WEB Service > HTTP > Сервер безопасности (PP.SOM.SomSec) > СУБД.
В конфигурации с BI-сервером предполагается соединение с сервером безопасности во внутренней сети без использования протокола HTTPS.
Примечание. При необходимости использовать обе конфигурации подключения одновременно, необходимо выпустить два серверных сертификата (для BI-сервера и для сервера безопасности), подписанные одним корневым сертификатом.
Для установки OpenSSL в Ubuntu/Debian/Astra Linux выполните команду:
sudo apt-get install openssl
Для установки OpenSSL в Red Hat Enterprise Linux выполните команду:
sudo yum install openssl
При создании сертификата генерируется закрытый ключ, который используется для расшифровки данных, зашифрованных открытой частью сертификата. В целях безопасности ключ должен сохраняться в тайне и не передаваться третьим лицам.
Предварительно потребуется создать файл openssl.cnf, содержащий вспомогательную информацию:
[ req ]
default_md = sha1
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
countryName = Country
countryName_default = RU
countryName_min = 2
countryName_max = 2
localityName = Locality
localityName_default = Russia
organizationName = Organization
organizationName_default = Foresight
commonName = Common Name
commonName_max = 64
[ certauth ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
crlDistributionPoints = @crl
[ server ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
nsCertType = server
crlDistributionPoints = @crl
[ client ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth
nsCertType = client
crlDistributionPoints = @crl
[ crl ]
URI=http://testca.local/ca.crl
Сертификаты в формате PEM можно при необходимости конвертировать в формат DER командой:
openssl x509 -outform der -in MyCertificate.pem -out MyCertificate.crt
Для создания корневого сертификата выполните команду:
openssl req -config ./openssl.cnf -newkey rsa:2048 -nodes -keyform PEM -keyout ca.key -x509 -days 3650 -extensions certauth -outform PEM -out ca.cer
При выполнении команды будут запрошены дополнительные данные: PEM пароль и пользовательские данные о владельце сертификата. При запросе «Common name» укажем название выпускаемого удостоверяющего центра, например «Test CA».
Сгенерируем ключ для серверного сертификата:
openssl genrsa -out server.key 2048
Создадим запрос на подпись серверного сертификата:
openssl req -config ./openssl.cnf -new -key server.key -out server.req
Выпустим серверный сертификат сроком действия 1 год:
openssl x509 -req -in server.req -CA ca.cer -CAkey ca.key -set_serial 100 -extfile openssl.cnf -extensions server -days 365 -outform PEM -out server.cer
При выполнении команды будет выдан запрос доменного имени сервера, для которого выпускается серверный сертификат. Укажем полное имя компьютера (команда hostname), если компьютер в доменной сети и к нему будут обращаться с указанием домена, то необходимо указать имя, включая домен, например «hostname.domain.ru».
Запрос на создание сертификата содержит закрытый ключ. После выпуска сертификата он более не требуется, в целях безопасности его рекомендуется удалить командой:
rm server.req
Сгенерируем ключ для клиентского сертификата:
openssl genrsa -out client.key 2048
При выполнении команды будет получен запрос PEM пароля и уточняющие вопросы. При запросе «Common name» укажем реальное имя пользователя, которому будет выдан сертификат.
Создадим запрос на выпуск клиентского сертификата:
openssl req -config ./openssl.cnf -new -key client.key -out client.req
Выпустим клиентский сертификат:
openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extfile openssl.cnf -extensions client -days 365 -outform PEM -out client.cer
Экспортируем сертификат и закрытый ключ в сертификат в формате PKCS#12 (PFX), который будет содержать одновременно сертификат и зашифрованный ключ.
openssl pkcs12 -export -inkey client.key -in client.cer -out client.pfx
При экспорте укажем пароль для закрытого ключа, он потребуется при импорте сертификата в хранилище.
Удалим клиентский сертификат в формате PEM, закрытый ключ и запрос на создание сертификата:
rm client.key client.cer client.req
В результате были созданы:
корневой сертификат - ca.cer;
сертификат сервера - server.cer;
сертификат клиента с зашифрованным ключом - client.pfx.
Сертификаты необходимо разместить следующим образом:
на сервере: корневой сертификат и серверный сертификат с ключом (ca.cer, server.cer и server.key);
на рабочем компьютере: клиентский сертификат с зашифрованным
ключом в формате *.pfx и корневой сертификат без ключа.
Клиентский сертификат устанавливается в личное хранилище пользователя,
корневой сертификат импортируется в хранилище
доверенных корневых центров сертификации локального компьютера.
Отредактируем файл PP.xml, находящийся в папке «config» веб-приложения, для настройки подключения к BI-серверу минуя прокси-обработчик. Добавим секцию <AppConfig> и параметр PPServiceUrl:
<?xml version="1.0" encoding="utf-8" ?>
<pp>
<service url="https://hostname.domain.ru/axis2/services/PP.SOM.Som" />
<AppConfig>
<Service PPServiceUrl="https://hostname.domain.ru/axis2/services/PP.SOM.Som"/>
</AppConfig>
</pp>
Для используемого репозитория зададим следующие настройки:
Включим встроенную авторизацию.
Создадим служебного пользователя p4audit.
Привяжем слепок сертификата к пользователю.
Добавим настройки подключения к серверу безопасности:
Драйвер: WEB Service;
Точка подключения: http://hostname-ss.domain.ru/axis2/services/PP.SOM.SomSec;
Идентификатор репозитория: идентификатор созданного на сервере безопасности репозитория.
Примечание. Настройки подключения задаются через реестр. Создайте необходимые настройки в настольном приложении и скопируйте их на BI-сервер.
Добавим репозиторий с настройками подключения к СУБД (через реестр). На рабочей станции сервера безопасности должны быть установлены клиентские программы необходимых СУБД.
Сохраним данные для авторизации в базе данных при помощи утилиты PP.Util:
./PP.Util /save_creds <metabase_id> <login> <password>
В конфигурационном файле settings.xml зададим параметр Strategy_check.
После выполнения всех шагов перезагрузим веб-приложение, сервер безопасности и BI-сервер.
Дальнейшие шаги зависят от используемой ОС:
Для проверки авторизации по HTTP перейдем по адресу: http://hostname.domain.com/fp9.2/app/login.html.
Для проверки двухфакторной авторизации по HTTPS перейдем по адресу: https://hostname.domain.com/fp9.2/app/login.html.
При открытии страницы будет выдан запрос клиентского сертификата. Выберем клиентский сертификат, связанный с используемой учетной записью.
См. также:
Настройка двухфакторной аутентификации | Пример настройки двухфакторной аутентификации в ОС Windows