Введение
Речь пойдет про типовой почтовый сервер, настроенный самостоятельно на базе популярных бесплатных компонентов — Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim на CentOS 8. В качестве бэкенда для web сервера там используется apache, так что получать сертификаты будем с его помощью.
В ситуации с непубличным почтовым сервером нет принципиальной необходимости использовать подтвержденный сертификат. Вы запросто можете выпустить свой самоподписаный и использовать его. Пользователям достаточно будет подтвердить, что они доверяют этому сертификату и проблем не будет.
Тем не менее, последнее время наблюдается тенденция по выдавливанию самоподписанных сертификатов из обращения. Некоторый софт напрочь отказывается им доверять, не оставляя возможность пользователям это исправить. Вместо того, чтобы бороться с софтом, я предлагаю вам настроить всем известные сертификаты от let’s encrypt. К тому же сделать это относительно просто.
Демонстрационный Upstream-сервер
Для демонстрации будем использовать тривиальный HTTP-сервер, реализованный на Python:
sudo yum install -y nano python36 python36 -m http.server <PORT> --bind 127.0.0.1
Эта команда создает тривиальный HTTP-сервер, который просто выводит структуру каталога, в котором запущен. Вы можете запустить его на локальной машине, например, на 8000 порту и проверить его работу через браузер или curl:
curl http://localhost:8000/
Для целей урока на сервере, где будет настраиваться Nginx, мы так же запустим два сервера — один на порту 8081, второй на порту 8082.
Будем использовать различные каталоги, чтобы нагляднее видеть как меняется поведение. Эти серверы не будут доступны извне, но будут использоваться в качестве Upstream-серверов, между которых будет распределять трафик Nginx:
cd /tmp; python36 -m http.server 8081 --bind 127.0.0.1 & cd /usr; python36 -m http.server 8082 --bind 127.0.0.1 &
Обратите внимание на символ ‘&‘ в конце строки — это означает, что процесс будет запущен в фоновом режиме. Вы не должны закрывать терминал, в котором запустили эти процессы до окончания урока
Проверьте работоспособность обоих серверов с помощью curl, соединившись с ними:
curl http://localhost:8081/ curl http://localhost:8082/
Проверка сертификата ssl/tls в почтовом сервере
Способов проверить сертификат в почтовом сервере множество. Например, у меня есть статья, где я настраиваю мониторинг сертификатов с помощью Zabbix. Там же есть примеры и для почтового сервера. Вот так с помощью openssl в консоли сервера можно посмотреть текущие сертификаты.
# openssl s_client -starttls smtp -connect mail.site.ru:25 | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2
Это самый простой и быстрый способ. Можете проверить прямо из консоли почтового сервера. Так же можно воспользоваться каким-то готовым сервисом, например https://ssl-tools.net/mailservers.
Если у вас все в порядке, значит настройка ssl в postfix закончена. Остался последний штрих.
Настройка SSL, TLS на WordPress
Для примера, возьмём сайт на WordPress и настроим на нём SSL/TLS, сделаем его доступным по HTTPS.
Нужно будет обязательно пройтись по списку и внести соответствующие изменения:
- Переписать в базе данных все ссылки, заменив на
Для этого, вы можете воспользоваться WP-Cli или специальной утилитой Seach Replace DB - Переписать в файлах темы все ссылки, заменив на или
- Отредактировать , а именно, перед добавить:
// example.com меняем на своё имя домена define('WP_HOME', 'https://example.com'); define('WP_SITEURL', 'https://example.com'); // Принудительная авторизация в админке по защищённому протоколу define('FORCE_SSL_ADMIN', true); // Чтобы предотвратить бесконечный редирект с http на https if (strpos($_SERVER, 'https') !== false) $_SERVER='on';2 и 3 строки не обязательны, если выполнили первый пункт списка.
Про последнее можно добавить, что если WordPress находится за проксирующим сервером с SSL, но хостится на сервере без SSL (то есть, как в нашем случае, SSL на NGINX, Apache без), запросы к страницам сайта будут создавать бесконечный цикл. Чтобы его предотвратить, и используется определение в заголовках , наличие https в котором и будет говорить о том, что в заголовки надо будет записать метку о том, что HTTPS включен, и она будет сигнализировать Вордпрессу о том, что мы работаем на https.
Подробности можете посмотреть тут https://codex.wordpress.org/Administration_Over_SSL
Возможные ошибки!
Как открыть меню битрикс в VMBitrix
Да, бывает и такое! Для того, чтобы вызовать меню настроек VMBitrix 7.X.X из командной строки Linux необходимо выпольнить следующую команду:
/root/menu.sh
./menu.sh
Удаление ААА записи
В моём случае я столкнулся с следующей ошибкой. Я прописал A запись с указанием моего сервера с VMBitrix и домен открывался, однако сертификат выпустить не удавалось :
IMPORTANT NOTES: - The following errors were reported by the server: Domain: test.domain.com Type: connection Detail: Fetching http://test.domain.com/.well-known/acme-challenge/oTk4n-oaIuuAo_3WUSyh153oK5JLVGPedvHiztgoU68: Error getting validation data To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.
В итоге моя А запись разнилась с ААА записью. После удаления ААА записи всё получилось.
Linking up nginx and certbot
Let’s Encrypt performs domain validation by requesting a well-known URL from a domain. If it receives a certain response (the “challenge”), the domain is considered validated. This is similar to how Google Search Console establishes ownership of a website. The response data is provided by certbot, so we need a way for the nginx container to serve files from certbot.
First of all, we need two shared Docker volumes. One for the validation challenges, the other for the actual certificates.
Add this to the list of the section in .
- ./data/certbot/conf:/etc/letsencrypt- ./data/certbot/www:/var/www/certbot
And this is the counterpart that needs to go in the section:
volumes: - ./data/certbot/conf:/etc/letsencrypt - ./data/certbot/www:/var/www/certbot
Now we can make nginx serve the challenge files from certbot! Add this to the first (port 80) section of our nginx configuration ():
location /.well-known/acme-challenge/ { root /var/www/certbot;}
After that, we need to reference the HTTPS certificates. Add the soon-to-be-created certificate and its private key to the second section (port 443). Make sure to once again replace with your domain name.
ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;
And while we’re at it: The folks at Let’s Encrypt maintain best-practice HTTPS configurations for nginx. Let’s also add them to our config file. This will score you a straight A in the SSL Labs test!
include /etc/letsencrypt/options-ssl-nginx.conf;ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
Установка и использование сертификатов
Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. ).
Давайте посмотрим что за файлы у нас есть:
С этим знанием мы можем задать настройки SSL для nginx:
Как видите, нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.
Полный рабочий пример конфига:
Конфиг для переадресации с голого домена без www:
Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то в директиве нужно заменить на IP используемого DNS сервера.
Настройки шифров и прочее подобное (, ) лучше держать вне конфигов отдельных серверов.
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.
Откройте ssl.conf:
В блок server добавьте следующий код:
Если ранее вы изменили путь к 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».
Настраиваем WordPress в подпапке домена nginx
Нередко портал использует несколько CMS, доступ к которым организован из меню Landing Page. При размещении в поддомене с ссылкой вроде blog.example.org проблем нет, настраивается это стандартными правилами. А в случае использования подкаталога () стандартные установки уже не подходят.
Разберем на примере WordPress. В инструкции на сайте WP при таком расположении предлагается переместить и из каталога с WordPress в корневой каталог сайта и указать в новое расположение сайта. Вместо
вписать новый путь:
Загвоздка в том, что в корневом каталоге уже может быть такой файл от основного сайта или нужно подключать несколько CMS со своими ссылками. В Apache это не проблема, а вот в nginx придется чуть отойти от стандартной конфигурации.
В начале идет основной сайт. Здесь все как обычно:
Блог на WP к основному сайту подключается как location. В параметре root указываем полный путь к каталогу. В случае nginx нет ничего плохого в размещении root-каталога внутри location. Для проверки наличия файлов в nginx есть очень полезная инструкция , которая просматривает существование файлов в указанном порядке и при первом совпадении использует его для обработки. Обработка делается в контексте этого же location в соответствии с директивами root и alias. Если в конце имени указать слеш, то проверяется каталог (например, ). Если совпадения не найдены, то делается внутреннее перенаправление на uri, заданное последним параметром.
Переменная , используемая в конфигурации, указывает на текущий URI запроса в нормализованном виде, при обработке запроса его значение может изменяться. $uri вообще очень полезная директива, при помощи которой можно перенаправлять запросы, блокировать доступ к файлам, перенаправлять на 404, если файла нет, и многое другое.
Если сайт расположен в пределах корневого каталога веб-сайта, такая схема работает без проблем. Но если location находится вне корневого каталога веб-сервера (что, кстати, очень не рекомендуют сами разработчики), то у него не будет доступа к корневому каталогу. То есть описанная конфигурация работать не станет. Например, не будут грузиться картинки или стили, и нужно дополнительно указать веб-серверу, где их искать.
Основная часть кода остается без изменений, правим только ту, что касается самого блога:
Как установить SSL-сертификат на сервер Nginx
Перед установкой нужно получить все части SSL-сертификата:
- сертификат,
- приватный ключ,
- промежуточный сертификат,
- корневой сертификат.
Далее нужно выполнить несколько подготовительных действий на компьютере:
1. Создайте файл с названием domain_name.crt (вместо domain_name укажите домен, для которого заказан сертификат). Добавьте в него сертификат, промежуточный и корневой сертификаты. Итоговая версия файла должна иметь следующий вид:
——BEGIN CERTIFICATE——
сертификат
——END CERTIFICATE——
——BEGIN CERTIFICATE——
промежуточный_сертификат
——END CERTIFICATE——
——BEGIN CERTIFICATE——
корневой_сертификат
——END CERTIFICATE——
2. Создайте второй файл с названием domain_name.key (вместо domain_name укажите домен, для которого заказан сертификат). Добавьте в него содержимое приватного ключа.
3. Создайте файл с названием ca.crt и добавьте в него содержимое корневого сертификата.
Готово.
Следующие шаги — это установка и настройка SSL-сертификата на Nginx.
Чтобы установить сертификат:
1. Подключитесь к серверу по SSH.
2. Загрузите созданные файлы на сервер. Это нужно сделать в следующую директорию:
/etc/ssl/
Также возможен вариант:
/etc/nginx/ssl/domain.ru
Вместо domain.ru укажите директорию вашего домена.
3. Откройте конфигурационный файл Nginx. Для этого выполните одну из команд в зависимости от расположения файла на сервере:
sudo nano /usr/local/nginx/conf
sudo nano /etc/nginx
sudo nano /usr/local/etc/nginx
4. В файле конфигурации Nginx добавьте блок для работы сайта по HTTPS:
server {
listen 443 ssl;
server_name domain.ru;
ssl_certificate /etc/ssl/domain_name.crt;
ssl_certificate_key /etc/ssl/domain_name.key;
}
Где:
- domain.ru — доменное имя сайта,
- domain_name.crt — путь к файлу с публичным ключом,
- domain_name.key — путь к файлу с приватным ключом.
5. Если вам нужно, чтобы был доступен протокол HTTP, добавьте дополнительную директиву listen:
listen 80;
6. Далее необходимо оптимизировать работу HTTPS-сервера Nginx: для этого в секции server добавьте строки:
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
keepalive_timeout 70;
Где:
- shared:SSL:10m — тип кэша и его размер,
- ssl_session_timeout 10m — таймаут кэша,
- keepalive_timeout 70 — время одного соединения.
7. Укажите протоколы TLS (SSL), версии которых должен поддерживать сервер:
ssl_protocols TLSv1 TLSv1.2 TLSv1.3;
8. Для выбора серверных шифров в качестве приоритетных добавьте строку:
ssl_prefer_server_ciphers on;
9. Чтобы страницы сайта загружались быстрее, нужно:
- позволить серверу прикреплять OCSP-ответы для проверки статуса SSL-сертификата,
- указать путь к корневому сертификату,
- добавить адрес корневого DNS-сервера.
Для настройки этих параметров добавьте строки:
ssl_stapling on;
ssl_trusted_certificate /etc/ssl/domain.ru/ca.crt;
resolver 1.1.1.1;
Где:
- /etc/ssl/domain.ru/ca.crt — путь к файлу корневого сертификата,
- 1.1.1.1 — адрес корневого DNS-сервера.
10. Проверьте содержимое конфигурационного файла. Оно будет иметь следующий вид:
server {
listen 443 ssl;
listen 80;
server_name domain.ru;
ssl_certificate /etc/ssl/domain.ru/domain_name.crt;
ssl_certificate_key /etc/ssl/domain.ru/domain_name.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
keepalive_timeout 70;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_trusted_certificate /etc/ssl/domain.ru/ca.crt;
resolver 1.1.1.1;
}
После проверки сохраните изменения с помощью комбинации клавиш Ctrl + O. Затем закройте файл, используя Ctrl + X.
11. Чтобы изменения вступили в силу, нужно перезагрузить веб-сервер Nginx. Для этого выполните команду:
sudo /etc/init.d/nginx restart
Готово, вы установили SSL-сертификат на Nginx.
Шаг 4 — Получение сертификата SSL
Certbot предоставляет широкий выбор способов получения сертификатов SSL с помощью плагинов: Плагин Nginx изменит конфигурацию Nginx и перезагрузит ее, когда это потребуется. Для использования этого плагина введите следующую команду:
Эта команда запускает certbot с плагином —nginx, используя опцию -d для указания доменных имен, для которых мы хотим использовать сертификат.
Если это первый запуск certbot, вам будет предложено указать адрес эл. почты и принять условия обслуживания. После этого certbot свяжется с сервером Let’s Encrypt и отправит запрос с целью подтвердить, что вы контролируете домен, для которого запрашиваете сертификат.
Если это будет подтверждено, certbot запросит у вас предпочитаемый вариант настройки HTTPS:
Output
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -1: No redirect - Make no further changes to the webserver configuration.2: Redirect - Make all requests redirect to secure HTTPS access. Choose this fornew sites, or if you're confident your site works on HTTPS. You can undo thischange by editing your web server's configuration.- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Select the appropriate number then (press 'c' to cancel):
Выберите желаемый вариант, после чего нажмите ENTER. Конфигурация будет обновлена, а Nginx перезагрузится для получения новых настроек. Затем certbot завершит работу и выведет сообщение, подтверждающее завершение процесса и указывающее место хранения ваших сертификатов:
Output
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on 2020-08-18. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
Ваши сертификаты загружены, установлены и активированы. Попробуйте перезагрузить веб-сайт с помощью https:// и посмотрите на индикатор безопасности в браузере. Теперь в браузере должен отображаться символ замка, означающий, что сайт защищен надлежащим образом. Если вы протестируете свой сервер с помощью теста SSL Labs Server Test, он получит оценку A.
В заключение протестируем процесс обновления.
Получаем бесплатный SSL сертификат для Битрикс24 (Bitrix VM)
Чтобы в Bitrix VM установить SSL сертификат от Let’s Encrypt для начала его нужно нам получить. Как получим бесплатный сертификат и установим его не сервер мы сделаем автоматическое задание на его перевыпуск.
Для начала нужно установить certbot от Let’s Encrypt для автоматизации процесса получения бесплатных сертификатов а после и для автоматизации перевыпуска.
В моём случае я прикручивал бесплатный SSL (для доступа по https) сертификат Let’s Encrypt на виртуальную машину Битрикс 24 (Bitrix VM).
yum -y install yum-utils yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional yum install certbot
Для получения сертификата certbot’у нужен будет доступ через 443 порт () и для этого мы пока временно потушим работу nginx, так как он занимает этот порт.
systemctl stop nginx
certbot certonly --standalone -d itlocate.ru -d www.itlocate.ru
Мы получили наши сертификаты и они лежат тут: /etc/letsencrypt/live/itlocate.ru/
Что такое SSL-сертификат
SSL-сертификат — это цифровой документ, который хранит в себе информацию о домене и его владельце. Если вы переходите на ресурс и видите значок замка и https:// в адресной строке браузера, значит, на сайте используется SSL-сертификат.
Главное назначение сертификата безопасности — защитить данные от перехвата третьими лицами. Это возможно благодаря криптографическому протоколу TLS — «современнику» SSL-протокола (protocol SSL), в честь которого SSL-сертификат получил название. Он шифрует данные перед их передачей.
Помимо этого SSL-сертификаты используются, чтобы:
- сохранить целостность данных при передаче — при использовании SSL-сертификата они не потеряются и не изменятся,
- подтвердить подлинность ресурса — так как центр сертификации проводит проверку домена и его администратора на существование, SSL-сертификат выдается только проверенным сайтам.
После установки SSL-сертификата сайт начинает работу по протоколу HTTPS, который поддерживает шифрование информации и работает поверх криптографического TLS. В чем отличие TLS от HTTPS? TLS кодирует передаваемые данные, а HTTPS — канал, по которому они передаются.
Certbot и webroot
Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.
Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который ожидает найти в :
Последняя директива нужна чтобы избавить нас от прелестей и красивостей ncurses, что нужно чтобы вы могли сравнить вывод команд здесь, в этой статье, и у себя.
Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.
Что будет делать Certbot
Ожидается что будет создавать необходимые для проверки прав на домен файлы в подкаталогах ниже по иерархии к указанному. Вроде таких:
Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:
Для следующих проверок создадим какой-то такой файл:
Create Nginx Virtualhost
We will now create an Nginx virtual host configuration file for the domain
www.itzgeek.net.
This virtual host serves the HTTP version of your domain.
Use the below information.
server {
server_name www.itzgeek.net;
root /sites/www.itzgeek.net;
location / {
index index.html index.htm index.php;
}
access_log /var/log/nginx/www.itzgeek.net.access.log;
error_log /var/log/nginx/www.itzgeek.net.error.log;
}
Add below lines to the above server block in order to have PHP support in Nginx.
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
Create a document root to hold your HTML files.
Change the ownership of the directory.
Place the test HTML file in the document root of your domain.
Restart the Nginx service.
Получение бесплатного сертификата и подключение к Nginx
Настраиваем конфигурационный файл домена в Nginx
sudo nano /etc/nginx/sites-available/example.com
Вносим изменения (отмечено красным)
server {
listen 80;
listen :80;
server_name example.com www.example.com;
root /var/www/html/example.com;
index index.php;
include snippets/well-known;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
client_max_body_size 100M;
autoindex off;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Сохраняем файл и перезапускаем Nginx
Далее запустим команду получения сертификата
sudo certbot certonly --agree-tos --email admin@example.com --webroot -w /var/lib/letsencrypt/ -d example.com -d www.example.com
Красным отмечены изменения для вашего домена. Если все успешно видим сообщение
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on 2019-08-18. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
Подключаем сертификат. Сначала генерируем 2048 битный сертификат.
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Редактируем конфигурационный файл
sudo nano /etc/nginx/sites-available/example.com
server {
listen 80;
server_name www.example.com example.com;
include snippets/well-known;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen :443 ssl http2;
server_name example.com www.example.com;
root /var/www/html/example.com;
index index.html;
if ($host != "example.com") {
return 301 https://example.com$request_uri;
}
include snippets/well-known;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 30s;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
client_max_body_size 100M;
autoindex off;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Перезапускаем Nginx, при необходимости проверяя конфигурацию и делаем перевыпуск сертификата по расписанию в час ночи 1 числа каждого месяца.
sudo crontab -e
0 1 1 * * /usr/bin/certbot renew & > /dev/null
Установка WordPress
Обращаемся через веб к нашему сайту https://example.com и если все правильно видим первоначальную страницу установки.
Начало установки WordPress
Настройка подключения к базе данных WordPress
Указываем нашу базу данных wpbase, пользователя wpuser и пароль соединения с базой данных.
Далее создаем первого пользователя (администратор) и пароль WordPress.
Устанавливаем клиент Let’s Encrypt на сервер
Подключаемся к серверу по SSH. И переходим, например, в домашнюю директорию:
cd /home/
В нее мы установим клиент Let’s Encrypt. Для этого нам понадобится git, если у вас на сервере уже установлен git, то просто выполните следующие команды:
git clone https://github.com/letsencrypt/letsencrypt cd letsencrypt
Если у вас не установлен git, то либо установите его следующей командой:
apt-get install git
Либо просто распакуйте zip архив из репозитория GitHub:
wget https://github.com/letsencrypt/letsencrypt/archive/master.zip unzip master.zip mv letsencrypt-master letsencrypt cd letsencrypt
Проверяем:
./letsencrypt-auto --help
В ответ вы увидите следующие:
Все, клиент Let’s Encrypt установлен.