Lets encrypt ssl сертификат инструкция linux

Время на прочтение13 мин

Количество просмотров339K

Картинка с сайта: habr.com

Если вдруг вся эта история прошла мимо вас, Let’s Encrypt — центр сертификации от некоммерческой организации ISRG, существующий при поддержке EFF и многих компаний, взявшей на себя миссию дать людям бесплатные SSL/TLS сертификаты для сайтов и серверов. Сертификаты от Let’s Encrypt уже используются на более чем 10 миллионах доменов.

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

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

Организации автоматического обновления сертификатов в статье уделено пристальное внимание, с тем чтобы вы могли в полной мере оценить это принципиальное преимущество Let’s Encrypt.

Почему эта статья

На сайте EFF есть краткие инструкции по использованию Certbot, рекомендуемой программы для получения сертификатов, но они скорей рассчитаны на тех, кто заходит на свой сервер по SSH лишь по острой необходимости. Более подробная документация тоже есть, но пока всю ее прочитаешь и найдешь всё то, что действительно нужно знать… К тому же, в ней не рассмотрены некоторые важные стратегические вопросы использования сертификатов.

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

Содержание

Из этой статьи вы узнаете…

1. Как установить и настроить Certbot для регулярного использования.
2. Что требуется от nginx и как настроить nginx для получения сертификатов.
3. Как получать сертификаты и как проверить полученный сертификат.
4. Как установить сертификат от Let’s Encrypt в nginx.
5. Как автоматически обновлять сертификаты.

Caveat emptor

Всё знаете про SNI? Читайте сразу про установку.

В инструкциях ниже я исхожу из того что ваши сайты будут использовать SNI. Это расширение протокола TLS позволяет браузерам сообщить желаемое имя сайта до получения и проверки SSL сертификата от сервера. Благодаря SNI вы можете разместить сколько угодно сайтов за HTTPS на одном IP. Но не всё так просто — иначе бы зачем я об этом писал?

Есть ряд старых браузеров в принципе не поддерживающих SNI. В их число входят любые версии IE в уже заброшенном Windows XP, встроенный браузер в Android 2.3 и 2.2 из 2010 года, а также некоторые другие более экзотические браузеры и библиотеки типа Java версии 1.6 и Python до версии 2.7.9.

Если вы всё-таки хотите чтобы ваш сайт открывался в IE в Windows XP, то одним отказом от SNI эта проблема не решается. Нужно специальным образом подбирать шифры, уже отказываясь от forward secrecy и рискуя получить низкую оценку от SSL Labs. Как можно догадаться, этот вопрос заслуживает отдельного обсуждения хотя бы потому что пользователям IE под XP можно посочувствовать — у них уже не открывается половина интернета!

Еще год назад от перехода на SNI вас могла бы удержать ограниченная поддержка этой технологии некоторыми поисковыми ботами типа Bing, но сейчас, с появлением десятков сайтов с бесплатными сертификатами от Cloudflare, что без SNI не открываются, бот Bing (что легко проверить), и боты других основных поисковиков, пришли в согласие с реальностью. Сейчас за это можно не волноваться. Отмечу, что у Googlebot таких проблем не было никогда.

Другим поводом для волнений могут быть различные средства доступа к API вашего сайта. Если у вас давно есть API, то есть небольшой шанс что среди ваших клиентов есть какие-то, использующие устаревшие версии Java или Python. Если у вас таких нет, то не о чем переживать. Если же есть — мои соболезнования.

Почему лучше рассчитывать на SNI?

1. Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.

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

Например, так можно посмотреть домены в сертификате Тематических Медиа:

true | openssl s_client -showcerts -connect habrahabr.ru:443 2>&1 |
    openssl x509 -text | grep -o 'DNS:[^,]*' | cut -f2 -d:

На момент написания статьи эта команда выведет подробный список всевозможных доменов ТМ:

habrastorage.org
api.geektimes.ru
api.habrahabr.ru
geektimes.ru
habrahabr.ru
id.tmtm.ru
lab.geektimes.ru
m.geektimes.ru
m.habrahabr.ru
special.geektimes.ru
special.habrahabr.ru
www.geektimes.ru
www.habrahabr.ru

Никакой секретности и никаких тайн. Вы этого хотите?

Установка Certbot

Если вы читаете этот текст из будущего, когда Certbot уже есть в Debian stable и Ubuntu без обиняков и оговорок, то всё просто:

apt-get install certbot

Либо используйте aptitude или другой пакетный менеджер вашего дистрибутива.

Установка в Jessie

Если у вас еще в ходу актуальный на конец 2016 года Debian stable «jessie», то всё лишь немного сложнее.

1. Нужно подключить Debian Backports, добавив строчку в /etc/apt/sources.list:

   deb http://ftp.debian.org/debian/ jessie-backports main contrib non-free

2. Теперь можно устанавливать с указанием источника:

   apt-get update
   apt-get install certbot -t jessie-backports

   (Раздел актуален пока только stretch не стал stable.)

Ubuntu версий ниже 16.10 (yakkety)

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install --upgrade letsencrypt

Дальше везде вместо certbot используйте letsencrypt.

Другой дистрибутив

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

wget -O /usr/local/bin/certbot-auto https://dl.eff.org/certbot-auto
chmod +x /usr/local/bin/certbot-auto
ln -s /usr/local/bin/certbot-auto /usr/local/bin/certbot

Везде ниже вместо команды certbot можно использовать команду certbot-auto.

Certbot и webroot

Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который certbot будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.

Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который certbot ожидает найти в /etc/letsencrypt/cli.ini:

authenticator = webroot
webroot-path = /var/www/html
post-hook = service nginx reload
text = True

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

Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.

letsencrypt: error: Unexpected line 14 in /etc/letsencrypt/cli.ini: post-hook = service nginx reload; service postfix reload

Что будет делать Certbot

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

/var/www/html/.well-known/acme-challenge/example.html

Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:

http://www.example.com/.well-known/acme-challenge/example.html

Для следующих проверок создадим какой-то такой файл:

mkdir -p /var/www/html/.well-known/acme-challenge
echo Success > /var/www/html/.well-known/acme-challenge/example.html

Регистрация в Let’s Encrypt

Регистрацию нужно сделать только один раз:

certbot register --email me@example.com

Здесь ничего сложного.

Подготовим nginx к получению сертификатов

В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location:

location /.well-known {
    root /var/www/html;
}

Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.

# cat /etc/nginx/acme 
location /.well-known {
    root /var/www/html;
}

Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:

include acme;

Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.

Перезагрузим nginx и проверим что наш тестовый файл виден:

# service nginx reload
# curl -L http://www.example.com/.well-known/acme-challenge/example.html
Success

После проверки лучше удалить тестовый файл — certbot любит удалять за собой всё лишнее, а такой файл будет мешать и вызывать сообщение об ошибке (Unable to clean up challenge directory).

rm /var/www/html/.well-known/acme-challenge/example.html

Теперь у нас всё готово чтобы получить наш первый сертификат.

О переадресации с кодами 301 и 302

Как было уже сказано, ACME сервер Boulder учитывает переадресацию с кодами 301 и 302. В этом смысле не имеет значения где, в конечном счете, находятся файлы, требуемые для прохождения проверок. Переадресация возможна даже на нестандартные порты, без ограничений по конечному протоколу HTTP или HTTPS. Сами Let’s Encrypt рекомендуют использовать переадресацию для создания единой точки проверки прав на домены.

Если вы можете получить эти файлы с помощью curl с ограничением в десять переадресаций, то и Boulder эти файлы увидит. Не должно быть никаких ограничений по IP адресам.

curl --location --max-redirs 10 http://example.com/.well-known/acme-challenge/example.html

Это удобно если у вас сложная структура переадресаций между разными версиями сайтов. Должно быть достаточно подключить тот блок с location только на основном сайте для получения сертификатов для всех остальных.

$ curl --head --silent --location --max-redirs 10 http://somewhere.example.net/... | grep ^HTTP
HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
HTTP/1.1 200 OK

Проверка всегда начинается с запроса по протоколу HTTP на 80 порту.

