Как выпустить самоподписанный ssl сертификат и заставить ваш браузер доверять ему

Случалось ли так, что вы понимали — необходимо добавить HTTPS в приложение, запущенное на локальном хостинге или каком-нибудь еще местном домене вроде local.my-app.com?

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

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

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

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

Важно отметить вот что: с 1 сентября 2020 года SSL-сертификаты не выдаются дольше, чем на тринадцать месяцев (397 дней). Поэтому для сертификатов, создаваемых в этой статье, мы ограничимся двенадцатью месяцами.

Источник сертификата (Certificate Authority)

1. Создайте закрытый ключ и самоподписанный сертификат

openssl req -x509 -nodes -new -sha512 -days 365 -newkey rsa:4096 -keyout ca.key -out ca.pem -subj «/C=US/CN=MY-CA»

Опционально: если необходимо, можно заменить MY-CA в CN на что-нибудь другое.

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

openssl x509 -in ca.pem -text -noout

2. Создайте файл сертификата с расширением .crt:

openssl x509 -outform pem -in ca.pem -out ca.crt

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

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

1. Создайте файл расширения x509 v3:

Следуя этому шаблону, можно добавить сколько угодно доменных имен.

Примечание: пожалуйста, обновите DNS.4, DNS.5 и DNS.6 или удалите их, если у вас не настроены никакие локальные доменные имена.

2. Создайте закрытый ключ и запрос на подпись сертификата:

openssl req -new -nodes -newkey rsa:4096 -keyout localhost.key -out localhost.csr -subj «/C=US/ST=State/L=City/O=Some-Organization-Name/CN=localhost»

Опционально: страну, штат, город и организацию можно изменять.

3. Создайте самоподписанный сертификат:

openssl x509 -req -sha512 -days 365 -extfile v3.ext -CA ca.crt -CAkey ca.key -CAcreateserial -in localhost.csr -out localhost.crt

Использование сертификата

Приложениям, обслуживающим ваш контент, понадобится доступ к файлам сертификата и закрытого ключа. Это может быть локальный веб-сервер (Apache или NGINX), локальный сервис или какой-то другой локальный инструмент, допустим, сборщик модулей DevServer.

Вот несколько примеров:

Apache

webpack-dev-server —open —https —cert /path/to/localhost.crt —key /path/to/localhost.key

Express

const https = require(«https»);const fs = require(«fs»);const express = require(«express»);// прочитайте ключиconst key = fs.readFileSync(«localhost.key»);const cert = fs.readFileSync(«localhost.crt»);// создайте экспресс-приложениеconst app = express();

Как только вы настроите обслуживающий ваше приложение инструмент на работу с вашим сертификатом, ваше приложение будет доступно по URL’у с HTTPS.

Следуя приведенному выше примеру с Express, вы можете открыть вкладку браузера по адресу https://localhost:8000 и увидеть ваш контент:

Погодите секунду! Где же сообщение «это защищенный сервер»?

Вы рассчитывали увидеть кое-что другое, но именно этого и следовало ожидать — потому что источник сертификата еще не входит в число доверенных.

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

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

MacOS — Chrome и Safari

1. Дважды кликните на корневом сертификате (ca.crt).

3. Добавьте сертификат.

4. Откройте «Keychain Access» (если еще не открыт).

5. Выделите keychain, который выбрали раньше.

6. Вы должны увидеть сертификат MY-CA (это будет имя, которое вы, как CN, дали вашему источнику сертификата).

7. Дважды кликните по сертификату.

8. Разверните «Доверять» и выберите опцию «Доверять всегда» в пункте «При использовании этого сертификата».

9. Закройте окно сертификата и введите свой пользовательский пароль (если требуется).

Windows 10 — Chrome, IE11 и Edge

1. Дважды кликните на сертификате (ca.crt).

2. Кликните на кнопку «Установить сертификат».

3. Выберите, хотите ли вы хранить его на уровне пользователя или на уровне машины.

4. Кликните «Дальше».

5. Выберите «Разместить все сертификаты в следующем хранилище».

6. Кликните «Обзор».

7. Выберите «Доверенные корневые источники сертификатов».

8. Кликните «ОК».

9. Кликните «Дальше».

10. Кликните «Завершить».

11. Если появится подсказка, кликните «Да».

Firefox

