Введение

Существует множество причин использовать шифрование TLS на веб-сайте. Некоторые из них очевидны (например, защита безопасности и конфиденциальности посетителей), некоторые из них связаны с такими тонкостями, как SEO и предпочтения пользователей. Многие аналитики рекомендуют переключиться на HTTPS, потому что поисковая система Google, например, рассматривает HTTPS как один из сигналов ранжирования. Кроме того, новые версии браузеров (например, Chrome) пугают посетителей не зашифрованных веб-сайтов, отмечая их как «небезопасные».

До недавнего времени многие веб-мастера, блогеры и владельцы малого бизнеса использовали, для шифрования своих ресурсов, бесплатные сертификаты StartSSL и WoSign. Поскольку сертификаты StartSSL и WoSign больше не входят в список доверенных для Mozilla (https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/) и Google, и нет других бесплатных вариантов для получения долгоиграющих SSL сертификатов, мы выбрали опцию Let’s Encrypt (https://letsencrypt.org/getting-started/). Поскольку сертификат LetsEncrypt действителен только в течение 90 дней, автоматизация его обновлений действительно необходима. Рекомендуемым инструментом автоматизации является Certbot EFF (https://certbot.eff.org/). Эта утилита полуавтоматически включает HTTPS на вашем веб-сайте, развертывая сертификаты Let’s Encrypt. (На момент установки, не было полностью автоматизированного способа это сделать для нашего сочетания операционной системы ( CentOS7) и веб-сервера (nginx). Поэтому некоторые вещи пришлось делать руками.)

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

ПРОЦЕСС ИНСТАЛЛЯЦИИ

Вышеупомянутые ресурсы разработчиков дают полные инструкции для самых разных ситуаций. Здесь мы просто демонстрируем логику использования этого программного обеспечения для одного конкретного случая (только один домен / поддомен на VPS, который ранее имел другой сертификат: nginx в качестве веб-сервера и CentOS7 в качестве ОС; root SSH доступ; также предполагается, что мы можем остановить веб-сервер временно без негативных последствий).

Итак, шаг за шагом:

1. Устанавливаем certbot:
yum install certbot

(несколько зависимостей EPEL будут загружены вместе с ним, это нормально)

2. Чтобы получить сертификат с помощью встроенного «автономного» (“standalone”) плагина, может потребоваться временно остановить существующий веб-сервер:

systemctl stop nginx

3. Запускаем процесс:
certbot certonly —standalone -d your.website.com

и убеждаемся, что все идет гладко:

IMPORTANT NOTES:

— Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/your.website.com/fullchain.pem. Your cert will expire on 2017-04-28. 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»

Сертификаты фактически будут размещены в:
/etc/letsencrypt/archive/your.website.com/.

Симлинки к сертификатам будут помещены в
/etc/letsencrypt/live/your.website.com/.

Вы можете использовать плагин Webroot Certbot (он позволяет получить сертификат без остановки / запуска Nginx) вместо автономного Standalone плагина, но вам, вероятно, потребуется перезапустить / перезагрузить Nginx позже, чтобы активировать изменения, внесенные в файл(ы) конфигурации. В нашем случае разницы не было.

4. Найдите файл(ы) конфигурации Nginx. В нашем случае это:
/etc/nginx/nginx.conf и /etc/nginx/conf.d/ext.conf

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

# disabled 2017-01-28
# ssl_certificate /etc/nginx/conf.d/yourold.crt;
# ssl_certificate_key /etc/nginx/conf.d/yourold.key.open;

# added 2017-01-28
ssl_certificate /etc/letsencrypt/live/your.website.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your.website.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/your.website.com/fullchain.pem;

Также полезно добавить каталоги, используемые плагином Webroot в Certbot, к пути Webroot (это позволит в будущем обновлять сертификат без остановки / запуска Nginx). Поэтому добавьте:
location /.well-known {
alias /home/site/.well-known;
}
в обе части конфигурационного файла:
server {
listen 80;

и:

server {
listen 443 ssl;

(Здесь может быть неясный момент — он связан с тем, что мы на опыте обнаружили, что, хотя автономный Standalone плагин использует для проверки порт 443, для плагина Webroot используется порт 80).

Может быть полезно поместить любой тестовый файл (например, файл a.txt) в указанный каталог /.well-known/acme-challenge (чтобы проверить доступ позже).

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

5. Затем не забудьте запустить веб-сервер:

systemctl start nginx

Убедитесь, что он работает, и тестовый файл доступен из Интернета через http и https.

 

6. Теперь займемся автоматизацией будущих продлений:

находим .conf файл в /etc/letsencrypt/renewal/

Изменяем параметры, используемые в процессе обновления, следующим образом:

[renewalparams]

# authenticator = standalone
authenticator = webroot
webroot-path = /home/site

раскомментируем строку:
renew_before_expiry = 5 days

7. Запускаем обновление Certbot в тестовом режиме (dry-run):
certbot renew —dry-run -w /home/site

Убеждаемся, что все в порядке, особенно проверка:

 

Congratulations, all renewals succeeded. The following certs have been renewed: …

Если все работает, есть смысл заархивировать папку /etc/letsencrypt и файлы конфигурации (/etc/nginx/conf.d), и сохранить их в сухом, прохладном месте 🙂

8. Добавляем команду

certbot renew -w /home/site -q

в Crontab для ежедневного исполнения. Он не будет перезагружать сертификат каждый день, если вы правильно установите update_before_expiry (см. п. 6).

9. Убедитесь, что Nginx перезагружает конфигурацию после обновления сертификата. Очевидным способом для этого может быть добавление команды вроде
nginx -t -q && nginx -s reload
в Crontab на определенный день. Но немного разумнее было бы связать перезагрузку конфигурации с точным моментом обновления сертификата. Для этого мы можем изменить команду обновления (п. 8) следующим образом, используя хук:
certbot renew —no-self-upgrade -w /home/site -q —renew-hook «nginx -t -q && nginx -s reload»

или (с полными путями):

certbot renew —no-self-upgrade -w /home/site -q —renew-hook «/usr/sbin/nginx -t -q && /usr/sbin/nginx -s reload»

10. Если вы настроили некоторые из других серверов на этой же машине (например, Webmin) для использования тех же сертификатов, не забудьте перезагрузить / перезапустить их конфигурацию, например так:
systemctl stop webmin
systemctl start webmin

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

Этот метод был одобрен и хорошо работает на обоих наших сайтах: www.ruspo.com and www.tree-talk.com.

ВОЗМОЖНЫЕ ПРОБЛЕМЫ / TROUBLESHOOTING

Наш опыт показывает, что LetsEncrypt и сам Certbot работают как часы. Некоторые проблемы могут возникать со стороны Cron, и обычно они вызваны неправильными разрешениями, неправильным именем скрипта или переменными окружения. Если у вас есть проблемы такого рода, вы можете взглянуть на свои логи и изучить несколько полезных статей:
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-autotasks.html
и
6 Reasons Your Cron Job is Not Running (http://2clickfix.com/6-reasons-cron-job-not-running/ ).

Пути и файлы, относящиеся к Certbot:

/usr/bin/certbot
/root/certbot.log
/usr/share/doc/certbot-0.9.3
/usr/share/licenses/certbot-0.9.3

Эта статья изначально была опубликована на английском языке в Ruspo blog: https://blog1.ruspo.com/

и в https://medium.com/@IgorYanovskiy/installing-the-letsencrypt-ssl-certificate-and-arranging-an-automatic-renewal-b770dafb72e7