Как установить ssl сертификат на ubuntu

Security — Certificates

One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key. The system works by encrypting information using the public key. The information can then only be decrypted using the private key.

A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. One example: configuring Apache to provide HTTPS, the HTTP protocol over SSL/TLS. This allows a way to encrypt traffic using a protocol that does not itself provide encryption.

A certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certification Authority, or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.

Types of Certificates

To set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company’s identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server. Alternatively, you can create your own self-signed certificate.

Note

Note that self-signed certificates should not be used in most production environments.

Continuing the HTTPS example, a CA-signed certificate provides two important capabilities that a self-signed certificate does not:

Browsers (usually) automatically recognize the CA signature and allow a secure connection to be made without prompting the user.

When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.

Most of the software supporting SSL/TLS have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection. Also, other applications may generate an error message when using a self-signed certificate.

The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:

Create a private and public encryption key pair.

Create a certificate signing request based on the public key. The certificate request contains information about your server and the company hosting it.

Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.

Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.

When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.

Install this certificate on your secure server, and configure the appropriate applications to use the certificate.

Generating a Certificate Signing Request (CSR)

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.

If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc., a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.

This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.

Warning

Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.

To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:

You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. As a best practice it should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.

Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.

Now create the insecure key, the one without a passphrase, and shuffle the key names:

The insecure key is now named server.key , and you can use this file to generate the CSR without passphrase.

To create the CSR, run the following command at a terminal prompt:

It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file.

You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.

Creating a Self-Signed Certificate

To create the self-signed certificate, run the following command at a terminal prompt:

The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.

Warning

If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.

Installing the Certificate

You can install the key file server.key and certificate file server.crt , or the certificate file issued by your CA, by running following commands at a terminal prompt:

Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.

Certification Authority

If the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal Certification Authority (CA). Using certificates signed by your own CA, allows the various services using the certificates to easily trust other services using certificates issued from the same CA.

First, create the directories to hold the CA certificate and related files:

The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:

The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit /etc/ssl/openssl.cnf , and in the [ CA_default ] change:

Next, create the self-signed root certificate:

You will then be asked to enter the details about the certificate.

Now install the root certificate and key:

You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see Generating a Certificate Signing Request (CSR) for details. Once you have a CSR, enter the following to generate a certificate signed by the CA:

After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.

There should now be a new file, /etc/ssl/newcerts/01.pem , containing the same output. Copy and paste everything beginning with the line: ——BEGIN CERTIFICATE—— and continuing through the line: —-END CERTIFICATE—— lines to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt , is a nice descriptive name.

Subsequent certificates will be named 02.pem , 03.pem , etc.

Note

Replace mail.example.com.crt with your own descriptive name.

Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs . This enables multiple services to use the same certificate without overly complicated file permissions.

For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.

References

The Wikipedia HTTPS page has more information regarding HTTPS.

For more information on OpenSSL see the OpenSSL Home Page.

Also, O’Reilly’s Network Security with OpenSSL is a good in-depth reference.

Установка сертификатов в Ubuntu

Сертификаты SSL используются для обеспечения безопасности в различных сферах. Самая распространенная — это просмотр веб-сайтов по протоколу HTTPS. Существует небольшое количество доверенных корневых сертификатов организаций, которые подписывают остальные сертификаты для всех сайтов. Эти доверенные сертификаты хранятся на каждом компьютере или смартфоне. И именно исходя из этого веб-браузер может понимать, что тому или иному сайту можно доверять.

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

Что нам понадобится?

Я хочу показать на примере как сделать сертификат доверенным в Ubuntu. Для этого можно создать свой центр сертификации CA с помощью EasyRSA, создать и подписать SSL сертификат, как это описано в статье про создание сертификатов OpenSSL. Далее использовать этот сертификат для домена localhost в Apache. Таким образом у вас получится три файла:

• ca.crt — корневой сертификат центра сертификации;
• localhost.crt — сертификат сайта подписанный центром сертификации;
• localhost.key — ключ сертификата сайта.

Активируйте файл виртуального хоста Apache для сайта по умолчанию с помощью такой команды:

sudo a2ensite default-ssl

Далее откройте этот файл и найдите такие строки:

SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Для параметра SSLCertificateFile надо передать путь к сертификату сайта, например, localhost.crt, а для SSLCertificateKeyFile — ключу сертификата сайта. Например, localhost.key. Если сертификаты находятся в папке /etc/apache/ssl, то конфигуация будет выглядеть вот так:

SSLCertificateFile /etc/apache/ssl/localhost.crt SSLCertificateKeyFile /etc/apache/ssl/localhost.key

После этого нужно перезапустить Apache:

sudo systemctl restart apache2

Теперь у вас всё готово для того чтобы выполнить всё описанное ниже в своей системе.

Установка сертификатов в Ubuntu

1. Установка в системе

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

curl -I https://localhost

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

И так, у вас есть сертификат ca.crt. Для того чтобы система считала его доверенным, нужно скопировать его в папку /usr/local/share/ca-certificates:

cp ./ca.crt /usr/local/share/ca-certificates/losstca.crt

После этого необходимо выполнить такую команду:

После этого можно проверить что система воспринимает сертификат как доверенный выполнив команду curl:

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

Chrome, Firefox, Thunderbird используют nssdb для работы с сертификатами. Это значит что вы можете импортировать сертификаты как в графическом интерфейсе браузера, так и в терминале, с помощью утилиты certutil. Давайте рассмотрим как это сделать. Давайте рассмотрим как выполняется установка сертификата в Ubuntu.

2. Установка в Google Chrome

Для того чтобы добавить сертификат в Google Chrome или Chromium в графическом интерфейсе откройте настройки из главного меню:

Перейдите в Конфиденциальность и безопасность -> Безопасность -> Настроить сертификаты:

В открывшемся окне перейдите на вкладку Центры сертификации:

Здесь необходимо нажать кнопку Импорт и выбрать файл корневого сертификата:

Далее надо настроить параметры доверия. Поскольку сейчас сертификат будет использоваться для подтверждения подлинности сайтов, то можно оставить только первый пункт:

После этого сертификат будет добавлен и вы больше не будете видеть информацию о том, что подключение не безопасное.

В командной строке всё тоже довольно просто. Для работы с сертификатами вам понадобится пакет libnss3-tools, установите его с помощью команды:

sudo apt install libnss3-tools

База данных сертификатов Google Chrome находится в папке

/.pki/nssdb. Вы можете посмотреть доступные сертификаты командой:

Синтаксис команды для добавления сертификата следующий:

$ certutil -d путь/к/базе/данных -A -t «настройки_доверия» -n «имя» -i «/путь/к/файлу»

Обратите внимание на настройки доверия. Существует три группы атрибутов доверия:

• Для SSL;
• Для Email;
• Для программного обеспечения и других объектов.

Каждая из групп может содержать такие атрибуты:

• p — валидный пир;
• P — доверенный пир;
• c — валидный центр сертификации;
• C — доверенный центр сертификации;
• T — доверенный центр сертификации для авторизации клиентов.

Для SSL сертификатов можно достаточно такой последовательности «TC,,». То есть атрибуты T и C для SSL и ничего для всего остального. Вся команда для импорта ca.crt будет выглядеть вот так:

/.pki/nssdb -A -t «TC,,» -n «Losst CA» -i ./ca.crt

После этого вы снова можете посмотреть список сертификатов для того чтобы убедится что всё хорошо:

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

3. Установка в Firefox

В Firefox всё немного сложнее. Тут нет централизованного хранилища сертификатов, а поэтому их придется добавлять для каждого профиля отдельно, что в графическом интерфейсе, что в командной строке. Для того чтобы добавить сертификат в графическом интерфейсе откройте Настройки в главном меню:

Далее перейдите в раздел Защита и безопасность и найдите там пункт Сертификаты. Здесь надо нажать кнопку Посмотреть сертификаты:

В открывшемся окне перейдите на вкладку Центры сертификации и нажмите кнопку Импортировать, для того чтобы добавить свой сертификат. Далее выберите файл сертификата и установить настройки доверия. Нужно отметить как минимум первую галочку — Доверять при идентификации веб-сайтов:

На этом установка SSL сертификата в Firefox завершена. Если вы хотите добавить сертификат в командной строке, то необходимо добавить его во все профили. Профили находятся в папке

/.mozilla/firefox/. В данном примере, есть два профиля и только один из них заполнен:

Файлы nssdb находятся прямо в папке профиля, поэтому можно просто передать эту папку в certutil. Например, для просмотра списка сертификатов выполните:

Для добавления сертификата используйте такую команду подставив свой путь к папке профиля:

/.mozilla/firefox/k9z8sttc.default-release/ -A -t «TC,,» -n «Losst» -i ./ca.crt

После этого полученный сертификат появится в списке.

Обратите внимание, что такой способ работает для Firefox, установленного как .deb пакет. Если у вас Firefox, установленный с помощью пакетного менеджера snap, то этот метод может не работать.

Для Firefox есть ещё один способ добавить сертификаты из системы автоматически без использования certutil. Это загрузка сертификатов с помощью политики. Возможно вы слышали про опцию security.enterprise_roots.enabled в about:config. Она работает только в Windows и MacOS но не в Linux. Однако, можно создать файл политики папке /usr/lib/firefox/distribution/ и там прописать какие сертификаты следует загрузить. По умолчанию Firefox будет искать сертификаты таких каталогах:

• /usr/lib/mozilla/certificates
• /usr/lib64/mozilla/certificates

В самом файле надо указать имена файлов сертификатов если они находятся в одной из этих папок или полный путь к ним. Например, скопируйте сертификат CA в папку /usr/lib/mozilla/certificates:

Поддерживаются как ASCII сертификаты (CRT/PEM), так и двоичные (DER). Затем создайте файл политики со следующем содержимым:

sudo vi /usr/lib/firefox/distribution/policies.json

Перезапустите браузер и после этого Firefox должен начать видеть ваш сертификат.

Выводы

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

Сертификаты

Одной из наиболее распространенных форм криптографии сегодня является криптография на открытых ключах. Криптография на открытых ключах использует открытый (public) и закрытый (secret) ключи. Система выполняет шифрование с использованием открытого ключа. Расшифрована такая информация может быть только с использованием закрытого ключа.

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

Типы сертификатов

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

Продолжая пример с HTTPS, сертификат, подписанный CA, предоставляет два важных свойства в отличие от самоподписанного сертификата:

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

Когда CA выпускает подписанный сертификат, он гарантирует идентичность организации, которая предоставляет интернет страницы браузеру.

Процесс получения сертификата из CA довольно прост. Короткий обзор его приведен ниже:

Создайте пару из открытого и закрытого ключей.

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

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

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

Установите это сертификат на ваш защищенный сервер и настройте соответствующие приложения на его использование.

Создание запроса на подпись сертификата (CSR)

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

Если сертификат будет использоваться системными сервисами такими, как Apache, Postfix, Dovecot и т.п., уместно создать ключ без пароля. Отсутствие пароля позволяет сервису стартовать с минимальным ручным вмешательством, обычно это предпочтительный вариант запуска сервиса.

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

Для генерации ключей CSR запроса, запустите следующую команду из терминала:

Теперь вы можете ввести вашу кодовую фразу. Для лучшей безопасности рекомендуется использовать не менее восьми символов. Минимальная длина при использовании -des3 — 4 символа. Фраза должна включать цифры и/или знаки препинания и не должно быть словом из словаря. Также не забывайте, что ваша фраза будет чувствительна к регистру.

Повторите ввод для проверки. В случае корректного ввода ключ сервера будет создан и записан в файл server.key.

Теперь создадим небезопасный ключ, без кодовой фразы и поменяем имена ключей:

Небезопасный ключ теперь называется server.key и вы можете использовать его для создания CSR без кодовой фразы.

Для создания CSR выполните следующую команду в терминале:

У вас будет запрошена кодовая фраза (при использовании ключа с паролем — прим. пер.). Если введена корректная фраза, у вас запросят название компании, имя сайта, email и пр. Как только вы введете все эти подробности, будет создан запрос CSR и сохранен в файл server.csr.

Теперь вы можете оправить CSR файл в центр сертификации для обработки. CA использует этот файл для выпуска сертификата. С другой стороны, вы можете создать и самозаверенный сертификат, используя этот же CSR.

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

Для создания самоподписанного сертификата, запустите следующую команду в терминале:

Эта команда попросит вас ввести кодовую фразу. Как только вы введете корректную фразу, ваш сертификат будет создан и сохранен в файл server.crt.

Установка сертификата

Вы можете установить файлы ключа server.key и сертификата server.crt (или файл сертификата, выданный вашим CA), запуском следующих команд в терминале:

Теперь просто настройте любое приложение с возможностью использования криптографии на открытых ключах для использования этих файлов ключа и сертификата. Например, Apache может предоставить HTTPS, Dovecot предоставляет IMAPS и POP3S, и т.д.

Центр сертификации

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

1. Сначала создайте каталоги для хранения сертификата CA и необходимых файлов:

2. Центр сертификации требует несколько дополнительных файлов для своей работы; один для хранения последнего серийного номера, использованного CA, другой для записи какие сертификаты были выпущены:

3. Третий файл — это файл настроек CA. Хотя он не строго обязателен, но очень удобен для выпуска множества сертификатов. Отредактируйте /etc/ssl/openssl.cnf, изменив секцию [ CA_default ]:

4. Далее создайте самоподписанный сертификат:

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

5. Теперь установим корневой сертификат и ключ:

6. Теперь вы готовы приступить к выпуску сертификатов. Первое, что вам потребуется — запрос на сертификат (CSR). Смотрите детали в разделе Создание запроса на подпись сертификата (CSR). Получив CSR, введите следующую команду для создания сертификата, подписанного нашим центром:

После ввода пароля для ключа CA у вас запросят подтверждение на подпись сертификата и еще одно на сохранение нового сертификата. Затем вы сможете увидеть нечто с объемным выводом, относящееся к созданию сертификата.

7. Теперь у вас должен появиться новый файл /etc/ssl/newcerts/01.pem, с таким же содержанием, что и в предыдущем выводе. Выделите и скопируйте все, начиная со строки ——BEGIN CERTIFICATE—— и до строки ——END CERTIFICATE—— в файл с названием по сетевому имени сервера, где он будет установлен. Например, mail.example.com.crt — вполне хорошее описательное имя.

Последующие сертификаты будут иметь имена 02.pem, 03.pem и т.д.

8. Наконец, скопируйте новый сертификат на компьютер, для которого он выпущен, и настройте соответствующие приложения на его использование. Место по умолчанию для установки сертификатов — каталог /etc/ssl/certs. Это позволяет многим сервисам использовать один и тот же сертификат без чрезмерного усложнения прав доступа к файлу.

Для приложений, которые могут быть настроены на использование сертификата CA, вы можете скопировать файл /etc/ssl/certs/cacert.pem в каталог /etc/ssl/certs/ на каждом сервере.

Ссылки

Для более детальных инструкций по использованию криптографии смотрите SSL Certificates HOWTO на tlpd.org.

Страница Википедии HTTPS содержит больше относительно HTTPS.

Для дополнительной информации по OpenSSL смотрите домашнюю страницу OpenSSL.

Также хорошее глубокое руководство Network Security with OpenSSL от O'Reilly.

Создание самоподписанных сертификатов SSL для Apache в Ubuntu 18.04

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

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

В этом обучающем модуле мы покажем, как создать самоподписанный сертификат SSL для использования с веб-сервером Apache в Ubuntu 18.04.

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

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

Предварительные требования

Для начала у вас должен быть пользователь без прав root с привилегиями sudo . Чтобы создать такую учетную запись пользователя, следуйте указаниям руководства «Начальная настройка сервера с Ubuntu 18.04».

Также вам потребуется установить веб-сервер Apache. Если вы хотите установить на сервере полный комплект LAMP (Linux, Apache, MySQL, PHP), следуйте указаниям обучающего модуля «Установка LAMP в Ubuntu 18.04». Если вы хотите просто установить веб-сервер Apache, пропустите шаги, относящиеся к установке PHP и MySQL.

Когда предварительные требования будут выполнены, переходите к приведенным ниже шагам.

Шаг 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 указывает, что мы создаем ключ RSA длиной 2048 бит.
• -keyout: эта строка указывает OpenSSL, где мы разместим создаваемый закрытый ключ.
• -out: данный параметр указывает OpenSSL, куда поместить создаваемый сертификат.

Как мы указывали выше, эти опции создают и файл ключа, и сертификат. Нам будет задано несколько вопросов о нашем сервере, чтобы правильно вставить информацию в сертификат.

Укажите подходящие ответы. Самая важная строка — это строка, где запрашивается обычное имя (т. е. FQDN сервера или ВАШЕ имя) . Вам нужно ввести доменное имя, связанное с вашим сервером или, что более вероятно, публичный IP-адрес вашего сервера.

В целом диалоги выглядят примерно так:

Оба созданных вами файла будут помещены в соответствующие подкаталоги в каталоге /etc/ssl .

Шаг 2 — Настройка Apache для использования SSL

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

Внесем несколько небольших изменений в нашу конфигурацию:

1. Создадим сниппет конфигурации, чтобы задать надежные параметры SSL по умолчанию.
2. Мы изменим входящий в комплект файл виртуального хоста SSL Apache, чтобы он указывал на сгенерированные нами сертификаты SSL.
3. (Рекомендуется) Мы изменим незашифрованный файл виртуального хоста, чтобы он автоматически перенаправлял запросы на шифрованный виртуальный хост.

После завершения настройки мы получим защищенную конфигурацию SSL.

Создание сниппета конфигурации Apache с надежными настройками шифрования

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

Создайте новый сниппет в каталоге /etc/apache2/conf-available . Мы назовем файл ssl-params.conf , чтобы сделать его назначение очевидным:

Для безопасной настройки Apache SSL мы используем рекомендации Реми ван Эльста на сайте Cipherli.st. Этот сайт создан для предоставления удобных настроек шифрования для популярного программного обеспечения.

Рекомендованные настройки на вышеуказанном сайте обеспечивают высокий уровень безопасности. Иногда это достигается за счет совместимости клиентских систем. Если вам требуется поддержка старых версий клиентов, вы можете использовать альтернативный список, нажав на странице ссылку «Да, мне нужны настройки шифрования для устаревшего / старого программного обеспечения». Этот список можно заменить для копируемых ниже элементов.

Выбор конфигурации в основном зависит от того, какие системы вам нужно поддерживать. Оба варианта обеспечивают высокий уровень безопасности.

Для наших целей мы скопируем предоставленные настройки полностью. Мы внесем только одно небольшое изменение. Мы отключим заголовок Strict-Transport-Security (HSTS).

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

Вставьте конфигурацию в открытый нами файл ssl-params.conf :

Сохраните файл и закройте его после завершения.

Изменение файла виртуального хоста Apache SSL по умолчанию

Теперь изменим /etc/apache2/sites-available/sl.conf , используемый по умолчанию файл виртуального хоста Apache SSL. Если вы используете другой файл серверных блоков, используйте имя этого файла в приведенных ниже командах.

Прежде чем продолжить, создадим резервную копию первоначального файла виртуального хоста SSL:

Теперь откройте файл виртуального хоста SSL для внесения изменений:

С удалением большинства комментариев содержание файла виртуального хоста по умолчанию должно выглядеть примерно так:

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

После внесения изменений ваш серверный блок должен выглядеть примерно так:

Сохраните файл и закройте его после завершения.

(Рекомендуется) Изменение файла хоста HTTP для перенаправления на HTTPS

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

Чтобы изменить файл нешифрованного виртуального хоста для перенаправления всего трафика для шифрования SSL, мы можем открыть файл /etc/apache2/sites-available/000-default.conf :

Внутри файла в блоках конфигурации VirtualHost нам нужно добавить директиву Redirect , которая должна направлять весь трафик на версию сайта с шифрованием SSL:

Сохраните файл и закройте его после завершения.

Шаг 3 — Настройка брандмауэра

Если у вас включен брандмаэр ufw в соответствии с предварительными требованиями, вам может потребоваться изменить настройки для поддержки трафика SSL . К счастью, Apache регистрирует несколько профилей ufw после установки.

Мы можем просмотреть доступные профили с помощью следующей команды:

Список должен выглядеть примерно так:

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

Если вам разрешен только обычный трафик HTTP, результаты могут выглядеть следующий образ:

Чтобы разрешить дополнительный трафик HTTPS, мы разрешим профиль «Apache Full» и удалим избыточный профиль «Apache»:

Теперь ваш статус должен выглядеть примерно так:

Шаг 4 — Активация изменений в Apache

Мы внесли изменения и настроили брандмауэр, и теперь можем включить в Apache модули SSL и заголовков, активировать наш виртуальный хост SSL и перезапустить Apache.

Мы можем активровать mod_ssl , модуль Apache SSL, и модуль mod_headers , необходимый для некоторых настроек нашего сниппета SSL, с помощью команды a2enmod :

Теперь мы можем активировать виртуальный хост SSL с помощью команды a2ensite :

Также нам нужно будет активировать файл ssl-params.conf для считывания заданных значений:

Мы активировали наш сайт и все необходимые модули. Теперь нам нужно проверить наши файлы на наличие ошибок в синтаксисе. Для этого можно ввести следующую команду:

Если проверка будет успешно пройдена, мы получим результат, выглядящий примерно так:

Первая строка — это сообщение о том, что директива ServerName не задана глобально. Если вы хотите избавиться от этого сообщения, вы можете задать для ServerName доменное имя вашего сервера или IP-адрес в каталоге /etc/apache2/apache2.conf . Это необязательно, потому что данное сообщение не наносит никакого вреда.

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

Шаг 5 — Тестирование шифрования

Теперь мы готовы протестировать наш сервер SSL.

Откройте браузер и введите https:// и доменное имя или IP-адрес вашего сервера в адресную панель:

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

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

Теперь должен открыться ваш сайт. Если вы посмотрите в адресную строку браузера, вы увидите символ замка со знаком «x». В данном случае это означает, что сертификат не удается проверить. Ваше соединение все равно шифруется.

Если вы настроили Apache для перенаправления HTTP на HTTPS, вы можете проверить правильность перенаправления функций:

Если при этом появляется такой же значок, перенаправление работает правильно.

Шаг 6 – Переключение на постоянное перенаправление

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

Откройте файл конфигурации серверного блока еще раз:

Найдите добавленную нами строку Redirect . Добавьте в эту строку атрибут permanent , который изменяет тип перенаправления с временного перенаправления 302 на постоянное перенаправление 301:

Сохраните и закройте файл.

Проверьте конфигурацию на ошибки синтаксиса:

Когда вы будете готовы, перезапустите Apache, чтобы сделать перенаправление постоянным:

Заключение

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

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.