Даже после того, как вы установите доверенный источник сертификата в хранилище, Firefox все равно будет выдавать предупреждения. Этого может не случиться в Windows 10, но почти наверняка случится в macOS. Справиться с этим достаточно просто. Firefox демонстрирует вот такой экран:

Это нужно сделать всего один раз, но для каждого локального домена.

Заключение

Теперь, когда сертификат создан и доверие к нему обеспечено, вы без проблем можете посещать свой локальный домен! Обслуживание приложений стало безопасным, и вы можете спокойно продолжать разработку. Возвращаясь к примеру с Express, результат на экране будет таким:

Сайт полностью загружен, и рядом с URL в Chrome теперь отображается символ безопасного соединения.

Надеюсь, эта статья помогла вам превозмочь трудности с HTTPS.

Читайте нас в Telegram, VK и Яндекс.Дзен

Что такое самоподписанный сертификат SSL?

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

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

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

Предпосылки

Инструментарий openssl необходим для создания самозаверяющего сертификата.

Чтобы проверить, установлен ли пакет openssl в вашей системе Linux, откройте ваш терминал, введите openssl version и нажмите Enter. Если пакет установлен, система распечатает версию OpenSSL, в противном случае вы увидите нечто подобное openssl command not found .

Читать также:  К 2020 году компания должна будет получить сертификат, определяющий сотрудника в качестве фидуциария

Если пакет openssl не установлен в вашей системе, вы можете установить его, выполнив следующую команду:

  • Ubuntu и Debian
    sudo apt install openssl
  • Чентос и Федора
    sudo yum install openssl

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

Чтобы создать новый самоподписанный сертификат SSL, используйте openssl req команду:

openssl req -newkey rsa:4096 -x509 -sha256 -days -nodes -out example.crt -keyout example.key

Давайте разберем команду и разберемся, что означает каждая опция:

  • -newkey rsa:4096 — Создает новый запрос сертификата и 4096-битный ключ RSA. Значение по умолчанию составляет 2048 бит.
  • -x509 — Создает сертификат X.509.
  • -sha256 — Используйте 265-битный SHA (алгоритм безопасного хэширования).
  • -days 3650 — Количество дней для сертификации сертификата. 3650 — это 10 лет. Вы можете использовать любое положительное целое число.
  • -nodes — Создает ключ без ключевой фразы.
  • -out example.crt — Указывает имя файла, в который будет записан вновь созданный сертификат. Вы можете указать любое имя файла.
  • -keyout example.key — Задает имя файла, в который будет записан вновь созданный закрытый ключ. Вы можете указать любое имя файла.

Для получения дополнительной информации о параметрах openssl req команды посетите страницу документации OpenSSL req.

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

Введите запрашиваемую информацию и нажмите Enter.

Сертификат и закрытый ключ будут созданы в указанном месте. Используйте команду ls, чтобы убедиться, что файлы были созданы:

Это оно! Вы создали новый самозаверяющий сертификат SSL.

Всегда полезно создать резервную копию нового сертификата и ключа для внешнего хранилища.

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

Если вы хотите сгенерировать самозаверяющий SSL-сертификат без запроса какого-либо вопроса, используйте -subj параметр и укажите всю информацию о субъекте:

openssl req -newkey rsa:4096 -x509 -sha256 -days -nodes -out example.crt -keyout example.key -subj

Поля, указанные в -subj строке, перечислены ниже:

  • C= — Название страны. Двухбуквенное сокращение ISO.
  • ST= — Название штата или провинции.
  • L= — Название населенного пункта. Название города, в котором вы находитесь.
  • O= — Полное название вашей организации.
  • OU= — Организационная единица.
  • CN= — Полное доменное имя.

Вывод

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

26 июля, 2018 12:15 пп

TLS  (Transport Layer Security) и его предшественник SSL (Secure Socket Layers) – это криптографические протоколы, которые используются для защиты передачи данных в Интернете.

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

Данный мануал поможет создать самоподписанный SSL-сертификат для веб-сервера Nginx в Ubuntu 18.04.

Примечание: Самоподписанный сертификат не сможет подтвердить подлинности сервера, так как он не подписан проверенным центром сертификации (ЦС); тем не менее, такой сертификат позволит шифровать взаимодействие с веб-клиентами. Самоподписанный сертификат подходит пользователям, у которых пока что нет доменного имени. При наличии домена рекомендуется обратиться за подписью сертификата к одному из надёжных ЦС. Также можно получить бесплатный доверенный сертификат от сервиса Let’s Encrypt.

Требования

  • Сервер Ubuntu 18.04, настроенный по этому мануалу.
  • Предварительно установленный веб-сервер Nginx. Можно установить стек LEMP, одним из компонентов которого является Nginx (для этого следуйте руководству Установка стека LEMP в Ubuntu 18.04); чтобы установить только Nginx, выполните инструкции мануала Установка Nginx в Ubuntu 18.04.

Создание SSL-сертификата

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

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

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Команда задаст ряд вопросов. Рассмотрим компоненты команды подробнее:

  • openssl: базовый инструмент командной строки для создания и управления сертификатами, ключами и другими файлами OpenSSL.
  • req: эта подкоманда указывает, что на данном этапе нужно использовать запрос на подпись сертификата X.509 (CSR). X.509 – это стандарт инфраструктуры открытого ключа, которого придерживаются SSL и TLS при управлении ключами и сертификатами. То есть, данная команда позволяет создать новый сертификат X.509.
  • -x509: эта опция вносит поправку в предыдущую субкоманду, сообщая утилите о том, что вместо запроса на подписание сертификата необходимо создать самоподписанный сертификат.
  • -nodes: пропускает опцию защиты сертификата парольной фразой. Нужно, чтобы при запуске сервер Nginx имел возможность читать файл без вмешательства пользователя. Установив пароль, придется вводить его после каждой перезагрузки.
  • -days 365: эта опция устанавливает срок действия сертификата (как видите, в данном случае сертификат действителен в течение года).
  • -newkey rsa:2048: эта опция позволяет одновременно создать новый сертификат и новый ключ. Поскольку ключ, необходимый для подписания сертификата, не был создан ранее, нужно создать его вместе с сертификатом. Данная опция создаст ключ RSA на 2048 бит.
  • -keyout: эта опция сообщает OpenSSL, куда поместить сгенерированный файл ключа.
  • -out: сообщает OpenSSL, куда поместить созданный сертификат.

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

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

При использовании OpenSSL нужно также создать ключи Диффи-Хеллмана, которые нужны для поддержки PFS (совершенной прямой секретности).

Для этого введите:

Этот процесс займёт несколько минут. Ключи DH будут помещены в /etc/nginx/dhparam.pem.

Настройка Nginx для поддержки SSL

Итак, на данном этапе ключ и сертификат созданы и хранятся в каталоге /etc/ssl. Теперь нужно отредактировать настройки Nginx:

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

Расположение ключа и сертификата

Создайте новый сниппет Nginx в каталоге /etc/nginx/snippets.

Рекомендуется указать в названии файла его назначение (к примеру, self-signed.conf):

sudo nano /etc/nginx/snippets/self-signed.conf

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

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

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

Настройка SSL

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

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

Читать также:  Чем является пароль от файла архива выберите один ответ a сертификатом

sudo nano /etc/nginx/snippets/ssl-params.conf

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

Примечание: Данный список настроек подходит для более новых клиентов. Чтобы получить настройки для других клиентов, перейдите по ссылке Yes, give me a ciphersuite that works with legacy / old software.

Скопируйте все предложенные параметры. Остаётся только добавить в них DNS резолвер для upstream запросов. В руководстве для этого используется Google.

Также нужно отключить заголовок Strict-Transport-Security (HSTS). Предварительная загрузка заголовка HSTS обеспечивает повышенную безопасность, но может иметь далеко идущие последствия, если заголовок был включен случайно или некорректно. В этом мануале мы не будем включать эту опцию, но вы можете изменить это позже, если уверены, что понимаете последствия.

Скопируйте этот сниппет и вставьте его в ssl-params.conf:

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

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

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

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.bak

Затем откройте файл блока server в текстовом редакторе:

sudo nano /etc/nginx/sites-available/default

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

Ваш файл может быть составлен в другом порядке, и вместо директив root и index у вас может быть location, proxy_pass или другие пользовательские конфигурации. Это нормально, вам нужно только обновить директивы listen и включить сниппеты SSL. Этот блок нужно настроить для поддержки трафика SSL по порту 443, а затем создать новый блок server для обработки трафика по порту 80 и автоматической переадресации трафика на порт 443.

Примечание: Во время настройки рекомендуется использовать временный редирект 302. Убедившись в правильности настроек, можно включить постоянный редирект 301.

В текущем файле обновите директивы listen для поддержки порта 443 и ssl, а затем включите два новых сниппета:

Затем добавьте второй блок server в этот файл (после закрывающей фигурной скобки (}) первого блока):

Настройка брандмауэра

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

Чтобы просмотреть доступные профили, введите:

sudo ufw app list
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

Чтобы просмотреть текущие настройки брандмауэра, наберите:

sudo ufw status

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

Status: active
To                         Action      From
—                         ——      —-
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Чтобы добавить поддержку трафика HTTPS, нужно настроить профиль Nginx Full и отключить профиль Nginx HTTP.

sudo ufw allow ‘Nginx Full’
sudo ufw delete allow ‘Nginx HTTP’

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

sudo ufw status
Status: active
To                         Action      From
—                         ——      —-
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

Обновление настроек Nginx

Итак, теперь настройки веб-сервера и брандмауэра откорректированы. Перезапустите Nginx, чтобы изменения вступили в силу.

Сначала нужно проверить синтаксис на наличие ошибок.

sudo nginx -t

Если ошибок не обнаружено, команда вернёт:

Обратите внимание на предупреждение в начале. Как говорилось ранее, веб-сервер будет возвращать предупреждение в случае использования самоподписанного сертификата. Соединения всё рано шифруются правильно.

Если в синтаксисе обнаружены ошибки, исправьте их. Затем перезапустите веб-сервер:

sudo systemctl restart nginx

Тестирование шифрования

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

Поскольку сертификат был подписан самостоятельно, браузер сообщит о его ненадёжности:

