Введение
Let’s Encrypt — центр сертификации, предоставляющий бесплатные криптографические сертификаты X.509 для TLS-шифрования (HTTPS). Процесс выдачи сертификатов полностью автоматизирован.
Проект Let’s Encrypt создан для того, чтобы большая часть интернет-сайтов смогла перейти к шифрованным подключениям (HTTPS). В отличие от коммерческих центров сертификации, в данном проекте не требуется оплата, переконфигурация веб-серверов, использование электронной почты, обработка просроченных сертификатов, что делает процесс установки и настройки TLS-шифрования значительно более простым.
Устанавливаем Certbot на NGINX
Certbot — это официальный клиент для Let’s Encrypt, который позволяет запрашивать SSL сертификаты с помощью командной строки. Официальную документацию можно почитать на сайте: https://certbot.eff.org/docs/.
Установка Certbot в Ubuntu:
Далее устанавливаем сертификаты и конвертируем виртуальные хосты в HTTPS:
В интерфейсе командной строки нас попросят:
- ввести адрес электронной почты,
- подтвердить согласие с Условиями обслуживания,
- указать домены для использования HTTPS (он определяет список, используя строки server_name в вашей конфигурации Nginx),
- перенаправить HTTP на HTTPS (рекомендуется).
В результате, мы получаем:
- http://first.com редиректит на https://first.com
- http://second.com редиректит на https://second.com
- http://www.first.com редиректит на https://www.first.com
- http://www.second.com редиректит на https://www.second.com
- https://first.com и https://www.first.com загружаются с папки from /var/www/first
- https://second.com и https://www.first.com загружаются с папки /var/www/second
В чём ещё отличия от Apache
Документация. У Apache документации, форумов и примеров гораздо больше, потому что проект начался на 7 лет раньше и все материалы сразу были на английском — стандартном языке для всех программистов.
Nginx появился позже и в России, поэтому почти вся документация изначально была на русском. Из-за этого разработчикам из других стран было трудно использовать Nginx, но со временем ситуация выровнялась: сейчас проект ведётся одновременно на русском и на английском языках.
Работа с модулями. В Apache всё просто: прописал название модуля и веб-сервер сразу его подгрузил и начал использовать. Не нужно — выгрузил, тоже на ходу. Это позволяет очень гибко настраивать поведение сервера в разные моменты времени.
Чтобы добавить модули в Nginx, их нужно выбрать заранее и скомпилировать вместе с ядром сервера. С одной стороны, это неудобно: нужно на старте чётко представлять, что будет делать сервер и в каких ситуациях. Но с другой — это повышает безопасность: не получится на лету подключить какой-то неизвестный и непроверенный модуль, в котором будет дыра в безопасности.
Конфигурация и настройка. Apache управляется через служебные файлы, в которые он постоянно заглядывает, например .htaccess. Это снова гибкость и возможность очень тонкой настройки поведения для каждой папки и запроса. Но Apache каждый раз тратит время на такие чтения и проверки, а когда запросов много, то это становится критично. Ещё нужно просмотреть все папки, к которым идёт запрос, а это тоже время.
Nginx работает иначе: всё хранится в одном конфигурационном файле. Этот файл отвечает за настройки всего сервера, и Nginx точно знает, где его быстро найти. Это более безопасно для работы сервера: никто не сможет положить в папку свой файл .htaccess, прописать в нём чёрт-те что и сломать работу всего сервера.
2: Настройка брандмауэра и поддержка HTTPS-трафика
Если вы уже настроили брандмауэр на своем сервере, вы должны убедиться, что он поддерживает доступ HTTPS (через порт 443). Если вы еще не настроили брандмауэр, вы можете сделать это сейчас.
Откройте файл rc.conf, который находится в каталоге /etc/:
Этот файл сообщает FreeBSD, какие серверы следует автоматически запускать вместе с сервером. В верхней части файла добавьте следующие выделенные строки:
Эти директивы делают следующее:
- firewall_enable=”YES” загружает брандмауэр во времы загрузки сервера.
- firewall_type=”workstation”: FreeBSD предоставляет несколько типов брандмауэров по умолчанию, каждый из которых имеет несколько разные конфигурации. Брандмауэр workstation будет защищать этот сервер только с помощью stateful правил.
- firewall_myservices=”22 80 443″: в этой директиве можно перечислить все необходимые TCP-порты. В данном случае брандмауэр открывает порты 22, 80 и 443 (SSH, HTTP и HTTPS соответственно).
- firewall_allowservices=”any”: позволяет любому IP-адресу взаимодействовать с сервером через порты, указанные в директиве firewall_myservices.
После добавления этих строк сохраните файл и закройте редактор (нажмите CTRL+C, наберите exit, а затем нажмите Enter).
Затем запустите сервис брандмауэра ipfw с помощью следующей команды:
Настроив брандмауэр, вы можете запустить Certbot и получить сертификаты.
Сценарии настройки
В реальной жизни настройки могут быть несколько сложнее, чем приведенные здесь или в официальной документации. Рассмотрим несколько примеров, что может понадобиться настроить при балансировке.
1. Backend на https
Предположим, что наши внутренние серверы отвечают по SSL-каналу. Таким образом, нам нужно отправлять запрос по порту 443. Также схема проксирования должна быть https.
Настройка сайта:
server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}
* обратите внимание на 2 момента:
- Мы в схеме подключения proxy_pass указали https. В противном случае при подключении NGINX будет возвращать ошибку 400.
- Мы задали дополнительные опции proxy_set_header, которых не было в примерах выше.
Настройка upstream:
upstream dmosk_backend {
server 192.168.10.10:443;
server 192.168.10.11:443;
server 192.168.10.12:443;
}
* в данном примере мы указали конкретный порт, по которому должно выполняться соединение с бэкендом. Для упрощения конфига дополнительные опции упущены.
2. Разные бэкенды для разных страниц
Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.
Настройка сайта:
server {
…
location /page1 {
proxy_pass http://backend1;
}
location /page2 {
proxy_pass http://backend2;
}
…
}
* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.
Настройка upstream:
upstream backend1 {
server 192.168.10.10;
server 192.168.10.11;
}
upstream backend2 {
server 192.168.10.12;
server 192.168.10.13;
}
* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.
3. На другой хост
Может быть необходимым делать обращение к внутреннему ресурсу по другому hostname, нежели чем будет обращение к внешнему. Для этого в заголовках проксирования мы должны указать опцию Host.
Настройка сайта:
server {
…
location / {
proxy_pass https://dmosk_backend;
proxy_set_header Host internal.domain.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
…
}
* в данном примере мы будем проксировать запросы на бэкенды, передавая им имя хоста internal.domain.com.
4. TCP-запрос
Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.
Настройка сайта:
server {
listen 5432;
proxy_pass tcp_postgresql;
}
* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.
Настройка upstream:
upstream tcp_postgresql {
server 192.168.10.14:5432;
server 192.168.10.15:5432;
}
* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.
5. UDP-запрос
Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.
Настройка сайта:
server {
listen 53 udp;
proxy_pass udp_dns;
proxy_responses 1;
}
* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.
Настройка upstream:
upstream udp_dns {
server 192.168.10.16:53;
server 192.168.10.17:53;
}
* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.
Настроим nginx
Исходим из того что у нас на 80 порту нет сайтов, требующих сертификатов, а вся работа по переадресации на HTTPS делается в одном месте.
Чтобы не переносить сервер приложений (например, Apache) на другой порт, отличный от 80-го по умолчанию, будем cлушать только на внешнем IP.
В случае переезда с сервера на сервер конфиг выше одновременно. Аналогичную схему можно использовать если постоянно используются два сервера.
Проверим, что требуемые файлы будут видны сертификационному центру.
Команда должна вывести .
Если для вашего сервера есть записи AAAA, то он должен по ним отвечать. Проверим и это.
Проверочный файл удалим чтобы не смущать Certbot.
Шаг 4 — Получение сертификата SSL
Certbot предоставляет широкий выбор способов получения сертификатов SSL с помощью плагинов: Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется. Для использования этого плагина введите следующую команду:
Эта команда запускает с плагином , используя опцию для указания доменных имен, для которых мы хотим использовать сертификат.
Если это первый запуск , вам будет предложено указать адрес эл. почты и принять условия обслуживания. После этого свяжется с сервером Let’s Encrypt и отправит запрос с целью подтвердить, что вы контролируете домен, для которого запрашиваете сертификат.
Если это будет подтверждено, запросит у вас предпочитаемый вариант настройки HTTPS:
Выберите желаемый вариант, после чего нажмите . Конфигурация будет обновлена, а Nginx перезагрузится для получения новых настроек. Затем завершит работу и выведет сообщение, подтверждающее завершение процесса и указывающее место хранения ваших сертификатов:
Ваши сертификаты загружены, установлены и активированы. Попробуйте перезагрузить веб-сайт с помощью и посмотрите на индикатор безопасности в браузере. Теперь в браузере должен отображаться символ замка, означающий, что сайт защищен надлежащим образом. Если вы протестируете свой сервер с помощью теста SSL Labs Server Test, он получит оценку A.
В заключение протестируем процесс обновления.
Рейтинг А+ для SSL сертификатов
В NGINX конфигах наших сайтов содержатся следующие строки:
Более сильные настройки используют OCSP Stapling (сшивание OCSP), поэтому каждому виртуальному хосту будет нужен ssl_trusted_certificate.
Добавьте эту строку (используя имя папки, которую Certbot создал для вашего домена) после строки ssl_certificate_key:
Теперь давайте отредактируем общие настройки SSL в /etc/letsencrypt/options-ssl-nginx.conf. Скорее всего, они выглядит так:
Заменяем содержимое файла на:
Теперь перезапустите Nginx и снова проверяем домен с помощью SSL Labs. Должен получиться рейтинг А+. О том, почему я больше люблю Nginx, а не Apache, читаем тут: NGINX или Apache?
Правильный сертификат
Под этим подразумевается выполнение двух условий:
- Сертификат должен быть выпущен доверенным центром.
- Сертификат должен быть выдан для домена, к которому идет подключение.
Доверенный центр
Есть список центров сертификации, внесенные в общий реестр доверенных узлов, которые могут выпускать ключи безопасности. Данным центрам по умолчанию доверяют все основные операционные системы.
Для получения сертификата от правильного центра, необходимо за него заплатить или получить бесплатно от Let’s Encrypt. Купить сертификат можно у большинства хостеров или регистраторов доменных имен. Для получения бесплатного сертификата можно воспользоваться инструкцией Получение бесплатного SSL сертификата Let’s Encrypt.
И наоборот, сертификат может быть выпущен не доверенным центром или локально на компьютере (самоподписанный). В таком случае мы получим ошибку при проверке подлинности.
Сертификат для домена
Заказывая сертификат, мы обязательно указываем, для какого доменного имени его будем использовать. Это обязательное требование. Например, если мы хотим настроить SSL-подключение к узлу security.dmosk.ru, то необходимо указывать именно это имя при заказе ключа безопасности. В противном случае, браузер будет выдавать нам ошибку, что сертификат выдан для другого узла.
Также мы можем заказать сертификат типа wildcard — он применим к домену и все его поддоменам. Например, в нашем случае мы можем заказать ключ для *.dmosk.ru — он будет применять для любого доменного имени 3-го уровня с корнем dmosk.ru.
4: Получение SSL-сертификата
Certbot предлагает несколько способов получения SSL-сертификата с помощью различных плагинов. Плагин для Nginx автоматически перенастраивает Nginx и обновляет его настройки в случае необходимости.
Эта команда запустит certbot с плагином –nginx, а флаг –d позволяет задать доменные имена, для которых предназначен сертификат.
Если вы запускаете certbot впервые, клиент запросит ваш электронный адрес и предложит принять условия использования. После этого certbot подключится к серверу Let’s Encrypt и начнет проверку, чтобы убедиться, что у вас есть права на домен, для которого создается сертификат.
Если проверка пройдет успешно, certbot предложит выбрать параметры HTTPS:
Выберите подходящий вам вариант и нажмите Enter. Конфигурация обновится, веб-сервер Nginx будет перезагружен. В конце настройки certbot сообщит, что процесс прошел успешно и скажет, где лежат файлы сертификата.
Сертификаты загружены на сервер, установлены и настроены
Попробуйте перезапустить сайт, используя протокол https://, и обратите внимание на индикатор безопасности в браузере. Обычно если сайт защищен шифрованием, браузер показывает значок зеленого замочка в адресной строке
Однако если вы протестируете сайт с помощью SSL Labs Server Test, вы получите оценку В из-за слабых параметров Диффи-Хеллмана. Исправьте их, чтобы получить А.
Доступ к файловой базе 1с через интернет в браузере
Теперь перемещаемся на виртуальную машину с nginx. Предварительно не забудьте добавить dns запись в каком-то домене, по которой вы будете ходить в базу через интернет. Она нам нужна, чтобы выпустить бесплатный tls сертификат, чтобы ходить в базу по https. Я не буду привязываться к какой-то конкретной операционной системе и рассказывать, как все делать именно в ней. Систему выбирайте на свой вкус. Настройка будет одинаковой. Нам нужны будут в системе 2 пакета: nginx и certbot. Установите их:
# yum install nginx certbot
или
# apt install nginx certbot
На данную виртуальную машину должны быть проброшены 80 и 443 порты с внешнего ip адреса. Как это будет сделано, зависит от ваших сетевых настроек. В случае с proxmox я настраиваю подобный проброс с самого хоста с помощью iptables. Пример настройки iptables читайте в отдельной статье. Там есть и про проброс. Не буду на этом задерживаться в статье про 1С.
Теперь нам нужно получить сертификат. Для этого запускайте в консоли certbot и следуйте инструкциям. Перед этим остановите nginx. Для быстрого получения сертификата certbot предлагает временно запустить свой веб сервер на 80-м порту.
# systemctl stop nginx # certbot certonly
Подробно получение сертификата let’s encrypt с помощью certbot я рассматриваю в статье про . Результатом работы certbot должны быть tls сертификаты в директории /etc/letsencrypt/live. Используем их в настройке виртуального хоста nginx для публикации баз 1С. Создаем в директории /etc/nginx/conf.d/ конфиг 1c.site.ru.conf примерно следующего содержания. Взял его с рабочего сервера.
server {
listen 443 ssl http2;
server_name 1c.site.ru;
access_log /var/log/nginx/1c-access.log;
error_log /var/log/nginx/1c-error.log;
ssl_certificate /etc/letsencrypt/live/1c.site.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/1c.site.ru/privkey.pem;
location /.well-known/acme-challenge/ {
root /tmp;
}
location / {
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/htpasswd.1c;
proxy_pass http://10.10.10.11:80;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto https;
}
}
server {
listen 80;
server_name 1c.site.ru;
return 301 https://1c.site.ru$request_uri;
}
В данном случае 10.10.10.11 — локальный ip адрес виртуальной машины с windows, где опубликована база 1С через apache. Доступ к 1С сразу же закрыт отдельным паролем и механизмом веб сервера auth basic. Создадим файл с именем пользователя и паролем, указанным в конфиге.
# htpasswd -c /etc/nginx/htpasswd.1c user1c
Если у вас нет в системе утилиты htpasswd, то установите пакет httpd-tools. Она из него. user1c — имя пользователя. Пароль вам предложат задать в консоли.
Теперь можно запускать nginx и проверять доступ к базе 1с по https с дополнительной авторизацией. Так как в конфиге nginx настроен proxy_pass всех запросов через location / , то на самой виртуалке с 1С вы можете публиковать сколько угодно баз через алиасы, например /buh3, /zup3 и т.д. Все они будут автоматом направляться с nginx на apache. При этом на самом nginx конфигурацию менять не придется.
Вот и все. Можно относительно безопасно выставлять такую конструкцию в интернет. В случае необходимости можно настроить fail2ban, если кто-то надумает перебирать пароли или просто выполнять непонятные запросы к веб серверу с опубликованными базами. При желании в том же nginx с помощью директив allow и deny можно ограничить доступ к виртуальному хосту с базами на уровне ip адресов. Это на случай, если не умеете делать то же самое на фаерволе. В nginx проще и быстрее.
Не забудьте настроить автоматическое обновление tls сертификатов. Как это сделать, я рассказываю в статье с настройкой web сервера. Ссылку на нее я дал выше.
4: Автоматическое обновление сертификатов Certbot
Сертификаты Let’s Encrypt действительны только в течение девяноста дней. Это должно побудить пользователей автоматизировать процесс продления сертификата. В этом разделе вы узнаете, как автоматизировать обновление сертификата с помощью задач cron
Прежде чем настроить автоматическое обновление, важно убедиться, что вы можете правильно обновлять сертификаты
Чтобы протестировать процесс обновления, вы можете запустить сухой прогон certbot:
Если команда не вернула ошибок, вы можете запланировать ее запуск в crontab.
Это откроет новый файл crontab. Добавьте в файл новую строку, которая будет запускать команду certbot renew дважды каждый день – в полдень и полночь. Команда certbot renew проверяет, скоро ли истекает срок действия сертификатов в системе, и пытается их обновить, если это необходимо.
Обратите внимание: поскольку команда crontab -e начинается с sudo, эта операция будет выполняться как root, так как для запуска certbot требуются привилегии суперпользователя. Если процесс автоматического обновления не срабатывает, Let’s Encrypt отправит сообщение на указанный вами адрес электронной почты, предупредив вас о завершении срока действия вашего сертификата
Если процесс автоматического обновления не срабатывает, Let’s Encrypt отправит сообщение на указанный вами адрес электронной почты, предупредив вас о завершении срока действия вашего сертификата.
Что такое SSL-сертификат и зачем он нужен?
SSL-сертификат (TLS-сертификат) — это специальный цифровой документ, который связывает между собой криптографический ключ и информацию о сайте, для которого он был выпущен. Наличие SSL-сертификата, выпущенного доверенным центром сертификации является обязательным условием для установления безопасного соединения между сервером и клиентами по протоколу HTTPS.
До недавнего времени, практически все центры сертификации выпускали SSL-сертификаты на платной основе. При этом существует несколько разновидностей таких сертификатов, различающихся степенью глубины проверки данных о владельце сайта. Из-за того, что такие SSL-сертификаты являлись платными, их достаточно редко использовали для небольших сайтов, домашних страниц, личных блогов и т.п. В результате, большая часть сайтов в интернете не использовала защищенные протоколы для связи с клиентами.
К счастью, на текущий момент, благодаря Let’s Encrypt, у владельцев сайтов появилась возможность совершенно и автоматически выпускать SSL-сертификат для своего сайта и перейти на использование защищенного протокола HTTPS.
Let’s Encrypt — некоммерческий центр сертификации, у которого можно получить бесплатный SSL‑сертификат сроком действия в 90 дней. Для получения такого сертификата необходимо подтвердить факт владения доменом с использованием протокола аутентификации ACME (Automated Certificate Management Environment), согласно которому к веб-серверу, запросившему выпуск сертификата, производится серия запросов для валидации домена. После выполнения этой процедуры клиенту выдается SSL-сертификат и приватный ключ, которые необходимо передать своему веб-серверу для перехода на работу по протоколу HTTPS.
Мы подготовили простые инструкции, которые позволят вам выпустить бесплатный SSL-сертификат и настроить его автоматическое обновления для веб-серверов Nginx, Apache и панели управления VestaCP, в зависимости от того, что вы используете на своем виртуальном сервере.
Настройка клиента Let’s Encrypt
Установите клиент Let’s Encrypt:
emerge -a app-crypt/certbot
Выполните регистрацию Let’s Encrypt ACME (автоматизированная среда управления сертификатами) аккаунта, указав почтовый адрес, на который в будущем будут приходить важные сообщения:
Saving debug log to /var/log/letsencrypt/letsencrypt.log ------------------------------------------------------------------------------- Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about EFF and our work to encrypt the web, protect its users and defend digital rights. ------------------------------------------------------------------------------- (Y)es/(N)o: No IMPORTANT NOTES: - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
После этого в каталоге будет создана инфраструктура для управления сертификатами (хранения, обновления, отзыва, удаления).
Обзор
tree /etc/letsencrypt
/etc/letsencrypt/
├── accounts
│ └── acme-v01.api.letsencrypt.org
│ └── directory
│ └── 091f17d3f1d16083e1f0e70b463452cc
│ ├── meta.json
│ ├── private_key.json
│ └── regr.json
└── renewal-hooks
├── deploy
├── post
└── pre
8 directories, 3 files
5: Проверка автоматического обновления сертификата
Сертификаты Let’s Encrypt действительны только в течение девяноста дней. Потому пользователи должны автоматизировать процесс продления сертификата. Установленный вами пакет certbot позаботится об этом с помощью таймера systemd. Он запускается два раза в день и автоматически обновляет сертификат, срок действия которого истекает через тридцать дней.
Чтобы проверить статус таймера, введите:
Чтобы протестировать процесс обновления сертификата, запустите сухой прогон:
Если вы не видите ошибок, все настроено правильно. При необходимости Certbot обновит ваши сертификаты и перезагрузит Nginx, чтобы активировать изменения. Если процесс автоматического обновления не срабатывает, Let’s Encrypt отправит сообщение на указанный вами адрес электронной почты, предупредив вас о завершении срока действия вашего сертификата.
Получение SSL-сертификата Let’s Encrypt
Чтобы получить сертификат SSL для нашего домена, мы собираемся использовать плагин Webroot, который работает путем создания временного файла для проверки запрашиваемого домена в каталоге . Сервер Let’s Encrypt отправляет HTTP-запросы к временному файлу, чтобы убедиться, что запрошенный домен разрешается на сервер, на котором работает certbot.
Чтобы упростить мы собираемся отобразить все HTTP-запросы для в один каталог .
Следующие команды создадут каталог и сделают его доступным для записи для сервера Nginx.
Чтобы избежать дублирования кода, создайте следующие два фрагмента, которые мы собираемся включить во все наши файлы блоков сервера Nginx.
Откройте свой текстовый редактор и создайте первый фрагмент, :
/etc/nginx/snippets/letsencrypt.conf
/etc/nginx/snippets/ssl.conf
После создания фрагментов откройте блок сервера домена и фрагмент как показано ниже:
/etc/nginx/sites-available/example.com.conf
Чтобы включить новый файл блока сервера, нам нужно создать символическую ссылку из файла в каталог с поддержкой , который Nginx читает во время запуска:
Перезапустите сервис Nginx, чтобы изменения вступили в силу:
Теперь вы можете запустить Certbot с подключаемым модулем webroot и получить файлы сертификатов SSL, выполнив:
Если сертификат SSL получен успешно, certbot напечатает следующее сообщение:
Теперь, когда у вас есть файлы сертификатов, вы можете отредактировать блок сервера домена следующим образом:
/etc/nginx/sites-available/example.com.conf
В приведенной выше конфигурации мы форсируем HTTPS и перенаправляем с www на версию без www.
Перезагрузите службу Nginx, чтобы изменения вступили в силу:
5: Автоматическое обновление сертификата
Сертификаты Let’s Encrypt действительны в течение 90 дней, но во избежание ошибок их рекомендуется обновлять каждые 60 дней. На момент написания статьи клиент не оборудован функцией автоматического обновления сертификатов. Этот процесс можно выполнить вручную, просто запустив клиент Let’s Encrypt с использованными ранее параметрами.
Надёжный способ обеспечить своевременное обновление сертификата – это демон cron.
Вместо плагина Standalone используйте плагин Webroot; он позволяет проверить домен сервера, не останавливая веб-сервер. Плагин Webroot добавляет скрытый файл в document root веб-сервера, который необходим Let’s Encrypt CA для подтверждения домена.
Использование плагина Webroot
Плагин Webroot помещает специальный файл в каталог ./well-known в главном каталоге веб-сервера. После этого Let’s Encrypt может открыть этот файл, чтобы подтвердить домен. В зависимости от настроек сервера вам может понадобиться явно разрешить доступ к каталогу ./well-known.
Чтобы центр сертификации Let’s Encrypt смог получить доступ к каталогу, нужно изменить настройки Nginx.
В блок server для ssl добавьте следующий код:
Также можно уточнить путь к root-каталогу в директиве root. Этот путь необходим плагину Webroot; по умолчанию это каталог /usr/share/nginx/html.
Сохраните и закройте файл.
Теперь можно использовать плагин Webroot для обновления сертификата. Указать доменные имена можно при помощи опции –d.
После этого нужно перезапустить Nginx, чтобы получить доступ к обновлённому сертификату.
Конфигурационный файл Let’s Encrypt
Чтобы упростить процесс обновления Let’s Encrypt, создайте конфигурационный файл:
Откройте файл для редактирования:
Файл должен выглядеть так (закомментированные строки опущены):
Можно не указывать домен в команде, а просто использовать конфигурационный файл Let’s Encrypt для автоматического внесения домена в команду. Для обновления сертификата можно использовать следующую команду:
Скрипт для обновления сертификата
Чтобы автоматизировать процесс обновления сертификата, используйте скрипт оболочки, который будет отслеживать срок действия сертификата и обновлять его за 30 дней до истечения этого срока. Скрипт будет запускаться раз в неделю. Таким образом, в случае сбоя cron у вас будет в запасе 30 дней, чтобы снова попытаться обновить сертификат.
Загрузите скрипт и сделайте его исполняемым; предварительно можно просмотреть его содержимое.
Скрипт le-renew-webroot использует домен в качестве аргумента. Если сертификат не нуждается в обновлении, скрипт просто сообщит, сколько дней осталось до истечения срока действия сертификата.
Примечание: Скрипт не запустится, если файла /usr/local/etc/le-renew-webroot.ini не существует. Также нужно убедиться, что в начале конфигурационного файла и в начале сертификата (при его создании) был указан один и тот же домен.
Поскольку текущий сертификат был создан только что, у скрипта нет необходимости обновлять его, и он просто сообщит, сколько дней осталось до истечения срока действия сертификата:
После этого нужно отредактировать crontab и добавить в таблицу новую команду, которая будет запускаться раз в неделю.
Добавьте в файл следующую строку:
Сохраните и закройте файл. Теперь cron будет запускать команду le-renew-webroot каждый понедельник в 2:30 ночи, а вывод команды будет помещён в лог /var/log/le-renewal.log.
Примечание: Больше информации о работе cron можно получить в статье «Автоматизация задач с помощью cron».
Обновление сертификата
Если планируется использовать сертификат SSL от Let’S Encrypt более 90 дней, его придется систематически обновлять. И делать это рекомендуется заранее, минимум за 30 дней до истечения срока действия. Иначе возникают риски временной неработоспособности протокола SSL, когда сайт перестает открываться по прежним ссылкам (браузеры предупреждают об ошибке).
Выполняется процедура обновления командой:
$ certbot renew
После ее ввода будут проверены все ранее выпущенные и установленные в системе сертификаты и заново созданы те, по которым сроки подходят к концу. Если хочется настроить автоматический перевыпуск SSL, нужно ввести команду cron:
$crontab -e 30 2 * * 1 /usr/bin/certbot renew >> /var/log/renew-ssl.log
В таком виде она каждый понедельник в 2:30 будет выполнять проверку актуальности всех SSL и записывать результат в файл с указанным названием.
1: Установка Certbot
Сначала нужно установить на сервер пакет Certbot.
Certbot находится в активной разработке, поэтому пакеты Certbot, предоставляемые репозиторием Ubuntu, очень быстро устаревают. Тем не менее, разработчики Certbot поддерживают свой репозиторий программ для Ubuntu с обновленными версиями, поэтому вместо стандартного можно использовать этот репозиторий.
Сначала добавьте новый репозиторий.
Нажмите Enter. Обновите индекс пакетов:
Установите пакет Certbot для Nginx:
Клиент Certbot готов к работе. Теперь нужно проверить некоторые параметры Nginx, чтобы настроить SSL для Nginx.
Nginx + Apache = ❤️
Может показаться, что Nginx и Apache воюют друг с другом за долю рынка, но на самом деле они отлично работают вместе:
- Ставим Nginx и Apache на один сервер.
- Настраиваем Apache на обработку запросов на динамические страницы. Самый частый пример такого запроса — отдать страницу на PHP-движке Водрпресса.
- Настраиваем Nginx, чтобы он обрабатывал все простые запросы и отдавал уже готовые статические страницы, которые запрашивают чаще всего.
- Также говорим, чтобы Nginx обрабатывал всю остальную статику: отдавал, если нужно, отдельно файлы, картинки, музыку и прочее, что имеет постоянный адрес и содержимое.
- А всё остальное, что нужно собирать динамически, — перенаправляем на Apache.
Заключение
Вы научились создавать базовый проксирующий сервер Nginx с поддержкой сертификата Let’s Encrypt, освоили настройку секции upstream Nginx, которая позволяет балансировать нагрузку между несколькими серверами, познакомились с директивой балансировщика ip_hash, предназначенной для реализации липкой балансировки.
Вам могут быть интересны следующие статьи:
- Как установить сервер WordPress с Nginx, PHP-FPM и MariaDB и сертификатом Let’s Encrypt в Debian Linux 9 (Stretch)
- Как установить сервер WordPress с Nginx, PHP-FPM и MariaDB и сертификатом Let’s Encrypt в Ubuntu Linux 18.04
- Защита, оптимизация и повышение производительности сайта с помощью CDN CloudFlare
Выводы и советы
Чтобы интернет-провайдер не смог получить конфиденциальную информацию пользователей, рекомендуется посещать интернет-ресурсы, использующие защищенный протокол (HTTPS), к примеру, https://primmmer.com. В таком случае интернет-провайдер будет знать исключительно:
- IP-адрес сервера;
- когда пользователь подключился к сервису;
- объем пользовательского трафика.
Важно! Каких-либо других данных интернет-провайдер не узнает, так как все данные будут зашифрованы. Подводя итоги, следует заметить, что вряд ли кому-то захочется заморачиваться ради пароля и логина обычного пользователя
Попытки украсть пароль слишком существенных ресурсов и явно того не стоят. На данный момент все серьезные сервисы и сайты работают по защищенным протоколам. Перехватом трафика нельзя определить пароль от личного кабинета банка, почты, социальной сети, финансовых и прочих площадок. Если по зарез нужно обезопасить доступ к площадкам не использующим протоколы с шифрованием (HTTP): , тогда придется воспользоваться надежным сервисом, предоставляющим услугу VPN соединения. В этом случае перехватить трафик на стороне провайдера будет не возможно
Подводя итоги, следует заметить, что вряд ли кому-то захочется заморачиваться ради пароля и логина обычного пользователя. Попытки украсть пароль слишком существенных ресурсов и явно того не стоят. На данный момент все серьезные сервисы и сайты работают по защищенным протоколам. Перехватом трафика нельзя определить пароль от личного кабинета банка, почты, социальной сети, финансовых и прочих площадок. Если по зарез нужно обезопасить доступ к площадкам не использующим протоколы с шифрованием (HTTP): , тогда придется воспользоваться надежным сервисом, предоставляющим услугу VPN соединения. В этом случае перехватить трафик на стороне провайдера будет не возможно.
АРАлиса Рукинаавтор