Если у вас уже всё зашифровано…

Если у вас уже все сайты работают по HTTPS, то вся схема будет работать если у вас настроен переадресующий сервер на 80 порту, сохраняющий $request_uri в ответе.

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

Пример конфигурации такого переадресующего всё-подряд-на-HTTPS сервера:

server {
    listen server.example.com:80 default_server;

    include acme;

    location / {
        return 301 https://$host$request_uri;
    }
}

Такой конфиг стоит определить в /etc/nginx/conf.d/default.conf, в стороне от конфигов конкретных сайтов.

Сервер запускаем явно на внешнем IP чтобы не перенастраивать Apache на другой порт. Если для вас это не проблема, то указание имени сервера в директиве listen можно пропустить.

Если нужно получить сертификат для домена без сайта…

Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо…

server {
    server_name smtp.example.com imap.example.com;
    listen server.example.com:80;

    include acme;

    location / {
        return 404;
    }
}

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

Если у вас только Apache2…

Если у вас Apache2, а перейти на всеми любимый nginx возможности нет, то… Добавьте следующие строчки в /etc/apache2/conf-available/certbot.conf:

Alias /.well-known/ /var/www/html/.well-known/
<Directory /var/www/html/.well-known/>
    Satisfy any
</Directory>

Затем

a2enconf certbot
mkdir -p /var/www/html/.well-known
service apache2 reload

И обязательно проверьте, так:

mkdir -p /var/www/html/.well-known/acme-challenge
echo Success > /var/www/html/.well-known/acme-challenge/example.html
curl -L http://localhost/.well-known/acme-challenge/example.html && 
rm /var/www/html/.well-known/acme-challenge/example.html

Существует много причин почему такая схема может у вас в Apache2 не заработать. Пары экранов текста не хватит чтобы описать их все. Не серчайте — статья про nginx.

Получаем сертификаты

У Let’s Encrypt есть лимиты на количество обращений за сертификатами, потому сначала попробуем получить необходимый сертификат в режиме для тестов:

certbot certonly --dry-run -d example.com -d www.example.com

В конце программа должна отчитаться об успешной работе:

The dry run was successful.

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

# certbot certonly -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will
   expire on 2017-04-01. 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"

Ура! С получением сертификата закончено!

Если нужно добавить поддомен или домен в сертификат

Если вы вдруг забыли указать поддомен www, или вам нужно добавить другой домен или поддомен в сертификат (которых может быть до 100 в одном сертификате), то это легко сделать после получения сертификата. Просто запустите команду еще раз, добавив требуемое имя:

certbot certonly -d example.com -d www.example.com -d shop.example.com

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

certbot certonly --expand -d example.com -d www.example.com -d shop.example.com

Операцию можно повторять.

Проверим полученный сертификат

Убедимся что полученный сертификат — именно тот, что нам нужен:

# openssl x509 -text -in /etc/letsencrypt/live/example.com/cert.pem
Certificate:
    Signature Algorithm: ...
      Validity
        Not Before: Jan  3 06:00:00 2017 GMT
        Not After : Apr  3 06:00:00 2017 GMT
        X509v3 extensions:
            ...
            X509v3 Subject Alternative Name: 
                DNS:example.com, DNS:www.example.com

Или, если подробности вам не нужны:

cat /etc/letsencrypt/live/*/cert.pem | openssl x509 -text | 
        grep -o 'DNS:[^,]*' | cut -f2 -d:

Команда должна вывести список доменов в сертификате.

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

Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. CN).

Давайте посмотрим что за файлы у нас есть:

 # find /etc/letsencrypt/live/ -type l
/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/chain.pem
/etc/letsencrypt/live/example.com/privkey.pem
/etc/letsencrypt/live/example.com/cert.pem

С этим знанием мы можем задать настройки SSL для nginx:

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;

Как видите, cert.pem нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.

Полный рабочий пример конфига:

server {
    server_name www.example.com;
    listen www.example.com:443 ssl; # default_server;
    # выше можно добавить default_server для клиентов без SNI

    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_stapling on;
    ssl_stapling_verify on;
    resolver 127.0.0.1 8.8.8.8;

    # исключим возврат на http-версию сайта
    add_header Strict-Transport-Security "max-age=31536000";

    # явно "сломаем" все картинки с http://
    add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";

    # далее всё что вы обычно указываете
    #location / {
    #    proxy_pass ...;
    #}
}

Конфиг для переадресации с голого домена без www:

server {
    server_name example.com;
    listen example.com:443 ssl;
    access_log off;

    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_stapling on;
    ssl_stapling_verify on;
    resolver 127.0.0.1 8.8.8.8;

    add_header Strict-Transport-Security "max-age=31536000";

    expires max;
    return 301 https://www.example.com$request_uri;
}

Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то 127.0.0.1 в директиве resolver нужно заменить на IP используемого DNS сервера.

Настройки шифров и прочее подобное (ssl_dhparam, ssl_session_cache) лучше держать вне конфигов отдельных серверов.

Perfect Forward Secrecy

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

Если для ECDHE на эллиптических кривых ничего не нужно делать, то для DHE можно было бы использовать усиленные параметры. Лучше всего будет отключить DHE вообще.

openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

ssl_dhparam /etc/ssl/private/dhparam.pem;

Продление сертификатов

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

Но нет, не спешите искать платежные средства! Как и было обещано в начале статьи, с обновлением сертификатов проблем нет.

Если у вас Debian, то нужно лишь дописать к вызову certbot в /etc/cron.d/certbot ключ --allow-subset-of-names:

# последняя строка в /etc/cron.d/certbot
# было certbot -q renew, а надо
certbot -q renew --allow-subset-of-names

Если у вас Debian и systemd, то посмотрите эти инструкции.

Если у вас не Debian или нет файла, то добавим в crontab от root одну лишь строчку (sudo crontab -e):

42 */12 * * * certbot renew --quiet --allow-subset-of-names

Согласно рекомендаций Let’s Encrypt следует пытаться обновить сертификаты два раза в день. Делать это нужно в случайным образом выбранную минуту того часа, а значит вам нужно заменить 42 в этой строке на другое число в диапазоне между 0 и 59. Либо вы можете поступить так как это делается в /etc/cron.d/certbot.

Как это работает

В этой команде ключ --allow-subset-of-names нужен чтобы Certbot пытался получить сертификаты для частичного набора доменов.

Например, были у вас на сервере были сайты www.example.com и shop.example.com, проходящие под одним сертификатом, но потом вы перенесли shop.example.com на другой сервер. Если такой ключ не указать, то Certbot упадет с ошибкой при попытке подтвердить владение shop.example.com, не получив для вас вообще никакого сертификата. Сертификат истечет и ваш сайт уйдет в оффлайн. С этим ключом вы всё же получите сертификаты хотя бы для частичного набора доменов, оставив ваши сайты в сети.

Вот и всё

Если вам близки по духу tee и sed, то есть гораздо более короткая инструкция по настройке связки Let’s Encrypt и nginx, при условии корректно настроенного hostname. Только копируй команды и вставляй.

Нашли ошибку? Напишите в личку, пожалуйста.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Получение бесплатного SSL сертификата Let’s Encrypt

Обновлено: 13.05.2025
Опубликовано: 22.05.2017

Тематические термины: Let’s Encrypt, CentOS, Ubuntu

Процесс в данной статье описан на примере систем Linux CentOS, Ubuntu (Debian) и Windows. Настройка выполняется в несколько шагов.

Условия получения бесплатного сертификата от Let’s Encrypt

Прежде чем начать, необходимо знать о некоторых нюансах получения сертификата Let’s Encrypt:

• При запросе выполняется проверка домена. Для этого необходимо:
  1. либо создать TXT-запись в DNS.
  2. либо поднять веб-сервер, далее в его корне создается каталог .well-known, а в нем файл с произвольным названием. После корневой центр отправляет запрос серверу на загрузку данного файла и, в случае успеха, выдает сертификаты для указанного доменного имени.
• SSL-сертификат выдается на 90 дней, поэтому необходимо по расписанию запускать команду на автоматическое продление ключа. Когда проходит 60 дней после начала использования нового сертификата, центр Let’s Encrypt может выдать новый.
• Если выполнять запрос для домена 3 уровня и выше, он должен пройти DNS проверку на всех уровнях. Например, домен layer3.layer2.com должен отвечать на запросы как для layer3.layer2.com, так и для layer2.com.

Проверка домена

Как было сказано выше, для получения бесплатного сертификата, Let’s Encrypt должен удостовериться, что мы являемся владельцем домена. Свое право на его владение мы можем подтвердить, создав специальную TXT-запись или настроив веб-сервис, который будет отвечать на запросы.

Настройка веб-сервера

Данный способ немного сложнее для Linux (для Windows все настройки делает утилита автоматически), но позволяет без проблем настроить автоматическое продление.

Запрашивать сертификат Let’s Encrypt проще всего с веб-сервера, на котором запущен сайт для домена. Возможен альтернативный вариант с монтирование сетевой папки, но его рассматривать не будем.

Linux NGINX

Пример простого конфигурационного файла для NGINX:

server {
    listen       80;
    server_name  dmosk.ru;
    root   /usr/share/nginx/html;
}

* где dmosk.ru — домен, для которого работает сайт и для которого мы будем запрашивать сертификат; /usr/share/nginx/html — путь по умолчанию для nginx.

Если сервер уже используется для сайта, в секцию server добавляем:

location ~ /.well-known/acme-challenge {
    root /usr/share/nginx/html;
    allow all;
}

* данными строчками мы говорим, что для всех запросов после /.well-known необходимо отдавать скрипты из каталога /usr/share/nginx/html; allow all предоставляет доступ всем.

При необходимости выполнять проверку и использовать rewrite/return, добавляем что-то подобное:

    …
    location ~ /.well-known/acme-challenge {
        root /usr/share/nginx/html;
        allow all;
    }
    if ($uri !~ /.well-known/acme-challenge){
        return 301 https://$host$request_uri;
    }

После проверяем конфигурацию и перезапускаем nginx:

nginx -t && nginx -s reload

Linux Apache

Создаем общий конфигурационный файл, в котором пропишем алиас.

а) для CentOS:

vi /etc/httpd/conf.d/lets.conf

б) для Ubuntu / Debian:

vi /etc/apache2/conf-enabled/lets.conf

Со следующим содержимым:

Alias /.well-known/acme-challenge/ /var/www/html/.well-known/acme-challenge/

* в данном примере, запросы для страниц /.well-known/acme-challenge всех сайтов мы переводим в каталог /var/www/html/.well-known/acme-challenge.

Проверяем корректность конфигурационного файла:

apachectl configtest

И перезапускаем apache:

systemctl restart httpd || systemctl restart apache2

Windows

IIS должен отвечать на http-запрос до доменному имени, для которого мы планируем получить сертификат. Также в его настройках мы должны сделать привязку узла, для которого хотим получить сертификат к конкретному сайту. Для этого в консоли управления IIS раскрываем сайты и выбираем нужный нам (в данном примере, он всего один):

В меню справа кликаем по Привязки:

Изменяем привязку для имеющийся записи и, при необходимости, добавляем еще:

Картинка с сайта: www.dmosk.ru

Применяем настройки и закрываем консоль управления IIS.

С помощью записи в DNS

Данный метод проще, описанного выше, но он позволит настроить автоматическое продление сертификата только для некоторых DNS, для которых есть отдельные certbot-плагины. Поэтому данный способ, в большинстве случаев, будет удобен для проведения тестов.

У нас должна быть возможность управления записями в DNS. На данном этапе достаточно просто зайти в панель управления DNS и перейти к этапу получения сертификата (ниже по тексту). Если домен новый и был только-что делегирован на DNS, возможно, придется подождать, пока он не станет доступен для всех серверов DNS в глобальной сети.

Установка утилиты для получения сертификата

Certbot для Linux

1) Rocky Linux:

dnf install epel-release

dnf install certbot

2) на CentOS 8:

dnf —enablerepo=powertools install certbot

3) на CentOS 7:

yum install certbot

4) на Ubuntu 16.04 и выше, а также Debian:

apt update

apt install certbot

5) Универсальный через python-pip:

Пакет certbot является приложением python и для его установки нужно использовать модуль pip. Сам модуль также нужно поставить. В зависимости от дистрибутива Linux наша команда будет отличаться.

а) Для систем на базе DEB:

apt install python3-pip

б) Для систем на базе RPM:

yum install python3-pip

После установки пакета нам доступен модуль pip. Используем его для установки certbot.

Начнем с обновления самого модуля:

python3 -m pip install —upgrade pip

Выполняем установку:

python3 -m pip install certbot

6) Astra Linux:

Для астры не нашел репозитория установки certbot, но есть решение хоть и не красивое, но рабочее.

Загружаем deb-файлы для debian 10:

wget http://ftp.de.debian.org/debian/pool/main/p/python-certbot/certbot_0.31.0-1+deb10u1_all.deb

wget http://ftp.de.debian.org/debian/pool/main/p/python-certbot/python3-certbot_0.31.0-1+deb10u1_all.deb

Пробуем установить python3-certbot:

dpkg -i python3-certbot_0.31.0-1+deb10u1_all.deb

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

dpkg: зависимости пакетов не позволяют настроить пакет python3-certbot:
 python3-certbot зависит от python3-acme (>= 0.29.0~), однако:
  Пакет python3-acme не установлен.
 python3-certbot зависит от python3-configargparse (>= 0.10.0), однако:
  Пакет python3-configargparse не установлен.
 python3-certbot зависит от python3-josepy, однако…

… выполняем команду:

apt install -f

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

dpkg -I python3-certbot_0.31.0-1+deb10u1_all.deb

Будет выполнена установка зависимостей. После устанавливаем скачанные пакеты:

dpkg -i python3-certbot_0.31.0-1+deb10u1_all.deb

dpkg -i certbot_0.31.0-1+deb10u1_all.deb

7) на сильно устаревшие системы, например CentOS 6 / Ubuntu 14.04 / Debian 8:

Создадим каталог, в котором будет храниться утилита и переходим в него:

mkdir /opt/certbot

cd /opt/certbot

Загружаем утилиту и разрешаем ее запуск:

wget https://raw.githubusercontent.com/certbot/certbot/7f0fa18c570942238a7de73ed99945c3710408b4/letsencrypt-auto-source/letsencrypt-auto -O /opt/certbot/letsencrypt-auto

chmod a+x ./letsencrypt-auto

Для удобства, делаем симлинк:

ln -s /opt/certbot/letsencrypt-auto /usr/local/sbin/certbot

Запустим команду:

certbot

При первом запуске certbot он автоматически предложит доустановить необходимые зависимости — соглашаемся.

LetsEncrypt-Win-Simple для Windows

На сайте GitHub скачиваем win-acme pluggable для нужной разрядности операционной системы:

Картинка с сайта: www.dmosk.ru

Раcпаковываем скачанный архив в любую папку.

Первое получение сертификата

Linux

1. Если мы подтверждаем право на домен при помощи веб-сервера, выполняем команду с таким синтаксисом:

certbot certonly —webroot —agree-tos —email <почта администратора домена> —webroot-path <путь до каталога с файлами проверки> -d <домен 1> -d <домен 2> -d …

* где:

• certonly — запрос нового сертификата;
• webroot — проверка будет выполняться на основе запроса к корню сайта;
• agree-tos — даем согласие на лицензионное соглашение;
• email — почтовый адрес администратора домена;
• webroot-path — каталог в системе Linux, который является корневым для сайта;
• d — перечисление доменов, для которых запрашиваем сертификат.

а) Пример запроса при использовании веб-сервера NGINX:

certbot certonly —webroot —agree-tos —email postmaster@dmosk.ru —webroot-path /usr/share/nginx/html/ -d dmosk.ru -d www.dmosk.ru

б) Пример запроса при использовании веб-сервера Apache:

certbot certonly —webroot —agree-tos —email postmaster@dmosk.ru —webroot-path /var/www/html/ -d dmosk.ru -d www.dmosk.ru

После успешного выполнения команды, сертификаты будут созданы в каталоге /etc/letsencrypt/archive/dmosk.ru, а также симлинки на них в каталоге /etc/letsencrypt/live/dmosk.ru. При настройке приложений, стоит указывать пути до симлинков, так как при обновлении файлы в первом каталоге будут меняться, во втором — нет. Публичный ключ будет с именем cert.pem, а приватный — privkey.pem.

2. При подтверждении права на домен с TXT-записью:

certbot certonly —manual —agree-tos —email postmaster@dmosk.ru —preferred-challenges=dns -d dmosk.ru -d www.dmosk.ru

* где:

• certonly — запрос нового сертификата;
• manual — проверка домена вручную.
• preferred-challenges — указывает метод проверки домена.
• agree-tos — даем согласие на лицензионное соглашение;
• email — почтовый адрес администратора домена;
• d — перечисление доменов, для которых запрашиваем сертификат.

На запрос подтверждения отвечаем Y — система выдаст что-то на подобие:

* Данное сообщение говорит, что мы должны создать TXT-запись _acme-challenge.dmosk.ru со значением W2SC9b88y2j2oUjhxVgS7Bphph9g5PqhkBq9KiWkLTm.

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

Windows

Открываем командную строку от администратора и переходим в распакованный каталог. Например, если архив распакован на диск C, выполняем:

cd C:\win-acme.v2.1.6.773.x64.pluggable

* где 2.1.6.773.x64 — моя версия утилиты.

Запускаем wacs:

wacs.exe

Если запускаем в Powershel, то так:

.\wacs.exe

Утилита формирует бинарный сертификат для Windows, но если мы хотим получить файлы в формате pem, вводим:

wacs.exe —store pemfiles —pemfilespath C:\Certificates

* где pemfilespath — путь до каталога, в котором должны оказаться файлы сертификата.

Откроется меню с выбором действия — вводим N, чтобы создать новый сертификат:

Картинка с сайта: www.dmosk.ru

Обратите внимание, что в зависимости от версии win-acme, некоторые пункты могут отличаться. Внимательно просмотрите варианты.

Выбираем сайт в IIS, который отвечает на запросы нашего домена (в нашем случае, это единственный Default Web Site, то есть 1):

Картинка с сайта: www.dmosk.ru

Если для сайта создано несколько привязок, выбираем 3, чтобы создать сертификаты для всех:

Вводим email адрес и подтверждаем корректность данных:

Картинка с сайта: www.dmosk.ru

Утилита создаст необходимый каталог для проверки домена, запросит проверку, получит сертификат, добавит привязку к сайту по 443 порту с добавлением полученного сертификата и создаст в планировщике задание на автоматическое продление сертификата.

Автоматическое продление

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

Linux

Открываем на редактирование cron и добавляем следующее:

crontab -e

Если система вернет ошибку crontab: command not found, устанавливаем пакет cron и запускаем сервис.

а) Для deb-систем:

apt install cron

б) Для rpm-систем:

yum install cron

systemctl enable crond —now

Прописываем строку.

0 0 * * 1,4 /usr/bin/certbot renew —noninteractive

* в данном примере проверка и продление сертификата будет выполняться по понедельникам и четвергам (1,4) в 00:00.

Команда certbot renew проверяет для всех наших сертификатов срок окончания, и если осталось менее 30 дней, запрашивает новый, сохраняет его в каталоге /etc/letsencrypt/archive/<домен> и обновляет симлинк.

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

vi /etc/letsencrypt/cli.ini

И добавляем строку с командной перезапуска нужного нам приложения, например:

…
deploy-hook = systemctl reload nginx

Windows

Настройка задания на автоматическое продление создается при получении сертификата. Проверить задание можно в планировщике заданий Windows:

Используем docker

Рассмотрим отдельный способ получить сертификат, если у нас на компьютере нет веб-сервера, но работает docker. В этом случае, мы можем запустить контейнер certbot, и выполнить в нем все необходимые процедуры.

Запускаем контейнер certbot/certbot и выполняем в нем команду certonly:

docker run -it —rm —name certbot -p 80:80 -v «/etc/letsencrypt:/etc/letsencrypt» -v «/var/lib/letsencrypt:/var/lib/letsencrypt» certbot/certbot certonly

На первом шаге нас спросят, в каком режиме включить certbot — выбираем вервый (запуск веб-сервера):

How would you like to authenticate with the ACME CA?
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
1: Runs an HTTP server locally which serves the necessary validation files under
the /.well-known/acme-challenge/ request path. Suitable if there is no HTTP
server already running. HTTP challenge only (wildcards not supported).
(standalone)
2: Saves the necessary validation files to a .well-known/acme-challenge/
directory within the nominated webroot path. A seperate HTTP server must be
running and serving files from the webroot path. HTTP challenge only (wildcards
not supported). (webroot)
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 1

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

Enter email address (used for urgent renewal and security notices)
 (Enter ‘c’ to cancel): master@dmosk.ru

Принято лицензионное соглашение:

Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
(Y)es/(N)o: Y

Подписка на рассылки о статусе сертификатов:

Would you be willing, once your first certificate is successfully issued, 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 our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
(Y)es/(N)o: N

* Y если хотим получать рассылки или N — чтобы контролировать процесс без оповещений на почту.

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

Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter ‘c’ to cancel): dmosk.ru www.dmosk.ru

* как и в случае с обысной проверкой, данные имена должны вести на наш сервер, на котором запускается docker-контейнер.

Если операция прошла успешно, мы должны увидеть:

…
Successfully received certificate.
…

Для продления сертификатов с помощью docker вводим команду:

docker run -it —rm —name certbot -p 80:80 -v «/etc/letsencrypt:/etc/letsencrypt» -v «/var/lib/letsencrypt:/var/lib/letsencrypt» certbot/certbot renew

Wildcard

С марта 2018 года появилась возможность получить бесплатный сертификат на все поддомены, например, mail.dmosk.ru, test.dmosk.ru, admin.dmosk.ru (*.dmosk.ru).

Особенности получения Wildcard от Let’s Encrypt:

1. Подтвердить право использования доменом можно только с помощью DNS — таким образом, затрудняется процесс автоматического продления. Нужно использовать плагины, которые позволяют автоматически создавать нужную запись на DNS, но они доступны далеко не для всех поставщиков услуг DNS. В противном случае, обновлять Wildcard нужно вручную.
   Также, некоторые панели управления хостингом, например ISP Manager с версии 5 могут управлять процессом получения Wildcard от Let’s Encrypt с возможностью автоматического продления (но необходимо, чтобы домен обслуживался на данном хостинге).
2. Время действия сертификата также ограничено 3 месяцами.

Certbot

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

certbot —version

… если версия ниже, обновляем ее командами:

а) для CentOS / Red Hat:

yum update certbot

б) для Ubuntu / Debian: 

apt update

apt install —only-upgrade certbot

Процесс получения

Процесс очень похож на процесс получения сертификата с подтверждением домена в DNS.

Вводим команду:

certbot certonly —manual —agree-tos —email master@dmosk.ru —server https://acme-v02.api.letsencrypt.org/directory —preferred-challenges=dns -d dmosk.ru -d *.dmosk.ru

* обратим внимание на 2 детали: 1) мы добавили опцию server, чтобы указать, на каком сервере Let’s Encrypt должна проходить проверка DNS; 2) мы получаем сертификат как для *.dmosk.ru, так и самого dmosk.ru, так как первое не включает второго.

… система попросит создать TXT-запись в DNS, который обслуживает наш домен:

* в данном примере система попросила создать TXT-запись _acme-challenge.dmosk.ru со значением DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI.

Заходим в панель управления DNS и создаем нужную запись. Если у нас свой сервер DNS, например, bind, то строка будет такой:

; TXT
_acme-challenge IN      TXT     DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI

Не торопимся нажимать Enter — после настройки DNS нужно немного времени (пару минут), чтобы настройка применилась. Проверить появление записи можно командой с рабочего компьютера:

nslookup -type=txt _acme-challenge.dmosk.ru 8.8.8.8

Как только видим, что настройки применились, нажимаем Enter — если это наш первый запрос Wildcard для данного домена, то система нас попросит создать еще одну запись — повторяем процедуру, создав в DNS вторую запись TXT.

Если все сделали правильно, то увидим:

… сертификат получен.

Полезные команды

Рассмотрим некоторые полезные команды утилиты certbot для работы с сертификатами Let’s Encrypt.

1. Показать группы сертификатов:

certbot certificates

2. Удалить сертификат:

certbot delete -d dmosk.ru

После получения сертификата мы не сможем экспортировать его с закрытым ключом. Мы можем изменить поведение, открыв файл settings.json в распакованном каталоге win-acme. Находим параметр PrivateKeyExportable и задаем ему значение:

«PrivateKeyExportable»: true,

После обновляем сертификат:

.\wacs.exe —renew —force

Или без обновления сертификата мы можем найти файл .pfx в каталоге: %programdata%\win-acme\$baseuri$\certificates.

Пароль для pfx можно найти в интерактивном меню wacs:

Manage Renewals > Show details

Сертификат Let’s Encrypt для почтового сервера MS Exchange

В комплекте установленного нами LetsEncrypt-Win-Simple для Windows идет скрипт ImportExchange.v2.ps1. Он нужен для импорта сертификата в конфигурацию почтового сервера MS Exchange.

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

Допустим, что адрес подключения к серверу будет exchange.dmosk.ru. Тогда получить сертификат и импортировать его в Exchange можно командой:

wacs.exe —source manual —host exchange.dmosk.ru,autodiscover.dmosk.ru —store centralssl,certificatestore —certificatestore My —acl-fullcontrol «network service,administrators» —centralsslstore «C:\SSL» —installation iis,script  —installationsiteid 1 —script «./Scripts/ImportExchange.v2.ps1» —scriptparameters «‘{CertThumbprint}’ ‘IIS,SMTP,IMAP’ 1 ‘{CacheFile}’ ‘{CachePassword}’ ‘{CertFriendlyName}'»

* данная команда запросит сертификат для узлов exchange.dmosk.ru и autodiscover.dmosk.ru, сохранит нужные файлы в каталоге C:\SSL и импортирует полученные ключи в Microsoft Exchange Server.

Если мы запускаем команду в оболочке PowerShel, клманда должна начинаться с:

.\wacs.exe …

После успешного выполнения команды, заходим в консоль управления сервером, переходим на вкладку управления сертификатами. В списке мы должны увидеть полученную последовательность от Let’s Encrypt. Кликаем по ней и назначаем сертификат для нужных служб Exchange (как правило, SMTP, IIS).

Возможные ошибки

Рассмотрим некоторые ошибки, с которыми мы можем столкнуться.

1. Missing command line flag or config entry for this setting

Ошибка появляется при попытке обновить сертификат для одного или нескольких доменов.

Причина: при обновлении сертификата, утилита certbot ищет настройки в конфигурационном файле /etc/letsencrypt/renewal/<имя домена>.conf. Если в данном файле не будет определена конфигурация для webroot_map, мы получим данную ошибку.

Решение:

Открываем конфигурационный файл для домена, например:

vi /etc/letsencrypt/renewal/dmoks.ru.conf

Находим опцию webroot_map (как правило, в самом низу). Либо она будет пустой, либо указывать на неправильный путь. Исправляем это:

dmoks.ru = /usr/share/nginx/html

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

Пробуем обновить сертификат.

2. ACMEv1 is deprecated and you can no longer get certificates from this endpoint

Ошибка появляется при попытке запросить или обновить сертификат. Полный текст ошибки:

Attempting to renew cert (xxx) from /etc/letsencrypt/renewal/xxx.conf produced an unexpected error: urn:acme:error:serverInternal :: The server experienced an internal error :: ACMEv1 is deprecated and you can no longer get certificates from this endpoint. Please use the ACMEv2 endpoint, you may need to update your ACME client software to do so. Visit https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/27 for more information.. Skipping.

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

Решение: обновляем утилиту certbot.

а) Для Ubuntu/Debian:

apt update

apt —only-upgrade install certbot

б) Для Rocky Linux/CentOS:

yum update certbot

3. Remote error: tls: handshake failure

Ошибка появляется при попытке запросить или обновить сертификат.

Причина: Let’s Encrypt отключил устаревшие наборы шифров TLS во время проверки.

Решение: если проверка выполняется на веб через https, то нам потребуется, чтобы последний работал с TLS современной версии. На момент обновления данной инструкции, 1.3.

Чтобы решить проблему, необходимо обновить веб-сервер до актуальной версии. А также убедиться, что в настройках не указаны конкретные шифры без нужной версии. Например, если в NGINX будет настройка:

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

… то мы получим ошибку. Для ее решения нужно добавить шифр:

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

И не забываем перезапустить nginx:

nginx -t && nginx -s reload

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

Другие полезные материалы:

1. Примеры редиректов в NGINX.

2. Настройка Apache + SSL для работы сайта по HTTPS.

3. Установка Docker на Linux.

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

Чтобы этого избежать, был создан протокол HTTPS, который работает благодаря SSL/TLS-сертификатам. 

Картинка с сайта: timeweb.cloud

HTTPS (HyperText Transfer Protocol Secure) — протокол передачи данных, который поддерживает шифрование при помощи криптографических протоколов SSL/TLS. По своей сути это расширенная версия обычного HTTP, на основе которого работает интернет.

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

По умолчанию все запросы HTTPS используют для подключения 443 порт. 

cloud

SSL и TLS — в чём разница?

В 90-х годах прошлого века компания Netscape разработала SSL-сертификат, чтобы обезопасить интернет-соединение. Но уже в 1999 году были произведены существенные доработки сертификата, потому что в его начальных версиях было немало недостатков. Такая новая версия получила название TLS — transport layer security — защита транспортного уровня. Но для того, чтобы не путать пользователей, разработчики допустили использование и старого, и нового названий. В официальной документации вы вероятнее всего встретите аббревиатуру TLS, но в этой статье мы используем более привычное SSL.

Ключ шифрования

Ещё одна очень важная роль SSL-сертификата — шифровать данные. Когда браузер понимает, что с сайтом всё в порядке, и устанавливает соединение, начинается обмен шифрами. Криптографическое шифрование бывает ассиметричным или симметричным.

Асиметричное шифрование

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

Картинка с сайта: timeweb.cloud

Симметричное шифрование

У обеих сторон есть один ключ, данные они шифруют с его помощью, при этом он годится как для шифрования, так и для расшифровки. Но перед этим между клиентом и сервером уже должно быть установлено соединение.

Картинка с сайта: timeweb.cloud

Let’s Encrypt — центр сертификации, который выдаёт бесплатные SSL-сертификаты. С его помощью можно легко и быстро обезопасить сайт с помощью HTTPS-протокола. Его простота заключается в том, что практически за все шаги отвечает специальный клиент — certbot, который автоматизирует все действия с сертификатом. 

Однако несмотря на всю простоту установки и работы с сертификатами Let’s Encrypt, у них есть существенные минусы. Во-первых, его можно получить только на 90 дней, дальше придётся обновлять, тогда как платные сертификаты можно выпустить на срок до трёх лет. Во-вторых, они рассчитаны только на один домен и не проверяют компанию, которой принадлежит домен. В-третьих, — это самое важное для коммерческого проекта — Let’s Encrypt не несёт ответственность за ваши данные, вы не получаете никаких финансовых гарантий; если случится взлом бесплатных сертификатов, ущерб никто не возместит.

Но сертификаты Let’s Encrypt — отличный вариант для небольших проектов, для сайтов, которые находятся на стадии разработки или для внутренней инфраструктуры.

В этой статье мы рассмотрим, как установить бесплатный сертификат Let’s Encrypt для Nginx в Ubuntu 20.04, а также настроим его автоматическое продление. 

Требования

В этой статье нам понадобится сервер Ubuntu 20.04, который вы можете заказать на timeweb.cloud с настроенным пользователем, которому доступны привилегии sudo. На этом сервере должен быть установлен и сконфигурирован Nginx и виртуальный хост для него.

Кроме этого вы должны обладать зарегистрированным доменным именем. Вы можете купить его с помощью любого регистратора доменных имён. В нашем примере мы используем домен example.com. 

Для домена должны быть корректно настроены А-записи. В нашем случае мы установим сертификат на example.com, а также защитим www.example.com. Поэтому нужно убедиться в том, что существует две А-записи, где оба этих домена указывают на публичный адрес вашего сервера.

Установка Certbot

На официальном сайте certbot рекомендуют устанавливать через snap. Основное отличие от установки deb-пакета через менеджер apt в том, что snap устанавливает приложение сразу со всеми зависимостями, которые будут использоваться только им. Такой способ помогает избежать проблем с версиями дистрибутивов, но приложение займёт больше места на диске и будет дольше запускаться.

В нашем руководстве мы установим пакет классическим методом,так как никаких проблем с версиями зависимостей cerbot на нашем новом, «чистом» сервере нет. Если вы хотите использовать snap, воспользуйтесь официальным руководством.

В первую очередь нужно обновить индекс пакетов:

sudo apt update && sudo apt upgrade -y

Далее можно устанавливать Cerbot:

sudo apt install certbot python3-certbot-nginx

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

Конфигурация Nginx

Для автоматизации всех действий с помощью certbot вы должны соблюдать некоторые правила при написании конфигурации виртуальных хостов nginx. Во-первых, серверный блок для домена, на который вы устанавливаете SSL-сертификат, должен располагаться по адресу /etc/nginx/sites-available/example.com. Во-вторых, в этом файле должна быть настроена директива server_name, которая будет соответствовать доменам, для которых мы настраиваем безопасное соединение. 

Чтобы проверить, соблюдены ли все эти требования, откройте файл с конфигурацией:

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

Теперь найдите в нём строчку:

server_name example.com www.example.com;

Если её нет, вы можете добавить директиву самостоятельно.

После того, как вы завершили проверку или обновление конфигурации, проверьте синтаксис nginx и перезагрузите веб-сервер:

sudo nginx -t
sudo systemctl reload nginx

Теперь certbot точно сможет найти нужную конфигурацию и автоматически её обновить.

Брандмауэр

Если на вашем сервере настроен брандмауэр ufw, нужно дополнительно разрешить трафик HTTPS. При установке Nginx в ufw регистрируется несколько профилей, поэтому вся настройка заключается в том, чтобы вместо профиля Nginx HTTP использовать профиль Nginx Full. 

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)

Получение сертификата SSL

С помощью плагина nginx certbot автоматически изменит конфигурацию нашего веб-сервера и перезагрузит её, когда это потребуется. Для установки сертификата с помощью плагина введите следующую команду:

sudo certbot --nginx -d example.com -d www.example.com

Здесь флаг --nginx отвечает за использование плагина nginx, а домены, для которых устанавливается SSL указываются при помощи опции -d.

При первом запуске certbot предложит вам принять условия обслуживания и запросит адрес электронной почты. Затем он свяжется с сервером Let’s Encrypt для получения сертификата и отправит запрос, чтобы подтвердить, что вы контролируете домен. 

Когда все проверки будут пройдены, certbot спросит у вас, как настроить HTTPS:

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 for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Первый вариант означает, что certbot не станет настраивать автоматическое перенаправление с адреса http:// на https://. Второй — что все запросы будут перенаправлены на безопасный протокол https. В большинстве случаев следует выбирать последний вариант, однако перед этим вы должны убедиться в том, что ваш сайт корректно работает с такими запросами. Если кодовая база ещё не подготовлена, выбирайте первый вариант, перенаправление можно настроить позже.

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

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 2022-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

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

Автоматическое обновление сертификата

Certbot устанавливает сертификаты, которые действительны только в течение 90 дней. Это сделано для безопасности — разработчики из Let’s Encrypt стимулируют администраторов периодически обновлять ключи. 

Однако certbot сам продлевает сертификаты, которые истекают менее, чем через 30 дней. Это происходит при помощи таймера systemd. Статус таймера вы можете узнать с помощью systemctl:

sudo systemctl status certbot.timer

Картинка с сайта: timeweb.cloud

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

sudo systemctl list-timers

В столбце UNIT найдите имя таймера для certbot.

NEXT                        LEFT          LAST                        PASSED            UNIT                           ACTIVATES
Mon 2023-11-06 19:25:00 MSK 8h left       Mon 2023-11-06 08:16:00 MSK  2h ago           snap.certbot.renew.timer       snap.certbot.renew.service

Скопируйте его и просмотрите статус:

sudo systemctl status snap.certbot.renew.timer

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

sudo certbot renew --dry-run

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

Картинка с сайта: timeweb.cloud

Заключение

В этой статье мы рассмотрели основные принципы работы https и разобрались, зачем он нужен. На тестовый домен example.com и его поддомен поставили SSL-сертификат с помощью утилиты certbot — так наглядно проверили, как происходит установка Let’s Encrypt в Ubuntu.

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

Let’s Encrypt — это центр сертификации (англ. certification authority, CA), предоставляющий лёгкий способ получения и установки TLS/SSL-сертификатов, обеспечивающих возможность использования протокола HTTPS на веб-сервере. Работа с Let’s Encrypt упрощена наличием клиента Certbot, который автоматизирует большую часть работы. Тем не менее, бесплатный SSL-сертификат можно установить на веб-сервер вручную, независимо от его конфигурации.

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

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

Картинка с сайта: tproger.ru

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

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

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

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

После регистрации домена убедитесь, что создана запись A, которая связывает ваш домен и публичный IP-адрес вашего сервера. Это необходимо, потому что Let’s Encrypt проверяет, что вы являетесь владельцем домена, на который выдаётся сертификат. Например, если вы хотите получить сертификат для example.com, такое доменное имя должно указывать на ваш сервер, чтобы проверка прошла. Мы будем использовать доменные имена example.com и www.example.com, поэтому необходимы DNS-записи для обоих доменов.

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

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

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

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

			sudo add-apt-repository ppa:certbot/certbot
		

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

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

			sudo apt-get install certbot
		

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

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

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

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

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

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

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

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

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

			# Добавить в SSL-блок server

location ~ /.well-known {
    allow all;
}
		

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

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

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

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

			sudo systemctl restart nginx
		

Теперь, когда мы знаем webroot-path, можно выполнить запрос на получение SSL-сертификата. При помощи ключа -d указываются доменные имена. Если вы хотите использовать единый сертификат для нескольких доменных имен (например, example.com и www.example.com), не забудьте добавить их все. Также убедитесь, что вы заменили значения webroot-path и доменные имена на соответствующие вашим:

			sudo certbot certonly --webroot --webroot-path=/var/www/html -d example.com -d www.example.com
		

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

			# Пример сообщения

IMPORTANT NOTES:

— Congratulations! Your certificate and chain have been saved at
  /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will expire
  on 2017-07-26. 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 lose your account credentials, you can recover through e-mails
  sent to sammy@example.com.

— 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.

— 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
		

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

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

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

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

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

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

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

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

			sudo ls -l /etc/letsencrypt/live/ваше_доменное_имя/
		

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

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

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

			sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
		

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

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

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

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

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

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

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

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

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

			sudo nano /etc/nginx/snippets/ssl-example.com.conf
		

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

			ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
		

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

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

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

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

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

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

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

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

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

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

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

И, наконец, почитайте о протоколе HTTP Strict Transport Security, или HSTS. Он обеспечивает повышенную безопасность, но его некорректное использование может привести к серьезным последствиям. В этом руководстве мы отключим заголовочный файл по умолчанию, но вы можете не делать этого, если уверены, что понимаете последствия:

			# Источники: https://cipherli.st/
# и https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# отключаем заголовочный файл HSTS
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;
		

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

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

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

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

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

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

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

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

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

			server {
 listen 80 default_server;
 listen [::]:80 default_server;

# Конфигурация SSL

# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;

. . .
		

Изменим текущую конфигурацию так, чтобы незашифрованные HTTP-запросы автоматически перенаправлялись на шифрованный HTTPS. Такой способ обеспечивает лучшую безопасность. Если вы хотите разрешить и HTTP-, и HTTPS-трафик, используйте альтернативную конфигурацию, представленную в следующем разделе.

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

			server {
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name example.com www.example.com;
 return 301 https://$server_name$request_uri;
}

# Конфигурация SSL

# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;

. . .
		

Следующим шагом необходимо открыть новый блок server сразу за текущим, чтобы оставшаяся часть конфигурации попала в него. Мы можем раскомментировать обе директивы listen, использующие порт 443. К этим строкам можно добавить http2, чтобы включить HTTP/2 внутри блока. После этого нам останется подключить оба настроенных нами сниппета в файл:

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

			server { 
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name example.com www.example.com;
 return 301 https://$server_name$request_uri;
}

server {

# Конфигурация SSL

listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-example.com.conf;
include snippets/ssl-params.conf;

. . .
		

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

Альтернативная конфигурация: разрешаем HTTP- и HTTPS-трафик

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

			server {
 listen 80 default_server;
 listen [::]:80 default_server;
 listen 443 ssl http2 default_server;
 listen [::]:443 ssl http2 default_server;

 server_name example.com www.example.com;
 include snippets/ssl-example.com.conf;
 include snippets/ssl-params.conf;

. . .
		

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

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

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

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

Вероятно, результат будет выглядеть следующим образом, означая, что на сервере разрешён только 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’
		

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

			Status: active

To              Action            From
--              ------            ----
OpenSSH         ALLOW             Anywhere
Nginx Full      ALLOW             Anywhere
OpenSSH (v6)    ALLOW             Anywhere (v6)
Nginx Full (v6) ALLOW             Anywhere (v6)
		

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

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

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

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

			nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
		

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

			sudo systemctl restart nginx
		

Теперь TLS/SSL-сертификат от Let’s Encrypt на месте и файрвол разрешает трафик на портах 80 и 443. На этом этапе протестируйте работоспособность TLS/SSL-сертификата, зайдя на ваш домен в браузере по HTTPS.

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

			# Наберите в браузере:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com
		

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

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

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

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

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

			. . . 
15 3 * * * /usr/bin/certbot renew --quiet --renew-hook "/bin/systemctl reload nginx"
		

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

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

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

Заключение

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

Защита веб-сервера Apache с Let’s Encrypt — это просто. В нашей статье вы найдёте подробные инструкции для Ubuntu 20.04 и 22.04, а также узнаете, как автоматизировать обновление сертификатов и настроить современные алгоритмы шифрования. 

Это не просто инструкция по настройке HTTPS и обеспечению безопасности Apache с помощью Let’s Encrypt. Вы узнаете, как избежать скрытых уязвимостей, выбрать современные алгоритмы шифрования и автоматизировать обновление сертификатов. Даже если вы впервые настраиваете SSL, после прочтения ваш сервер будет соответствовать требованиям безопасности 2025 года.

Установка и настройка Certbot: первый шаг к защищённому сайту

Чтобы Apache начал работать по HTTPS, необходимо получить SSL-сертификат. Let’s Encrypt предоставляет его бесплатно, но сертификат нужно обновлять каждые 90 дней, а делать это вручную — не лучшее решение.

Именно здесь на помощь приходит Certbot — инструмент, который автоматизирует получение и продление сертификатов. Рассказываем, как подготовить систему, установить и настроить Certbot.

Важно!

Все описанные ниже команды выполняются либо с sudo, либо из-под учётной записи root.

Подготовка системы

Любая настройка или установка ПО начинается с обновления пакетов. Команда, которая синхронизирует локальную базу данных пакетов с репозиториями Ubuntu и устанавливает последние обновления безопасности:

apt update && apt upgrade

Пропуск этого шага может привести к конфликтам версий. Например, старые зависимости Apache не позволят активировать модуль mod_ssl, критичный для работы HTTPS.

После обновлений установите Apache, если он ещё не установлен и настроен:

apt install apache2  

Затем активируйте mod_ssl — без него веб-сервер не сможет обрабатывать зашифрованные соединения:

a2enmod ssl 
systemctl restart apache2  

Если модуль не включится, проверьте логи:

journalctl -u apache2

Частая ошибка на этом этапе связана с занятостью порта 443 другим приложением (например, Nginx или Docker-контейнером).

Установка Certbot с помощью Apt и Snap

Certbot можно установить с помощью Apt и Snap. Разработчики Let’s Encrypt рекомендуют использовать Snap — это гарантирует актуальность версии и отсутствие конфликтов с системными пакетами.

Ubuntu 20.04

На Ubuntu 20.04 Certbot проще всего установить через стандартный репозиторий Apt (но готовьтесь к тому, что версия может быть устаревшей из-за возможных задержек в обновлениях):

apt install certbot python3-certbot-apache

Для актуальных функций потребуется добавить PPA-репозиторий:

add-apt-repository ppa:certbot/certbot 
apt update

И только затем переходите к установке.

Ubuntu 22.04

Для Ubuntu 22.04 официальная документация рекомендует устанавливать Certbot через Snap. Сначала обновите Snap-сервис:

snap install core 
snap refresh core  

Если Snap не установлен, добавьте его командой:

apt install snapd

Затем установите сам Certbot:

snap install --classic certbot  

Флаг —classic отключает изоляцию Snap-пакета, что необходимо для доступа к системным файлам Apache. После установки создайте символьную ссылку, чтобы Certbot был доступен из любой директории:

ln -s /snap/bin/certbot /usr/bin/certbot  

Если возникнет ошибка «Permission denied», проверьте права на /usr/bin/ через ls -l /usr/bin/ | grep certbot и убедитесь, что у пользователя есть права на запись.

Пакет python3-certbot-apache из Apt на Ubuntu 22.04 тоже доступен, но менее предпочтителен.

Проверка доступности домена

Let’s Encrypt требует доказательства владения доменом. Certbot автоматически проведёт проверку через HTTP-запросы, для чего должны быть выполнены следующие условия:

• Домен привязан к IP-адресу сервера. Убедитесь, что A-записи в DNS ведут на правильный адрес. Сделать это можно через dig ваш_домен.ru +short. Также проверьте A-запись для домена с префиксом WWW.
• Порты 80 и 443 открыты. Брандмауэр Ubuntu (UFW) часто блокирует их по умолчанию. Разрешите трафик командой:

ufw allow 'Apache Full' 
ufw reload  

Если порты остаются закрытыми, просмотрите статус файрвола:

ufw status

В выводе должны быть строки:

Иногда конфликтуют правила, добавленные вручную — в таком случае удалите их:

ufw delete [номер_правила]

Что делать, если Certbot не проходит проверку

Ошибка «Failed to connect to host for DVSNI challenge». Убедитесь, что Apache слушает порт 80:

ss -tulpn | grep ':80'

Если служба запущена, но порт не открыт, перезагрузите Apache:

systemctl restart apache2

Ошибка «DNS problem: NXDOMAIN looking up A». Проверьте DNS-записи через специальные сервисы, например DNS Checker. Возможно, изменения ещё не распространились — подождите 10-15 минут.

После успешной настройки можно переходить к генерации сертификата.

Получение SSL-сертификата и настройка Apache

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

Генерация сертификата

Запустите команду:

certbot --apache  

Certbot выполнит несколько действий автоматически:

• Просканирует виртуальные хосты Apache в /etc/apache2/sites-available/, чтобы определить, для каких доменов запрашивать сертификаты. Если у вас несколько доменов, появится интерактивное меню — укажите нужные через пробел.
• Проведёт проверку домена через протокол ACME. Для этого временно создаст файл в директории .well-known/acme-challenge/ вашего веб-корня и обратится к нему через HTTP. Если файл недоступен, сертификат не будет выдан.
• Сгенерирует сертификаты и сохранит их в /etc/letsencrypt/live/ваш_домен/. Здесь появятся файлы fullchain.pem (сертификат и цепочка доверия) и privkey.pem (приватный ключ).
• Настроит Apache на использование HTTPS. Certbot добавит в конфиг виртуального хоста блок <VirtualHost *:443> с параметрами SSLEngine on, SSLCertificateFile и SSLCertificateKeyFile, а также перенаправит HTTP-трафик на HTTPS через Redirect permanent / https://ваш_домен/.

В процессе вам нужно будет согласиться с условиями обслуживания и указать необходимую информацию:

• e-mail (нужен для получения уведомлений, поэтому указывайте актуальный адрес);
• дать согласие или отказаться от получения рассылки;
• указать домены, для которых нужно включить HTTPS; если вы активизируете HTTPS для всех доменов в списке, то оставьте поле пустым.

Ручная проверка конфигурации

После завершения работы Certbot обновит конфиг Apache.

Найдите его в директории:

/etc/apache2/sites-available/ваш_домен-le-ssl.conf

Проверьте:

• SSLCertificateFile должен указывать на fullchain.pem;
• SSLCertificateKeyFile — на privkey.pem;
• Директива Redirect — перенаправлять с HTTP на HTTPS.

Если перенаправление не настроено, добавьте в HTTP-виртуальный хост (файл ваш_домен.conf):

Redirect permanent / https://ваш_домен/  

После внесения изменений перезагрузите Apache:

systemctl reload apache2  

Если служба не запустится, проверьте синтаксис конфигов:

apache2ctl configtest

Частая ошибка — опечатка в путях к сертификатам.

Обновление Let’s Encrypt

Сертификаты Let’s Encrypt действуют 90 дней, но вручную обновлять их не придётся. Certbot добавляет задачу в cron — скрипт выполняется дважды в день и обновляет сертификаты, срок действия которых заканчивается в течение 30 дней. Проверить работу планировщика можно командой, запускающей пробное обновление:

certbot renew --dry-run  

Если вывод содержит сообщение «Congratulations, all simulated renewals succeeded», всё настроено верно. Для принудительного обновления выполните:

certbot renew --force-renewal  

При установке через Snap используется systemd timer (certbot.timer), а не cron. Проверка Snap-установки:

systemctl list-timers | grep certbot

Важно: частые обновления (чаще 50 раз в неделю) могут привести к временной блокировке со стороны Let’s Encrypt.

Как диагностировать ошибки при обновлении:

• «No renewals were attempted» — не найдены сертификаты для обновления. Убедитесь, что они были получены через certbot certificates.
• «Challenge failed for domain» — домен недоступен для проверки. Проверьте, открыты ли порты 80/443 и корректны ли DNS-записи.
• «Permission denied» в /etc/letsencrypt/ — Certbot требует прав на запись. Исправьте через команду:

chown -R root:root /etc/letsencrypt/

Проверка работоспособности HTTPS

Убедитесь, что сайт доступен по HTTPS:

• Откройте его в браузере — значок замка в адресной строке или «https» в начале URL подтвердит успех. Также вы можете кликнуть на «Сведения о сайте» и просмотреть информацию о действующем сертификате.
• Проверьте сертификат и срок его действия через консоль:

echo | openssl s_client -connect ваш_домен:443 2>/dev/null | openssl x509 -noout -dates  

Теперь Apache защищён, но забота о безопасности на этом не заканчивается. В следующем разделе мы настроим современные шифры, включим HSTS и проверим конфигурацию через независимые сервисы.

Усиление безопасности Apache и SSL/TLS: от базовой защиты до профессиональных настроек

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

Оптимизация параметров шифрования

Протоколы TLS 1.0 и 1.1 давно считаются небезопасными — они уязвимы для некоторых видов атак, например BEAST и POODLE. Let’s Encrypt по умолчанию выдаёт сертификаты, совместимые с TLS 1.2 и 1.3, но Apache может разрешать устаревшие соединения. На Ubuntu 22.04 файл настроек SSL (/etc/apache2/mods-available/ssl.conf) уже может содержать более строгие параметры шифрования (например, TLS 1.0 и 1.1 часто отключены по умолчанию). Но на 20.04 эти настройки иногда приходится менять вручную. Чтобы сделать это, отредактируйте конфиги SSL:

nano /etc/apache2/mods-available/ssl.conf  

Найдите блок SSLProtocol и замените его на:

SSLProtocol -all +TLSv1.2 +TLSv1.3  

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

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256  
SSLHonorCipherOrder on  

Где:

• ECDHE — обеспечивает Perfect Forward Secrecy: даже если злоумышленник получит приватный ключ, он не сможет расшифровать старые сессии;
• AES128-GCM — современный алгоритм шифрования с аутентификацией;
• SSLHonorCipherOrder принудительно выбирает самый безопасный шифр из поддерживаемых клиентом.

После изменений перезагрузите Apache через systemctl reload apache2. Если сайт перестал открываться, проверьте журналы ошибок:

tail -n 50 /var/log/apache2/error.log

Возможно, вы отключили алгоритмы, которые использует ваша аудитория (например, старые Android-устройства).

HTTP Strict Transport Security (HSTS) — защита от downgrade-атак

HSTS — это заголовок, который запрещает браузерам подключаться к сайту по HTTP, даже если пользователь явно введёт этот протокол. Добавьте его в конфиг SSL-хоста:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"  

Где:

• max-age=63072000 — срок действия политики (2 года в секундах);
• includeSubDomains — распространяет HSTS на все поддомены;
• preload — разрешает включение сайта в список HSTS Google (требует отдельной регистрации).

Обратите внимание, что после активации HSTS удалить сайт из кеша браузеров будет невозможно до истечения max-age. Начинайте с небольшого срока (например, max-age=300), и только после тестов увеличивайте его.

Проверка безопасности

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

• SSL Labs (ssllabs.com/ssltest) — проверяет поддерживаемые протоколы, шифры и наличие известных уязвимостей. Цель — достичь оценки «A+».
• Hardenize (hardenize.com) — анализирует не только SSL, но и другие аспекты безопасности (DNSSEC, заголовки CSP).

Консольные команды:

• Проверка поддерживаемых TLS-версий:

openssl s_client -connect ваш_домен:443 -tls1_2  

• Просмотр заголовков ответа:

curl -I https://ваш_домен  

Если тесты показывают уязвимости (например, SSLv3 или RC4), вернитесь к настройкам ssl.conf и убедитесь, что небезопасные алгоритмы отключены.

Резервное копирование

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

tar -czvf /backup/apache_ssl_$(date +%F).tar.gz /etc/apache2/ /etc/letsencrypt/  

Эта команда запакует все конфиги Apache и сертификаты Let’s Encrypt в архив с датой создания. Храните копии на отдельном сервере или в облаке — если атака повредит файлы, вы быстро восстановите работу.

Что делать, если…

• Сайт не открывается после настройки шифров. Вернитесь к старой версии ssl.conf, используя бекап, и проверьте, какие алгоритмы поддерживают ваши пользователи через SSL Labs.
• HSTS блокирует доступ к HTTP. Временно уменьшите значение max-age до 300 секунд и дождитесь истечения предыдущего срока.
• Let’s Encrypt не обновляет сертификаты. Убедитесь, что задача в cron активна:

systemctl status cron

А также что нет ошибок в логах:

grep certbot /var/log/syslog

Заключение

Защита Apache с помощью Let’s Encrypt — это не просто «замочек» в браузере, это фундамент доверия пользователей к вашему сайту и залог его безопасности. Вы прошли все этапы: от установки Certbot до тонкой настройки шифров и HSTS. Теперь ваш сервер использует актуальные протоколы TLS, автоматически обновляет сертификаты и защищён от большинства известных атак.

Читайте в блоге:

• Установка Java на Ubuntu 22.04 через Apt: полное руководство
• Настройка VPS на Debian 11: пошаговое руководство
• Как установить Joomla на VPS: от простого хостинга до полного контроля