Your connection is not private
Attackers might be trying to steal your information
(for example, passwords,messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

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

После этого вы получите доступ к своему сайту.

Если вы настроили два блока server для переадресации трафика HTTP на HTTPS, проверьте, работает ли переадресация:

Постоянный редирект

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

Откройте файл блока server:

sudo nano /etc/nginx/sites-available/example.com

Найдите в нём return 302 и замените значение строки на return 301.

return 301 https://$server_name$request_uri;

Проверьте синтаксис на ошибки:

Если ошибок нет, перезапустите Nginx:

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

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

27 августа, 2019 11:54 дп

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

  • openssl: базовый инструмент командной строки для создания и управления сертификатами, ключами и другими файлами OpenSSL.
  • req: эта подкоманда указывает, что на данном этапе нужно использовать запрос на подпись сертификата X.509 (CSR). X.509 – это стандарт инфраструктуры открытого ключа, которого придерживаются SSL и TLS при управлении ключами и сертификатами. То есть, данная команда позволяет создать новый сертификат X.509.
  • –x509: эта опция вносит поправку в предыдущую субкоманду, чтобы вместо запроса на подпись сертификата создать самоподписанный сертификат.
  • –nodes: пропускает опцию защиты сертификата парольной фразой. Нужно, чтобы при запуске сервер Apache имел возможность читать файл без вмешательства пользователя. Установив пароль, придется вводить его после каждой перезагрузки.
  • –days 365: эта опция устанавливает срок действия сертификата (как видите, в данном случае сертификат действителен в течение года).
  • –newkey rsa:2048: эта опция позволяет одновременно создать новый сертификат и новый ключ. Поскольку ключ, необходимый для подписания сертификата, не был создан ранее, нужно создать его вместе с сертификатом. Данная опция создаст ключ RSA на 2048 бит.
  • –keyout: эта опция сообщает OpenSSL, куда поместить сгенерированный файл ключа.
  • –out: сообщает OpenSSL, куда поместить созданный сертификат.

Настройка Apache для поддержки SSL

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

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

Местонахождение ключа и сертификата

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

Создайте новый сниппет Apache в каталоге etc/apache2/conf-available.

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

sudo nano /etc/apache2/conf-available/ssl-params.conf

Скопируйте все предложенные параметры. Единственное небольшое изменение, которое нужно внести в эти настройки – отключить заголовок Strict-Transport-Security (HSTS).

Вставьте в файл ssl-params.conf следующее:

Настройка стандартного виртуального хоста Apache

Теперь нужно настроить стандартный виртуальный хост Apache (/etc/apache2/sites-available/default-ssl.conf) для поддержки SSL.

Примечание: Если вы используете другой виртуальный хост, укажите его имя вместо /etc/apache2/sites-available/default-ssl.conf.

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

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Откройте хост в текстовом редакторе:

sudo nano /etc/apache2/sites-available/default-ssl.conf

На данный момент файл виртуального хоста выглядит примерно так (закомментированные строки опущены для удобства):

В результате файл будет иметь такой вид:

Настройка переадресации (опционально)

На данный момент сервер поддерживает и HTTP, и HTTPS. Для более надёжной защиты сервера рекомендуется отключить незашифрованный трафик HTTP.

Отредактируйте виртуальный хост, разрешающий HTTP-трафик, и настройте переадресацию. Откройте файл /etc/apache2/sites-available/000-default.conf:

sudo nano /etc/apache2/sites-available/000-default.conf

В блок VirtualHost добавьте директиву Redirect, которая будет переадресовывать весь незашифрованный трафик:

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

sudo ufw app list
Available applications:
. . .
WWW
WWW Cache
WWW Full
WWW Secure
. . .

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

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

Status: active
To                         Action      From
—                         ——      —-
OpenSSH                    ALLOW       Anywhere
WWW                        ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

Чтобы добавить поддержку трафика HTTPS, нужно включить профиль WWW Full и отключить профиль WWW.

sudo ufw allow ‘WWW Full’
sudo ufw delete allow ‘WWW’

Проверьте текущее состояние брандмауэра:

sudo ufw status
Status: active
To                         Action      From
—                         ——      —-
OpenSSH                    ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

Обновление настроек Apache

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

Включите модуль Apache для SSL, mod_ssl, и модуль mod_headers, который необходим для работы сниппета SSL:

sudo a2enmod ssl
sudo a2enmod headers

Включите подготовленный виртуальный хост:

sudo a2ensite default-ssl

Также нужно включить файл ssl-params.conf:

sudo a2enconf ssl-params

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

sudo apache2ctl configtest

Если ошибок нет, команда вернёт:

Если вы видите такой результат, вы можете перезапустить сервер. Если же в синтаксисе обнаружены ошибки, исправьте их. Затем перезапустите веб-сервер:

sudo systemctl restart apache2

Your connection is not private
Attackers might be trying to steal your information
(for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

Откройте файл виртуального хоста Apache:

Найдите ранее добавленную директиву Redirect и установите значение permanent.

Проверьте ошибки в синтаксисе:

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

5 июня, 2016 12:35 пп

LEMP Stack, Ubuntu

Данное руководство поможет создать самоподписанный SSL-сертификат для веб-сервера Nginx в Ubuntu 16.04.

  • Не- root пользователь с доступом к sudo (инструкции по созданию такого пользователя – в этой статье).
  • Предварительно установленный веб-сервер Nginx. Чтобы установить стек LEMP, одним из компонентов которого является Nginx, следуйте этому руководству; чтобы установить только Nginx, обратитесь к этому руководству.

Файлы ключа и сертификата будут помещены в каталог /etc/nginx/ssl.

Этот процесс займёт несколько минут. Ключи DH будут помещены в /etc/ssl/certs/dhparam.pem.

Для безопасной настройки SSL обратимся к рекомендациям Remy van Elst на сайте Cipherli.st. Этот сайт предназначен для распространения простых и надёжных параметров шифрования для популярного программного обеспечения. Больше параметров для Nginx можно найти здесь.

Скопируйте все предложенные параметры. Остаётся только добавить в них DNS распознаватель для восходящего канала запросов. В руководстве для этого используется Google.

Также нужно добавить параметр ssl_dhparam, чтобы настроить поддержку ключей Диффи-Хеллмана.

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

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

Теперь нужно отредактировать настройки, чтобы незашифрованные запросы HTTP были автоматически перенаправлены на HTTPS. Если вы хотите поддерживать и HTTP, и HTTPS, используйте альтернативный вариант настроек, о котором речь пойдёт ниже.

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

Ниже нужно добавить новый блок server и поместить в него оставшиеся настройки. Раскомментируйте директивы listen, которые используют порт 443. Затем добавьте директиву http2, которая отвечает за поддержку HTTP/2. После этого нужно просто выключить в файл созданные ранее сниппеты.

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

Альтернативный вариант настройки

Чтобы сайт поддерживал и HTTP, и HTTPS, используйте описанные в этом разделе настройки. Имейте в виду: такой вариант настройки использовать не рекомендуется.

В целом нужно только объединить два отдельных блока server в один блок и удалить редирект.

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

Status: active
To                         Action      From
—                         ——      —-
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

sudo ufw status
Status: active
To                         Action      From
—                         ——      —-
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

Если все настройки сервера работают должным образом, настройте постоянный редирект вместо временного.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *