Как обновить openssl centos 7
Обновлено: 06.07.2024
Именно с такой задачей я столкнулся несколько дней назад на работе. Требовалось организовать поддержку ГОСТовых алгоритмов шифрования в CentOS/Redhat 7 , чтобы работать с сайтом госуслуг. Сразу оговорюсь, поддержка была добавлена в OpenSSL, curl и PHP 7.1 путем сборки из исходников .
Поддержка ГОСТ алгоритмов осуществляется с помощью модуля GOST Engine , добавляемого в OpenSSL .
Инструкция является сборной солянкой из найденного в интернете и адаптирована под CentOS 7, права на оригинальные инструкции, части которых были использованы принадлежат их авторам.
Исходные данные
Начнем с того, что у меня было:
- 1 сервер на CentOS 7 (площадка разработки)
- 3 сервера на Redhat 7 (боевые площадки)
- OpenSSL 1.0.2k - последняя доступная версия в репозиториях Centos/Redhat 7
- PHP 7.1.33 (FPM) из репозитория Remi (в режиме MultiVersion )
- Подключены репозитории EPEL/Remi
- На Redhat серверах ограничен доступ внешним ресурсам, поэтому часть того, что на CentOS 7 была скачана wget`ом, тут была загружена с помощью копирования скаченного архива на сервер.
- В PHP была добавлена поддержка БД MySQL и PostgreSQL (MariaDB 10 и PostgreSQL 10 соответственно).
Общий план работ
- Создание резервной копии директории /etc
- Обновить ОС на сервере
- Сборка OpenSSL 1.1.х
- Сборка GOST Engine
- Сборка Curl
- Сборка PHP
- Фиксация версий
Сборка OpenSSL
Для начала установим необходимые компоненты, а именно: подключим репозиторий EPEL (если не подключен), cmake3
Теперь удалим установленный OpenSSL, он мешает сборке, позже мы его вернем, для обратной совместимости. Предварительно сделайте резервные копии конфигов из /etc т.к. удалятся все зависимые пакеты (у меня удалился как минимум certbot ).
Проверим, что OpenSSL удалился, попытавшись вызвать его:
В результате должны получить ошибку, что он не установлен.
Скачиваем OpenSSL 1.1.0g в любую удобную директорию , только с ним у меня корректно все заработало и собралось. Если доступ к внешним ресурсам ограничен, то загрузите архив на сервер любым доступным вам способом, имя архива должно быть openssl-1.1.0g.tar.gz
Распаковываем загруженный архив:
Переходив в директорию openssl-1.1.0g
Запускаем конфигурацию OpenSSL, по окончании всей сборки (последующие этапы) он будет установлен в /usr/local/ssl/
./config no-async shared --prefix=/usr/local/ssl --openssldir=/usr/local/ssl -Wl,-rpath,/usr/local/ssl/lib
Теперь запускаем сборку и после ее успеха - установку:
Делаем симлинк на новый OpenSSL:
Теперь проверим доступность OpenSSL, он должен быть доступен в /usr/bin/openssl и вызываться обычной командой openssl :
В результате вы должны получить OpenSSL 1.1.0g
На этом сборка OpenSSL окончена, теперь добавим в него поддержку GOST шифрования.
Сборка GOST Engine
Перейдем в директорию, где будем осуществлять сборку:
Скачиваем архив с GOST Engin e, к сожалению у меня не заработала последняя версия, поэтому загружаем архив, с которым все успешно собиралось. Если доступ к внешним ресурсам ограничен, то загрузите архив любым доступным вам способом и именем gost-engine.zip в эту же директорию.
Переходим в директорию распакованного архива
Создадим директорию build , где будем осуществлять сборку и сразу перейдем в нее:
Сконфигурируем систему сборки:
И теперь соберем наш GOST Engine:
Выйдем в директорию bin выше уровнем
Скопируем утилиту gost12sum в директорию /usr/local/bin/
Выйдем еще выше уровнем
Скопируем собранный движок gost.so в директорию engines-1.1 openssl
Добавим конфигурацию для GOST Engine в файл конфигурации OpenSSL:
Теперь проверим, что движок GOST подключился:
В результате должен появиться список из доступных движков, где будет присутствовать gost :
Проверим список доступных шифров и найдем среди них интересующий нас GOST :
В результате вы должны получить следующий список:
Как видите, теперь OpenSSL умеет работать с ГОСТ шифрами. При генерации ключа нужный гост вызывается через -newkey gost2012_256
Сборка Curl
Перейдем в директорию, где будем выполнять сборку:
Теперь загрузим нужную версию Curl. У меня заработало только с 7.59.0. Если доступ к внешним ресурсам ограничен, то загрузите архив любым доступным вам способом с именем curl-7.59.0.tar.gz
Перейдем в распакованную директорию
Сконфигурируем Curl для работы с нужной версией OpenSSL
CPPFLAGS="-I/usr/local/ssl/include" LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib" LD_LIBRARY_PATH=/usr/local/ssl/lib ./configure --prefix=/usr/local/curl --with-ssl=/usr/local/ssl --with-libssl-prefix=/usr/local/ssl
Теперь соберем и установим Curl:
Переименуем оригинальный (системный) curl в curl_real :
Сделаем симлинк на свежесобранный curl в /usr/bin/curl
Ну и проверим версию собранного curl :
В результате вы должны получить нечто подобное:
На этом и сборку Curl мы закончили.
Теперь соберем PHP
Сборка PHP
При сборке PHP в RedHat 7 столкнулся с тем, что не все devel компоненты есть в стандартных репозиториях (в том числе EPEL). Поэтому пришлось скачать их с помощью другой CentOS 7 системы и закинуть в Redhat 7 нужные rpm файлы.
Только для RHEL:
В любом доступной вам CentOS 7 системе установите yum-utils :
После чего скачайте rpm файлы нужных библиотек:
yumdownloader bison-devel libwebp-devel libedit-devel
В результате вы получите набор rpm файлов, берите те, что оканчиваются на .x86_64.rpm и копируйте в RHEL систему любым доступным вам способом.
После чего установите эти rpm файлы:
Общая инструкция:
Удалим devel компоненты zlib , они могут мешать сборке:
Перейдем в директорию, где будем собирать PHP
В зависимости от того, какая БД вам нужна (мне пришлось собирать на Dev сервере с поддержкой MySQL и PostgreSQL, а на Prod серверах только с PostgreSQL) - установите нужные пакеты:
yum install libxml2 libxml2-devel bzip2-devel libmcrypt-devel libwebp-devel libjpeg-devel libpng-devel libicu-devel libpqxx-devel readline-devel bison-devel bison systemd-devel pkgconfig autoconf bison re2c libicu-devel e2fsprogs-devel mariadb-devel readline libedit-devel
yum install libxml2 libxml2-devel bzip2-devel libmcrypt-devel libwebp-devel libjpeg-devel libpng-devel libicu-devel libpqxx-devel readline-devel bison-devel bison systemd-devel pkgconfig autoconf bison re2c libicu-devel e2fsprogs-devel readline libedit-devel
Удалим devel компоненты openssl , если они установлены:
Создадим директорию, где позже расположим конфигурационные файлы модулей PHP:
Загрузим PHP 7.1.33 , именно эта версия у меня была установлена из Remi. Если доступ к внешним ресурсам ограничен, то загрузите архив любым доступным для вас способом в директорию /usr/src и именем php-7.1.33.tar.gz
Распакуем полученный архив
И перейдем в распакованную директорию:
Сделаем первичную конфигурацию:
Теперь в зависимости от поддержки нужных БД, сконфигурируем PHP. Если нужна поддержка обеих версий - добавьте разница одного варианта в другой, и не забудьте установить пакеты для обеих БД
./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php/etc --with-config-file-scan-dir=/usr/local/php/etc/conf.d --enable-fpm --with-fpm-systemd --with-openssl --with-openssl-dir=/usr/local/ssl --with-pcre-regex --with-pcre-jit --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-curl=/usr/local/curl --enable-exif --with-gd --enable-intl --enable-mbstring --enable-pcntl --with-pdo-pgsql --enable-soap --enable-sockets --with-xmlrpc --enable-zip --with-webp-dir --with-jpeg-dir --with-png-dir --enable-cli -enable-ftp --with-libedit --with-iconv --enable-json --with-mcrypt --enable-opcache --enable-pdo --with-pgsql --enable-xml --enable-xmlreader --enable-xmlwriter --with-pdo-pgsql=/usr/pgsql-10/bin --with-pgsql=/usr/pgsql-10/bin --with-mysqli --with-pdo-mysql
./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php/etc --with-config-file-scan-dir=/usr/local/php/etc/conf.d --enable-fpm --with-fpm-systemd --with-openssl --with-openssl-dir=/usr/local/ssl --with-pcre-regex --with-pcre-jit --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-curl=/usr/local/curl --enable-exif --with-gd --enable-intl --enable-mbstring --enable-pcntl --with-pdo-pgsql --enable-soap --enable-sockets --with-xmlrpc --enable-zip --with-webp-dir --with-jpeg-dir --with-png-dir --enable-cli -enable-ftp --with-libedit --with-iconv --enable-json --with-mcrypt --enable-opcache --enable-pdo --with-pgsql --enable-xml --enable-xmlreader --enable-xmlwriter --with-pdo-pgsql=/usr/pgsql-10/bin --with-pgsql=/usr/pgsql-10/bin
Очищаем директорию сборки
Далее есть один нюанс, если доступ к внешним ресурсам у вас ограничен, то последующие шаги у вас не завершатся успехом т.к. PHP пытается скачать PEAR из внешних источников.
Чтобы эту проблему решить - скачаем и положим нужный файл, в нужное место.
Загрузите файл с именем install-pear-nozlib.phar
После чего загрузите его в директорию /usr/src/php-src-php-7.1.33/pear / любым доступным вам способом.
Приступим непосредственно к сборке и установке:
Процесс довольно длительный, после окончания процесса, создадим симлинки на новую версию PHP
Приведу список команд без комментариев, но общий принцип таков, что если файл есть - переименовываем его с суффиксом _old
ln -s /usr/local/php/bin/pear /usr/bin/pear
ln -s /usr/local/php/bin/peardev /usr/bin/peardev
ln -s /usr/local/php/bin/pecl /usr/bin/pecl
mv /usr/bin/phar
ln -s /usr/local/php/bin/phar /usr/bin/phar
mv /usr/bin/php
ln -s /usr/local/php/bin/php /usr/bin/php
mv /usr/bin/php-cgi
ln -s /usr/local/php/bin/php-cgi /usr/bin/php-cgi
mv /usr/bin/php-config
ln -s /usr/local/php/bin/php-config /usr/bin/php-config
ln -s /usr/local/php/bin/phpdbg /usr/bin/phpdbg
mv /usr/bin/phpize
ln -s /usr/local/php/bin/phpize /usr/bin/phpize
ln -s /usr/local/php/sbin/php-fpm /usr/sbin/php-fpm
Файлы конфигурации ( php.ini и php-fpm.conf ) я брал из Remi
И подключим OpCache модуль:
echo "zend_extension=opcache.so" >> /usr/local/php/etc/conf.d/modules.ini
Сами конфиги пулов у меня лежат по иному пути, а т.к. я скопировал старый php-fpm.conf - то и новый php-fpm запустит их оттуда же.
Теперь создадим Systemd сервис для нашего php-fpm , для этого создайте любым удобным для вас редактором файл /usr/lib/systemd/system/php-fpm.service
И заполните его следующим:
[Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target
[Service]
Type=simple
PIDFile=/run/php-fpm/php-fpm.pid
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /usr/local/php/etc/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
Перезагрузите список демонов:
Теперь можно останавливать старый FPM и запускать новый. Старый у меня был доступен под именем php71-php-fpm , а новый просто php-fpm :
systemctl stop php71-php-fpm && systemctl start php-fpm
И добавим/исключим в автозагрузку сервисы:
systemctl enable php-fpm && systemctl disable php71-php-fpm
На этом основная часть закончена. Теперь не менее важный этап - установка Openssl (да, того самого, из репозитория) и блокировка обновлений.
Установим снова openssl, для обратной совместимости:
При установке openssl подменит наш симлинк, поэтому вернем всё к нашей версии:
И восстановим симлинк:
Теперь зафиксируем версии openssl и curl, чтобы они не начали обновляться. От PHP из Remi мы уже не зависим, поэтому не блокируем.
Установите модуль yum - versionlock
Важное замечание по OpenSSL
После пары дней работы заметил, что начал при работе с сервисами (использующие SSL/TLS) ошибку вроде:
OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Думал где-то в коде проблема, а оказалось в другом. OpenSSL хранит некоторое количество сертификатов (корневые) и при сборке из исходников они не подтягиваются. Т.к. у нас установлен openssl в любом случае (системный), то актуальный список сертификатов у нас есть, а значит его мы можем симлинками подкинуть в нашу версию openssl. Приведу несколько команд, без комментариев. Сутя такая, что удаляем пустые папки и на их место кидаем симлинки.
rm -rf /usr/local/ssl/
ln -s /etc/pki/tls/certs /usr/local/ssl/certs
ln -s /etc/pki/tls/private /usr/local/ssl/private
ln -s /etc/pki/tls/cert.pem /usr/local/ssl/cert.pem
Заключение
Т.к. мне требовались конкретные версии PHP и собралось оно только на определенных версиях всех перечисленных выше компонентов - то привел инструкцию как оно точно собирается, не исключено, что и на других версиях оно соберется. Другие версии сам не пробовал т.к. требовалось запустить сервис клиента как можно скорее (как обычно у клиента всё в последний день).
Знаю, что это всё можно было оптимизировать, как-то систематизировать, но нужно было решить задачу в кратчайшие сроки, а найденные в интернете инструкции были слишком разрознены, либо сводились к использованию только в docker, либо только в Deb системах.
Инструкция в общем плане подходит и для более свежих версий PHP (с теми же версиями openssl/gost/curl), но придется повозиться с зависимостями и конфигурацией.
Клиент попросил стороннюю компанию по обеспечению безопасности просканировать их сервер и обнаружил, что SSH имеет множество уязвимостей в системе безопасности. Причина в том, что даже самый свежий (на 2021 год) CentOS 7.9 использует более старую версию OpenSSH v7.4, и эти уязвимости были исправлены в новой версии OpenSSH, поэтому по соображениям безопасности требуется обновление.
В этой статье мы обновимся до самой последней версии OpenSSH. На момент написания статьи это версия 8.5p1.
В yum нет последней версии OpenSSH, соответственно нам нужно загрузить исходники OpenSSH из официальной компиляции и сделать установочный пакет rpm. Поскольку клиентский сервер не может подключиться к внешней сети, его необходимо преобразовать в пакет автономного обновления.
Подготовка и сборка RPM
Скачиваем последнюю версию OpenSSH:
Всё распаковываем и копируем:
Даём права созданному пользователю rpmbuilder и переключаемся на него:
Вносим изменения в файл openssh.spec:
Переключаемся на root и вносим изменение в файл /usr/lib/rpm/macros:
Переключаемся на пользователя rpmbuilder и собираем rpm пакеты:
После компиляции в конце вывод должен быть примерно таким:
ВНИМАНИЕ! После сборки пакетов не забудьте снова изменить файл /usr/lib/rpm/macros:
Теперь собранные пакеты находятся в /home/rpmbuilder/rpmbuild/RPMS/x86_64/:
Примечание: openssh-debuginfo-8.5p1-1.el7.x86_64.rpm является отладочным пакетом, который не нужен во время обновления и должен быть удален.
Обновляем OpenSSH собранными пакетами:
Только что мы обновили OpenSSH с версии 6.4 до 8.5.
После того как OpenSSH установлен пробуем подключиться к серверу и терпим неудачу:
Возврашаемся на наш сервер, выполняем systemctl status sshd и видим, что сервис в статусе failed, а также проблемы с правами на файлы ключей (на скриншоте выделил белым)
Сначала мы думали, что у созданного нами пакета rpm возникла проблема. На самом деле конфигурация по умолчанию была неправильной.
Невозможно было войти в систему через SSH по ключам. Поэтому необходимо изменить разрешение файлов ключей!
Смотрим список ключей:
И меняем права на них:
Перезапускаем ssh и видим, что всё отлично:
А вот по паролю OpenSSH всё равно не пустит
Для этого необходимо изменить конфиг-файл sshd_config, а так же обновить динамическую библиотеку pam_stack.so, потому что старый OpenSSH использует старую библиотеку.
Делаем бекап конфиг-файла и вносим изменения:
Перезапускаем sshd и проверяем статус:
Но это еще не всё. Было обнаружено, что в качестве сценария запуска используется обновленная служба sshd, а не файл /usr/lib/systemd/system/sshd.service.
Фактически, в процессе обновления программа удалила /usr/lib/systemd/system/sshd.service и добавила сценарий запуска службы /etc/init.d/sshd
Кроме того, после обновления команда копирования открытого ключа ssh-copy-id, которую мы часто используем для входа в систему без секретов, исчезла!
На самом деле дело не в том, что файла больше нет, просто нужно скопировать файл ssh-copy-id из каталога распакованного исходника openssh-8.5p1, который мы скачали в самом начале статьи, в каталог /usr/bin/.
Два, обновите openssh7.9
Весь зависимый сервер загрузки пакетов (я поместил его в каталог / home / soft)
1. Сначала установите telnet-server (чтобы предотвратить удаленный вход после обновления openssh)
2. Установите xinetd
3. Принудительно установить все связанные зависимости
4. Обновите zlib
Установка zlib проходит успешно следующим образом:
После успешной установки:
5. Обновите openssl
Проверьте номер версии openssl, чтобы убедиться, что установка правильная, как показано ниже:
5. Обновите openssh
Подтвердите, что текущие OpenSSH и OpenSSL верны:
Если вы видите номер новой версии, обновление прошло успешно, а именно:
На этом обновление завершено.
В-третьих, ямы, обнаруженные после обновления.
1. Корень не может войти в систему удаленно, и ему было отказано.
Решение:
Зарегистрируйте, если возникнет следующая ситуация
Решение:
Любые другие вопросы приветствуются.
Интеллектуальная рекомендация
совместный запрос mysql с тремя таблицами (таблица сотрудников, таблица отделов, таблица зарплат)
1. Краткое изложение проблемы: (внизу есть инструкция по созданию таблицы, копирование можно непосредственно практиковать с помощью (mysql)) Найдите отделы, в которых есть хотя бы один сотрудник. Отоб.
[Загрузчик классов обучения JVM] Третий день пользовательского контента, связанного с загрузчиком классов
IP, сеанс и cookie
Команда OpenSSL s_server реализует общий SSL/TLS-сервер. Она должна использоваться только для целей тестирования. В приведенном ниже примере данный сервер прослушивает соединения на порту 8080 и возвращает отформатированную HTML страницу статуса, который включает много информации о ciphers:
Конвертирование сертификатов с DER в PEM формат.
Как правило, при покупке SSL сертификатов, его отдают вам в формате .der и если вам нужно использовать его в веб-сервере или .pem формате, вы можете использовать команду выше, чтобы преобразовать такие сертификаты.
Совет: Вы можете включить «chain certificate» используя «-chain» опцию:
Создание CSR используя приватный ключ (private key).
Если вы не хотите создать новый секретный ключ, а хотите используя вместо существующего, вы можете с предыдущей командой.
Проверьте содержимое сертификата в PKCS12 формате.
PKCS12 — это двоичный формат, так что вы не сможете просматривать содержимое в блокноте или другом редакторе. Таким образом, вы должны использовать команду что выше, для просмотра содержимого файла формата PKCS12.
Получить SHA-1 отпечаток сертификата или CSR
Чтобы получить отпечаток SHA1 сертификата с использованием OpenSSL, используйте команду, приведенную ниже:
Чтобы получить SHA1 отпечаток пальца CSR с использованием OpenSSL, используйте команду, приведенную ниже:
Получить MD5 отпечаток сертификата или CSR
Чтобы получить отпечаток MD5 сертификата с использованием OpenSSL, используйте команду, приведенную ниже:
Чтобы получить MD5 отпечаток пальца CSR с использованием OpenSSL, используйте команду, приведенную ниже:
Тестирование SSL сертификата по URL.
Я использую это довольно часто для проверки SSL-сертификатов по URL с сервера. Это очень удобно для проверки некоторых деталей протокола, шифров и CERT.
Узнать версию OpenSSL
Проверка SSL версии V2:
Проверка SSL версии V3:
Проверка TLS 1.0:
Проверка TLS 1.1:
Проверка TLS 1.2:
Получить сертификат по URL
Команда что ниже, сохранит сертификат в файл прямо по URL сайта:
Если веб-сервер имеет несколько сертификатов на один IP-адрес, то вам нужно будет сообщить OpenSSL, какой сертификат будет использоваться, пример ниже:
Вот и все, много полезностей и все в одной статье «Примеры использования OpenSSL в Unix/Linux».
Использование алгоритмов с открытым ключем
Создание пары приватный/публичный ключ
Шифрование данных
Цифровая подпись
Getting Help[edit]
As mentioned previously, the general syntax of a command is . The help command is no different, but it does have its idiosyncrasies. To view the top-level help menu, you can call openssl as follows.
This query will print all of the available commands, like so:
Note the above output was truncated, so only the first four lines of output are shown.
A help menu for each command may be requested in two different ways. First, the same command used above may be repeated, followed by the name of the command to print help for.
The program will then display the valid options for the given command.
The second way of requesting the help menu for a particular command is by using the first option in the output shown above, namely . Both commands will yield the same output; the help menu displayed will be exactly the same.
Использование CRL клиентами
Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.
Если сертификат был подписан с расширением, которое включает , клиентское приложение может прочитать эту информацию и получить CRL из указанного места.
Точки распространения CRL видны в спецификациях X509v3 сертификата.
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.
Например, когда веб-браузеру предоставлен сертификат сервера, он посылает запрос на адрес сервера OCSP, указанном в сертификате. По этому адресу OCSP слушает запросы и отвечает статусом отзыва сертификата.
Рекомендуется использовать OCSP вместо CRL, где это возможно, хотя реально, как правило, OCSP нужен только для сертификатов веб-сайтов. Некоторыми веб-браузерами поддержка CRL считается устаревшей, или вообще убрана.
Шаг 3 — Настройка брандмауэра
Если у вас включен брандмаэр в соответствии с предварительными требованиями, вам может потребоваться изменить настройки для поддержки трафика SSL . К счастью, Apache регистрирует несколько профилей после установки.
Мы можем просмотреть доступные профили с помощью следующей команды:
Список должен выглядеть примерно так:
Вы можете просмотреть текущие настройки с помощью следующей команды:
Теперь ваш статус должен выглядеть примерно так:
Из исходника
Устанавливаем пакеты, необходимые для сборки пакета:
yum install make gcc
* как видим, на момент написания обновления инструкции это была версия 1.1.1.
И копируем ссылку на ее скачивание:
На CentOS скачиваем исходник с использованием найденной ссылки:
И распаковываем его с последующим удалением:
tar -xvf openssl-*.tar.gz && \rm openssl-*.tar.gz
Переходим в папку с распакованным исходником:
Резервируем предыдущую версию openssl:
mv /usr/bin/openssl /root/openssl.back
И делаем ссылку на новую:
ln -s /usr/local/bin/openssl /usr/bin/openssl
Снова проверяем версию:
openssl version -a
Система вернет полные сведения об openssl, например:
Обращаем внимание, что у нас установлена новая версия OpenSSL, но по прежнему, используется старая библиотека — Library: OpenSSL 1.0.2k-fips 26 Jan 2017. Необходимо добавить в ldconfig новый путь
Для это создаем файл:
Необходимо добавить в ldconfig новый путь. Для это создаем файл:
* если у нас используется система 32-бит, то путь будет /usr/local/lib.
Мы должны увидеть:
OpenSSL 1.1.1g 21 Apr 2020
Предварительные требования
Для начала у вас должен быть пользователь без прав root с привилегиями . Чтобы создать такую учетную запись пользователя, следуйте указаниям руководства «Начальная настройка сервера с Ubuntu 18.04».
Также вам потребуется установить веб-сервер Apache. Если вы хотите установить на сервере полный комплект LAMP (Linux, Apache, MySQL, PHP), следуйте указаниям обучающего модуля «Установка LAMP в Ubuntu 18.04». Если вы хотите просто установить веб-сервер Apache, пропустите шаги, относящиеся к установке PHP и MySQL.
Когда предварительные требования будут выполнены, переходите к приведенным ниже шагам.
Getting Library Version Information[edit]
Using the -a option to show all version information yields the following output on my current machine:
Полезные команды openssl
Создание ключа для SSL-сертификата. Если не указывать -des3, то он будет без пароля:
В случае утери пароля или файла ключа придется пересоздавать сертификат.
Убрать пароль с ключа (необходимо когда сертификат ставится в конфигурацию Apache, иначе он при запуске будет просить пароль):
и вводим пароль с консоли (либо -passin pass:supersecretpassword что считается менее безопасным)
Прочитать содержимое CSR-файла в более удобном для чтения текстовом виде:
Шаг 1 – Создание сертификата SSL
Протоколы TLS и SSL используют сочетание открытого сертификата и закрытого ключа. Секретный ключ SSL хранится на сервере. Он используется для шифрования отправляемых на клиентские системы данных. Сертификат SSL находится в открытом доступе для всех, кто запрашивает этот контент. Его можно использовать для расшифровки контента, подписанного соответствующим ключом SSL.
Мы можем создать самоподписанный ключ и пару сертификатов OpenSSL с помощью одной команды:
Вам будет предложено ответить на ряд вопросов. Прежде чем перейти к этому шагу, посмотрим, что делает отправляемая нами команда:
- openssl: это базовый инструмент командной строки для создания и управления сертификатами OpenSSL, ключами и другими файлами.
- req: данная субкоманда указывает, что мы хотим использовать управление запросами подписи сертификатов X.509 (CSR). X.509 — это стандарт инфраструктуры открытых ключей, используемый SSL и TLS для управления ключами и сертификатами. Вы хотим создать новый сертификат X.509, и поэтому используем эту субкоманду.
- -x509: это дополнительно изменяет предыдущую субкоманду, сообщая утилите, что мы хотим создать самоподписанный сертификат, а не сгенерировать запрос на подпись сертификата, как обычно происходит.
- -nodes: этот параметр указывает OpenSSL пропустить опцию защиты сертификата с помощью пароля. Для чтения этого файла при запуске сервера без вмешательства пользователя нам потребуется Apache. Кодовая фраза может предотвратить это, поскольку нам придется вводить ее после каждого перезапуска.
- -days 365: данный параметр устанавливает срок, в течение которого сертификат будет считаться действительным. Здесь мы устанавливаем срок действия в один год.
- -newkey rsa:2048: указывает, что мы хотим генерировать новый сертификат и новый ключ одновременно. Мы не создали требуемый ключ для подписи сертификата на предыдущем шаге, и поэтому нам нужно создать его вместе с сертификатом. Часть указывает, что мы создаем ключ RSA длиной 2048 бит.
- -keyout: эта строка указывает OpenSSL, где мы разместим создаваемый закрытый ключ.
- -out: данный параметр указывает OpenSSL, куда поместить создаваемый сертификат.
Как мы указывали выше, эти опции создают и файл ключа, и сертификат. Нам будет задано несколько вопросов о нашем сервере, чтобы правильно вставить информацию в сертификат.
Укажите подходящие ответы. Самая важная строка — это строка, где запрашивается . Вам нужно ввести доменное имя, связанное с вашим сервером или, что более вероятно, публичный IP-адрес вашего сервера.
В целом диалоги выглядят примерно так:
Оба созданных вами файла будут помещены в соответствующие подкаталоги в каталоге .
Подготовка конфигурационных файлов
Необходимо создать конфигурационный файл для OpenSSL. Создадим файл , скопируем в него следующее содержимое root-config.txt.
Раздел является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела :
Раздел содержит ряд значений по умолчанию:
Policy_strict будет применяться для всех подписей корневого центра сертификации, и корневой центр сертификации будет использоваться только для создания промежуточных центров сертификации.
Применим для всех подписей промежуточных центров серфтификации, так как промежуточные центры сертификации это подписывающие серверы, и клиентские сертификаты могут приходить от различных третьих лиц.
Параметры из секции применяются когда создаются сертификаты или запросы на подписывание сертификатов.
Секция определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.
Следующие несколько секций являются расширениями, которые могут применять при подписывании сертификатов. Например, при указании аргумента командной строки -extensions v3_ca будут применены расширения из секции . Эти расширения будут применяться при создании корневого сертификата.
При создании сертификата промежуточного центра сертификации будут применяться расширения из . Параметр указывает, что не может быть никаких дальнейших центров сертификации ниже промежуточного центра сертификации.
Расширение будет применяться при подписывании клиентских сертификатов, таких, которые используются для аутентификации удаленных пользователей.
Расширение будет применяться при подписывании серверных сертификатов, таких, которые используются для веб-серверов.
Расширение будет автоматически применяться при создании списков отзыва сертификатов (CRL — certificate revocation lists).
Расширение будет применяться при подписывании сертификата OCSP (Online Certificate Status Protocol, онлайн протокол статуса сертификатов).
Шаг 5 — Тестирование шифрования
Теперь мы готовы протестировать наш сервер SSL.
Откройте браузер и введите и доменное имя или IP-адрес вашего сервера в адресную панель:
Поскольку созданный нами сертификат не подписан одним из доверенных центров сертификации вашего браузера, вы увидите пугающее предупреждение, которое будет выглядеть примерно так:
Такое предупреждение нормально, и его следует ожидать. Сертификат нам нужен только для шифрования, а не для подтверждения подлинности нашего хоста третьей стороной. Нажмите «Дополнительно», а затем нажмите на указанную ссылку, чтобы перейти к своему хосту:
Теперь должен открыться ваш сайт. Если вы посмотрите в адресную строку браузера, вы увидите символ замка со знаком «x». В данном случае это означает, что сертификат не удается проверить. Ваше соединение все равно шифруется.
Если при этом появляется такой же значок, перенаправление работает правильно.
Autoconf[edit]
OpenSSL uses its own configuration system, and does not use Autoconf. However, a number of popular projects use both OpenSSL and Autoconf, and it would be useful to detect either OPENSSL_init_ssl or SSL_library_init from libssl. To craft a feature test for OpenSSL that recognizes both OPENSSL_init_ssl and SSL_library_init, you can use the following.
Generating a Public Key[edit]
Having previously generated your private key, you may generate the corresponding public key using the following command.
You may once again view the key details, using a slightly different command this time.
The output for the public key will be shorter, as it carries much less information, and it will look something like this.
For more information on generating keys, see the source code documentation, located in the doc/HOWTO/keys.txt file.
openssl 1.1.1.h-1
Versions Elsewhere
- lib32-openssl 1:1.1.1.h-1 (x86_64)
- openssl 1.1.1.h-2 (x86_64)
Required By (350)
Создание центра сертификации
Настройка атрибутов базы CA в конфигурации ssl
Создание зашифрованного приватного ключа
Настройка атрибутов организации в конфигурации ssl
Создание самоподписанного корневого сертификата
Создание ключа
Наши корневая и промежуточная пары 4096 бит. Серверный и клиентский сертификат обычно истекают после одного года, поэтому мы можем безопасно использовать 2048 бит.
Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.
Читайте также: