Ubuntu создать свой ssl сертификат

Обновлено: 02.07.2024

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

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

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

Требования

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

Шаг 1 - Активация модуля SSL

Пакет Apache для Ubuntu 14.04 по-умолчанию поддерживает SSL . Его достаточно просто активировать. Команда для активации модуля:

После активации SSL следует перезапустить сервер для вступления в силу новых настроек:

Теперь наш веб сервер поддерживает SSL, осталось выполнить некоторые настройки.

Шаг 2 - создание подписанного сертификата SSL

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

Теперь создадим здесь ключ и сертификат одной командой:

Давайте подробно разберёмся в параметрах команды:

openssl - основной инструмент для создания и управления сертификатами, ключами, запросами на подпись и т.д. для OpenSSL
req - этот параметр задаёт запрос на подпись сертификата X.509. X.509 - стандартная структура открытого ключа, которой придерживается SSL для управления ключами и сертификатами. Нам необходим этот параметр так как мы хотим создать новый сертификат.
-x509 - этот параметр указывает на то, что мы хотим создать самостоятельно подписанный сертификат.
-nodes - указывает на то, что мы не хотим создавать кодовую фразу. При создании кодовой фразы у вас могут возникнуть проблемы при автоматическом запуске Apache, так как каждый раз придется её вводить.
-days 365 - срок действия сертификата - один год.
-newkey rsa:2048 - этот параметр указывает на одновременное создание приватный ключа и запроса на сертификат. Это необходимо, так как мы не создали приватный ключ заранее. rsa:2048 - создает RSA ключ длиной 2048 бит.
-keyout - имя файла создаваемого приватного ключа.
-out - имя файла создаваемого сертификата.

После запуска этой команды вам предстоит ответить на несколько вопросов. Наиболее важный из которых - Common Name (e.g. server FQDN or YOUR name)". Здесь следует ввести доменное имя ассоциируемое с сертификатом, или открытый IP адрес при отсутствии доменного имени.

Вопросы выглядят примерно следующим образом:

Ключ и сертификат будут созданы в каталоге /etc/apache2/ssl .

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

Теперь у нас есть сертификат и ключ и мы можем настроить Apache для использования этих файлов в файле виртуальных хостов. Вместо использования шаблона 000-default.conf мы воспользуемся шаблоном default-ssl.conf , который уже включает в себя некоторые необходимые настройки.

Откройте этот файл с правами root:

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

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

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

Шаг 4 - активация виртуального хоста с SSL

Теперь настало время включить наш виртуальный хост. Выполняем команду:

Теперь виртуальный хост, который будет служить для безопасной передачи данных, должен запуститься.

Шаг 5 - проверка

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

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

Заключение

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

Если вы собираетесь запускать проект с использованием SSL, следует задуматься над приобретением SSL сертификата от удостоверяющего центра.

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

Что такое сертификаты?

В этой инструкции мы будем иметь дело с такими видами ключей:

.pem, .crt, .cer - готовый, подписанный центром сертификации сертификат, расширения разные, но означают одно и то же. Если совсем просто, то сертификат, это подписанный открытый ключ, плюс немного информации о вашей компании;
.key - закрытый или открытый ключ;
.csr - запрос на подпись сертификата, в этом файле хранится ваш открытый ключ плюс информация, о компании и домене, которую вы указали.

А теперь рассмотрим как создать сертификат openssl, как его подписать и что для этого нужно сделать. Генерация ключей openssl - это довольно простая задача, если во всем разобраться.

Создание закрытого ключа и запроса на подпись

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

Чтобы создать закрытый ключ и запрос на подпись открытого ключа выполните такую команду:

openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

Опция -newkey указывает, что нужно создать новую пару ключей, а в параметрах мы сообщаем тип rsa и сложность 2048 байт. Опция -nodes указывает, что шифровать ключ не нужно, опция -new указывает что нужно создать запрос csr. Если у вас уже есть закрытый ключ, то вы можете создать для него csr запрос такой командой:

openssl req -key domain.key -new -out domain.csr

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

openssl genrsa -des3 -out domain.key 2048

openssl x509 -in domain.crt -signkey domain.key -x509toreq -out domain.csr

Параметр -x509toreq указывает, что нужно использовать сертификат для X509 для получения CSR. X509, это сертификаты, подписанные сами собой. Обычно сертификат подписывается другим сертификатом, а этот был подписан сам собой. Если вы получили сертификат от CA, то этот параметр не нужен.

Подпись сертификатов OpenSSL

Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:

openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt

С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:

openssl req -newkey rsa:2048 -nodes -keyout domain.key
-x509 -days 365 -out domain.crt

Или создаем самоподписанный сертификат openssl из существующего закрытого ключа без csr:

openssl req -key domain.key -new -x509 -days 365 -out domain.crt

Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL - подписать его с помощью собственного CA, центра сертификации.

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

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

Дальше нужно создать самоподписанный сертификат openssl для нашего CA:

openssl req -newkey rsa:4096 -x509 -extensions x509_ca -keyout /etc/ca/certs/ca.key -out /etc/ca/certs/ca.crt -days 3654

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

openssl ca -extensions x509_client -in

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

Просмотр сертификатов

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

openssl req -text -noout -verify -in domain.csr

Смотрим содержимое сертификата в режиме обычного текста:

openssl x509 -text -noout -in domain.crt

Проверяем действительно ли сертификат подписан нужным CA:

openssl verify -verbose -CAfile ca.crt domain.crt

Просмотр закрытого ключа:

openssl rsa -check -in domain.key

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

openssl rsa -noout -modulus -in domain.key | openssl md5
$ openssl x509 -noout -modulus -in domain.crt | openssl md5
$ openssl req -noout -modulus -in domain.csr | openssl md5

Выводы

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

Веб-протокол 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, чтобы воспользоваться их преимуществами.

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

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

После завершения настройки мы получим защищенную конфигурацию 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, чтобы они указывали на наши файлы сертификатов и ключей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

В этом руководстве мы расскажем, как при помощи Certbot получить бесплатный SSL-сертификат и использовать его в Nginx на Ubuntu 16.04. Мы также покажем, как настроить автоматическое обновление SSL-сертификата во избежание истечения его срока действия. Если у вас запущен другой веб-сервер, следуйте его документации, чтобы узнать, как использовать сертификат для вашей конфигурации.

Шаг 0. Подготовка

Перед тем, как приступить к работе, вам нужно убедиться в нескольких вещах.

У вас должен быть установлен сервер на Ubuntu 16.04, и создан пользователь (не root), для которого настроены sudo привилегии. Узнать, как это сделать, вы можете, следуя руководству по первичной настройке сервера на Ubuntu 16.04.

Старт 22 ноября, 4 месяца, Онлайн, От 35 000 до 100 000 ₽

Если все требования выполнены, приступаем к установке Certbot — клиента Let’s Encrypt.

Шаг 1. Устанавливаем Certbot

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

Для начала добавьте репозиторий:

Нажмите ENTER для подтверждения. После этого необходимо обновить пакеты:

По завершении установите Certbot, используя команду apt-get :

Теперь Certbot готов к использованию.

Шаг 2. Получаем SSL-сертификат

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

Давайте разберёмся, как использовать плагин Webroot для получения SSL-сертификата.

Использование плагина Webroot

Алгоритм работы Webroot включает в себя создание специального файла в директории /.well-known . Она размещается в корневом каталоге веб-сервера (document root) и может быть открыта сервисом Let’s Encrypt для проверки. В зависимости от ваших настроек, вам может понадобиться явно разрешить доступ к папке /.well-known .

Если вы ещё не установили Nginx, сделайте это, следуя руководству по установке Nginx на Ubuntu 16.04.

Чтобы убедиться в том, что папка доступна сервису Let’s Encrypt, внесем небольшие изменения в конфигурацию Nginx. По умолчанию файл конфигурации находится в папке /etc/nginx/sites-available/default . Мы будем использовать редактор Nano для внесения изменений:

Внутри блока server добавьте такой блок location :

Вам также стоит посмотреть, где расположен корневой каталог веб-сервера (document root), так как этот путь необходим при работе с Webroot. Если вы используете стандартный файл конфигурации, она будет расположена в /var/www/html .

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

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

Если ошибок нет, перезапустите Nginx, используя эту команду:

Примечание 1. Если в процессе вы получите ошибку вроде Failed to connect to host for DVSNI challenge , значит, вам нужно настроить файрвол вашего сервера, разрешив TCP-трафик на портах 80 и 443 .

Примечание 2. Если для вашего домена используется маршрутизация через такой DNS-сервис, как CloudFlare, вам придется временно отключить её до тех пор, пока сертификат не будет получен.

Файлы сертификата

После получения сертификата у вас должны появиться следующие файлы в PEM-кодировке:

cert.pem — сертификат вашего доменного имени;
chain.pem — цепочка сертификатов Let’s Encrypt;
fullchain.pem — объединённые cert.pem и chain.pem ;
privkey.pem — приватный (секретный) ключ вашего сертификата.

Важно запомнить расположение этих файлов, так как они будут использоваться в конфигурации вашего сервера. Сами файлы расположены в папке /etc/letsencrypt/archive . Однако Certbot создает симлинки на наиболее актуальные файлы сертификата в папке /etc/letsencrypt/live/ваше_доменное_имя/ . Так как символьные ссылки указывают на наиболее актуальные файлы сертификата, именно этот путь лучше использовать при обращении к ним.

Вы можете проверить существование файлов, используя такую команду (подставьте ваше доменное имя):

Результатом выполнения команды должны быть указанные выше файлы сертификата. Теперь вы можете настроить ваш сервер так, чтобы fullchain.pem использовался в качестве файла сертификата, а privkey.pem в качестве ключа сертификата.

Генерация ключа по алгоритму Диффи-Хеллмана

Для повышения безопасности вам необходимо сгенерировать ключ по алгоритму Диффи-Хеллмана. Для генерации ключа длиной 2048 бит используйте такую команду:

Процесс может занять несколько минут.

Шаг 3. Настраиваем TLS/SSL на веб-сервере

Теперь, когда у вас есть SSL-сертификат, необходимо настроить веб-сервер Nginx так, чтобы он начал его использовать.

Внесем некоторые изменения в нашу конфигурацию:

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

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

Создаем сниппет конфигурации для SSL-ключа и сертификата

Сперва создадим сниппет конфигурации Nginx в папке /etc/nginx/snippets .

Для правильного распознавания назначения файла назовем его ssl- , затем укажем доменное имя и в конце поставим .conf :

В этом файле необходимо установить соответствие директивы ssl_certificate файлу сертификата и ssl_certificate_key — соответствующему ключу. В нашем случае это будет выглядеть так:

Когда добавите эти строки, сохраните и закройте файл.

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

Следующим шагом мы создадим другой сниппет, определяющий некоторые настройки SSL. Это позволит Nginx подключить устойчивый «набор шифров» SSL (англ. cipher suite) и некоторые дополнительные функции, которые помогут обеспечить безопасность нашего сервера.

Прим. перев. Cipher Suite — это совокупность алгоритмов, используемых в конкретной TLS/SSL-сессии:

алгоритм выработки сессионных ключей шифрования;
алгоритм, используемый для аутентификации сервера;
непосредственно сам симметричный алгоритм шифрования трафика;
и алгоритм контроля целостности (MAC, message authentication code).

Установленные нами параметры могут быть использованы повторно для конфигураций Nginx в будущем, поэтому дадим файлу стандартное название:

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

Примечание. Предлагаемые стандартные настройки на сайте Cipherli.st обеспечивают устойчивую безопасность, но иногда это приводит к ухудшению совместимости. Если вам необходимо поддерживать более старые версии клиентов, используйте альтернативный список настроек, доступный при нажатии на значок «Yes, give me a ciphersuite that works with legacy/old software.» Составить такой список можно и вручную.

Для наших целей можно скопировать предлагаемые настройки целиком. Нам потребуется внести лишь некоторые изменения.

Сперва добавим DNS-резолвер. Используем для нашего руководства тот, что предлагает Google. Затем установим в качестве параметра ssl_dhparam указатель на файл ключа Диффи-Хеллмана, который мы сгенерировали ранее.

После внесения изменений сохраните и закройте файл.

Настраиваем конфигурацию Nginx для SSL

Теперь, когда мы подготовили сниппеты, можно обновить нашу конфигурацию Nginx и подключить SSL.

В данном руководстве мы полагаем, что вы используете стандартный файл с блоками server , расположенный в папке /etc/nginx/sites-available . Если вы используете другой файл с блоками server , замените название в представленных ниже командах.

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

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

Внутри ваш блок server , вероятно, начинается так:

Разделим конфигурацию на два отдельных блока. После первых двух директив listen добавим директиву server_name , указывающую на доменное имя вашего сервера. Затем установим перенаправление на созданный нами второй блок server . После этого закроем текущий блок:

Примечание. У вас может быть только одна директива listen , которая подключает модификатор default_server для каждой комбинации версии IP и порта. Если для выбранных портов у вас включены другие блоки server , для которых настроен default_server , вам придется удалить модификатор у одного из блоков.

После внесения изменений сохраните и закройте файл.

Если вы хотите или вынуждены разрешить и шифрованный, и нешифрованный контент, вам придётся настроить Nginx немного иначе. Так делать не стоит, но в некоторых ситуациях это может быть необходимо. По сути, мы склеим разделенные блоки server в один и уберём перенаправление:

После внесения изменений сохраните и закройте файл.

Шаг 4. Настраиваем файрвол

Если у вас включен файрвол ufw, вам необходимо обновить настройки и разрешить SSL-трафик. К счастью, Nginx регистрирует несколько профилей с ufw после установки.

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

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

Шаг 5. Подключаем изменения в Nginx

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

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

В случае успеха ваш результат должен выглядеть следующим образом:

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

Вы можете использовать инструмент Qualys SSL Labs Report, чтобы посмотреть оценку конфигурации вашего сервера:

Такая настройка SSL должна показать рейтинг A+.

Шаг 6. Настраиваем автоматическое обновление

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

Для запуска проверки ежедневных обновлений мы будем использовать Cron — стандартный системный сервис для запуска повторяющихся задач. Задачи Cron указываются в файле под названием crontab :

Вставьте следующую строчку в конец файла, затем сохраните и закройте его:

Часть строчки 15 3 * * * означает «запускай следующую команду в 3:15 ночи ежедневно». Вы можете выбрать любое время.

Команда renew для Certbot проверит все сертификаты, установленные в системе, и обновит каждый, срок использования которого истекает менее, чем через 30 дней. Ключ --quiet говорит Certbot’у ничего не выводить и не ждать ввода от пользователя. --renew-hook "/bin/systemctl reload nginx" перезагрузит Nginx, чтобы он использовал новые файлы сертификата, но только в случае, если произошло обновление.

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

Заключение

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

Читайте также: