Развёртывание и настройка oVirt 4.0. Часть 2. Замена сертификата веб-сервера oVirt Engine

imageПосле развёртывания oVirt Engine, при попытке подключения к веб-порталам oVirt мы каждый раз будем получать предупреждение системы безопасности веб-браузера о том, что веб-узел имеет сертификат, которому нет доверия. Это происходит из-за того, что на веб-узле oVirt используется сертификат выданный локальным Центром сертификации (ЦС), который был развёрнут в ходе установки oVirt Engine. Для того, чтобы избавиться от этих предупреждений, а также для того чтобы веб-браузер корректно работал со всеми функциями, доступными на веб-порталах oVirt, нам потребуется сделать так, чтобы веб-браузер доверял SSL сертификату веб-сервера oVirt. Решить этот вопрос можно двумя способами.

Первый и более простой способ – добавить корневой сертификат локального центра сертификации oVirt в хранилище доверенных коревых сертификатов на клиентском компьютере. Согласно документа Console Clients Resources для oVirt 4.0 получить этот корневой сертификат можно непосредственно через веб-браузер, обратившись по ссылке:

https://[your engine]/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

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

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

Забегая вперёд, можно сказать, что, в частности, нам нужно будет подменить 3 файла, ссылки на которые есть в конфигурации SSL веб-сервера Apache, на базе которого и работает веб-портал oVirt:

# cat /etc/httpd/conf.d/ssl.conf | grep /etc/pki/ovirt-engine/

SSLCertificateFile /etc/pki/ovirt-engine/certs/apache.cer
SSLCertificateKeyFile /etc/pki/ovirt-engine/keys/apache.key.nopass
SSLCACertificateFile /etc/pki/ovirt-engine/apache-ca.pem

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

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

  • файл корневого сертификата внутреннего ЦС в формате *.pem (my-corp-ca.pem);
  • файл сертификата веб-сервера oVirt (Apache) в формате *.pem, выданного внутренним ЦС (ovirt-apache.pem);
  • файл закрытого ключа от сертификата веб-сервера oVirt (ovirt-apache.key);
  • файл сертификата веб-сервера в паре с закрытым ключом и с сертификатом корневого ЦС в формате pkcs12 (ovirt-apache-bundle.p12)

Кстати, ранее мы уже рассматривали процедуру генерации и установки сертификата на веб-сервер Apache. Здесь процедура будет немного сложней.

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

# cat ovirt-apache.cnf

[ req ]
prompt = no
distinguished_name = req_distinguished_name 
[ req_distinguished_name ]
commonName = KOM-AD01-OVIRT1.holding.com
countryName = RU
0.organizationName = RoGa and Kopyta Ltd.
localityName = Syktyvkar
organizationalUnitName = Branch KOMI

Важно, чтобы атрибут commonName в конфигурационном файле соответствовал FQDN имени нашего сервера oVirt Engine.

Генерируем закрытый ключ и запрос к ЦС на основе этого ключа и ранее созданного конфигурационного файла:

# openssl genrsa -out ovirt-apache.key 2048
# openssl req -config ovirt-apache.cnf -new -key ovirt-apache.key -out ovirt-apache.req

Отправляем файл запроса ovirt-apache.req администратору корпоративного ЦС и получаем от него готовый сертификат для веб-сервера (ovirt-apache.cer) + корневой сертификат центра сертификации (my-corp-ca.cer). В моём случае локальный корпоративный ЦС работает на Windows Server CA, поэтому полученные из этого ЦС бинарные сертификаты в кодировке DER необходимо будет конвертировать в формат, понятный для Apache – PEM:

# openssl x509 -in ovirt-apache.cer -inform DER -out ovirt-apache.pem -outform PEM
# openssl x509 -in my-corp-ca.cer -inform d -out my-corp-ca.pem -outform PEM

После этого собираем сертификат/закрытый ключ сертификата и корневой сертификат в бандл формата P12:

# openssl pkcs12 -export -out ovirt-apache-bundle.p12 -inkey ovirt-apache.key -in ovirt-apache.pem -chain -CAfile my-corp-ca.pem

В процессе создания бандла задаём пароль, с помощью которого бандл будет зашифрован, — используем пароль «mypass«

В итоге у нас во временном каталоге ~/ovirt-certs/ получилось 4 файла ovirt-apache.key, ovirt-apache.pem, my-corp-ca.pem и ovirt-apache-bundle.p12. Теперь можно переходить к привязке полученных файлов к oVirt Engine.

***

Заменим файл сертификата веб-сервера oVirt используемый в конфигурации Apache (параметр SSLCACertificateFile в файле /etc/httpd/conf.d/ssl.conf), предварительно сделав копию используемого на данный момент файла.
Напомню, что файл apache-ca.pem в нашем случае содержит только сертификат веб-сервера:

# mv /etc/pki/ovirt-engine/apache-ca.pem /etc/pki/ovirt-engine/apache-ca.pem-BACK
# cp ~/ovirt-certs/ovirt-apache.pem /etc/pki/ovirt-engine/apache-ca.pem

До наших изменений файл /etc/pki/ovirt-engine/apache-ca.pem на самом деле не файл, а символическая ссылка на другой файл /etc/pki/ovirt-engine/ca.pem.
Ссылку мы удалять не будем, а, как я уже сказал, просто переименуем, оставив её на случай отката, если что-то у нас пойдёт не так.
Сам файл /etc/pki/ovirt-engine/ca.pem при этом не трогаем, так как он нужен для работы внутреннего ЦС oVirt и используется для меж-узлового обмена.

***

Заменим бандл apache.p12, используемый в данный момент oVirt, предварительно сделав копию уже существующего в системе файла на всякий случай.

# mv /etc/pki/ovirt-engine/keys/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12-BACK
# cp ~/ovirt-certs/ovirt-apache-bundle.p12 /etc/pki/ovirt-engine/keys/apache.p12

***

Заменим файл сертификата веб-сервера oVirt, используемый в конфигурации Apache (параметр SSLCertificateFile в файле /etc/httpd/conf.d/ssl.conf), опять же предварительно сделав копию используемого на данный момент файла. Второй командой фактически мы выгрузим из нашего обновлённого бандла apache.p12 сертификат самого веб-сервера вместе с корневым сертификатом нашего ЦС, то есть файл apache.cer это тоже своего рода бандл:

# mv /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/certs/apache.cer-BACK
# openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nokeys > /etc/pki/ovirt-engine/certs/apache.cer

В процессе выгрузки будет запрошен пароль. Напомню, что при создании бандла P12 ранее мы использовали пароль «mypass«.

***

Заменим файл закрытого ключа от сертификата веб-сервера oVirt, используемый в конфигурации Apache (параметр SSLCertificateKeyFile в файле /etc/httpd/conf.d/ssl.conf), предварительно сделав копию используемого на данный момент файла. Второй командой фактически мы выгрузим из нашего обновлённого бандла apache.p12 только закрытый ключ:

# mv /etc/pki/ovirt-engine/keys/apache.key.nopass /etc/pki/ovirt-engine/keys/apache.key.nopass-BACK
# openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -nocerts -nodes > /etc/pki/ovirt-engine/keys/apache.key.nopass

***

На этом этапе, если перезапустить службу веб-сервера (service httpd restart), мы увидим то, что веб-портал oVirt уже использует установленный нами сертификат. Однако это не вся конфигурация, и теперь нам нужно выполнить дополнительную настройку хранилища доверенных сертификатов java таким образом, чтобы в нём появился корневой сертификат нашего локального ЦС. В противном случае при попытке входа на портал администрирования oVirt мы словим ошибку:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Решение этой проблемы ранее было описано в Red Hat Bugzilla — Bug 1336838 — engine doesn’t trust externally-issued web certificate for internal authentication in spite of issuer being in system (and java) trust store и подтверждено в ветке обсуждения мейл группы oVirt [ovirt-users] oVirt 4 with custom SSL-certificate and SPICE HTML5 browser client -> WebSocket error: Can’t connect to websocket on URL: wss://ovirt.engine.fqdn:6100/. Далее привожу решение этой проблемы для версии oVirt Engine 4.0 в CentOS Linux 7.2.

Создаём дополнительный конфигурационный файл, который расширит механизм проверки хранилища доверенных сертификатов в oVirt:

# install -o ovirt -g ovirt -m 600 /dev/null /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf

Наполняем файл 99-custom-truststore.conf содержимым (пароль ‘changeit‘ используется по умолчанию для java truststore):

# cat > /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf << EOF
ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD="changeit"
EOF

Заданные нами переменные ENGINE_HTTPS_PKI_TRUST_STORE и ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD будут добавлены к конфигурации PKI для oVirt Engine. В конфигурации по умолчанию эти переменные ссылаются только на внутренний ЦС oVirt.

После скопируем корневой сертификат нашего локального корпоративного ЦС в специальный каталог и выполним обновление хранилища доверенных корневых сертификатов:

# cp ~/ovirt-certs/my-corp-ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust extract

Убедимся в том, что java truststore теперь содержит сведения о нашем корневом сертификате локального корпоративного ЦС. Для этого нам может потребоваться отпечаток SHA1 этого сертификата. Получить его можно командой:

# openssl x509 -in /etc/pki/ca-trust/source/anchors/my-corp-ca.pem -fingerprint -sha1 -noout

SHA1 Fingerprint=DE:43:0C:73:A5:8F:85:04:77:A7:64:FB:55:48:7C:D1:59:0F:7B:0A

Ну и соответственно запрос к хранилищу может выглядеть так (здесь в параметре -storepass мы используем пароль, ранее заданный в 99-custom-truststore.conf (по умолчанию ‘changeit‘)):

# keytool -list -keystore /etc/pki/java/cacerts -storepass changeit | grep "$( openssl x509 -in /etc/pki/ca-trust/source/anchors/my-corp-ca.pem -fingerprint -sha1 -noout | sed -e '/SHA1/s/.*=//;' )"

Certificate fingerprint (SHA1): DE:43:0C:73:A5:8F:85:04:77:A7:64:FB:55:48:7C:D1:59:0F:7B:0A

Как видим, наш корневой сертификат локального ЦС присутствует в хранилище java truststore.

Дополнительно можно проверить то, что сертификат также присутствует в подкаталогах /etc/pki/ca-trust/extracted/:

# grep -IR "$(sed -n '2p' /etc/pki/ca-trust/source/anchors/my-corp-ca.pem)" /etc/pki/ca-trust/extracted/

/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem:MIIERzCCAy+gIBAgIQb63kBz...BgkiG9w0BAQsFADBh
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem:MIIERzCCAy+gIBAgIQb63kBz...BgkiG9w0BAQsFADBh
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:MIIERzCCAy+gIBAgIQb63kBz...BgkiG9w0BAQsFADBh
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt:MIIERzCCAy+gIBAgIQb63kBz...BgkiG9w0BAQsFADBh

Перезапускаем службы oVirt Engine и проверяем результат.

# service ovirt-engine restart

Теперь веб-консоль порталов oVirt 4.0 должна открываться без предупреждений и ошибок.

***

Помимо вышеуказанных действий потребуется дополнительная конфигурация такой компоненты oVirt Engine, как WebSocket Proxy, без которой, в частности, не будет работать альтернативный метод подключения к консоли виртуальных машин с помощью HTML5 SPICE Web browser client. Приведём файл 10-setup.conf к следующему виду:

# cat /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf

PROXY_PORT=6100
SSL_CERTIFICATE=/etc/pki/ovirt-engine/apache-ca.pem
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
CERT_FOR_DATA_VERIFICATION=/etc/pki/ovirt-engine/certs/engine.cer
SSL_ONLY=True

После чего перезапустим службу WebSocket Proxy:

# service ovirt-websocket-proxy restart

На этом пока всё. В следующей записи мы рассмотрим базовые настройки oVirt.

Дополнительные источники информации: 

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