SavePearlHarbor

Как установить бесплатный SSL-сертификат и настроить HTTPS на домене

—

от автора

admin

Привет, Хабр!

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

Проблема даже не в сложности как таковой. Проблема в том, что под “поставить SSL” могут скрываться совершенно разные сценарии.

У кого-то сайт крутится на VPS с nginx, у другого — Apache, у третьего вообще непонятно, куда смотрит домен и почему проверка владения доменом не проходит. По этой причине одна и та же команда из интернета срабатывает с первого раза, а у кого-то заканчивается ошибкой ssl error и потерянным вечером.

Если вы хотите просто прописать команды и жить счастливо, то я предупреждаю: в начале статьи будет много теории. Я, конечно, очень рекомендую прочитать статью полностью, это просто не будет лишним, особенно если вы ставите сертификат впервые. Если же вам нужны просто команды под ваш сценарий — можете листать ниже до блока “Практическая часть”.

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

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

Вообще, почти везде (в том числе и в заголовке этой статьи) говорится о “SSL-сертификате”. Это нормально, но технически сегодня речь уже пойдет о TLS и HTTPS. Для сайта это просто означает, что весь HTTP-трафик идет поверх защищенного TLS соединения. Полностью вдаваться в подробности и разжевывать абсолютно каждый термин не считаю необходимым — статья все-таки создана для облегчения выдачи сертификата

Что вообще нужно для HTTPS

Если совсем упростить, то для корректной настройки HTTPS нам нужно всего несколько вещей.

Во-первых, домен. Именно по нему будет обращаться браузер. Но и в случае, если у вас нет домена, вы все равно сможете опубликовать ваш сайт, который будет доступен по домену с HTTPS, об этом чуть позже в блоке с Amvera.

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

В-третьих, сам сертификат. Его мы будем получать от Let’s Encrypt.

И, наконец, в-четвертых, нужен способ доказать центру сертификации, что домен действительно находится под вашим контролем. Без этого сертификат просто не выдадут. Let’s Encrypt для этого использует ACME и разные способы проверки владения доменом (все будет показано ниже).

Центр сертификации — это организация, которая выпускает сертификаты и выступает доверенной стороной для браузеров. ACME — это протокол, через который клиент вроде Certbot автоматически запрашивает и продлевает сертификаты.

Получается, что настройка HTTPS почти всегда сводится к одной и той же цепочке:

  1. Получение домена и его привязка с помощью DNS-сервера к конкретному серверу;

  2. Проверка владения доменом;

  3. Выпуск сертификата;

  4. Настройка веб-сервера или платформы;

  5. Проверка, что сайт нормально открывается по HTTPS.

Платный ли вообще сертификат?

Тут важно понимать, что сертификаты бывают разные.

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

DV-сертификат — это сертификат с проверкой домена. То есть буквально Domain Validation. Он подтверждает именно контроль над доменным именем, а не юр. статус компании.

Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации. Более того, он выдает именно DV-сертификаты, которых для обычного сайта, лендинга, блога, API или пет-проекта чаще более чем достаточно. Другие сертификаты (OV, EV) уже скорее будут платными и необходимыми для проверки организации. Это уже пойдет корпоративным сайтам, среднему бизнесу, банкам, крупным интернет-магазинам. В этой статье они рассматриваться не будут.
Помимо этого есть IV (Индивидуальная проверка) сертификат. Исходя из названия понятно, что он проверяет личность физического лица, указанного в качестве Субъекта сертификата.

Что еще важно понять до настройки SSL

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

При всем этом нужно осознавать, что сертификат от Let’s Encrypt нужно продлевать. Для домена срок действия сертификата — 90 дней. Но и это не всегда означает, что вам нужно каждые 3 месяца вместо завтрака подключаться по ssh и пытаться продлить сертификат, за вас это будет делать ACME-клиент, если выполнить все необходимые действия и оставить точку входа для проверки владения доменом.

А вы вообще уверены, что вам нужно этим заниматься?

Это, кстати, не придирка и не попытка усложнить вам жизнь. Let’s Encrypt в своем getting started вообще начинает именно с этого: сначала предлагает понять, не получает ли сертификаты ваш хостинг-провайдер или платформа за вас, и только если нет — уже переходить к самостоятельной настройке ACME-клиента.

Это реально важно, ведь именно на этом вопросе статья делится на два разных сценария.

Сценарий 1. Платформа или хостинг берут выпуск ssl-сертификата на себя

Это самый короткий и приятный путь.

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

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

Если ваша задача — просто быстро и нормально запустить сайт по HTTPS, это зачастую лучший вариант.

Сценарий 2. SSL-cертификат нужно получать и настраивать самостоятельно

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

Обычно это сценарий, когда сайт работает на VPS/VDS, а вы сами настраиваете Nginx или Apache. В этом случае сертификат надо:

  1. Запросить;

  2. Пройти проверку владения доменом;

  3. Подключить к веб-серверу;

  4. Настроить редирект на HTTPS;

  5. и не забыть про автопродление.

Естественно, все это вручную делать — лишняя суматоха. Для этого даже сам Let’s Encrypt советует начать с Certbot — одного из самых распространенных ACME-клиентов. Он умеет не только получать сертификат, но и в ряде сценариев (например для nginx или apache) автоматически их встраивать в конфигурацию веб-сервера. С ним все вышеописанные шаги выполняются чуть ли не за 2 минуты и пару команд.

Что проверить перед настройкой сертификата

Тут начинается практическая часть, на которой чаще всего ошибаются. Рекомендую проверить каждый шаг.

1) Домен должен указывать туда, где реально работает сайт

Звучит банально, но именно тут часто прячется проблема. Если домен еще не смотрит на нужный IP-адрес или DNS-записи еще не распространились, сертификат может не выпуститься просто потому, что проверка Let’s Encrypt упрется не в ваш сервер. Практические инструкции по настройке HTTPS для Apache и Nginx как раз начинаются с того, что у домена должны быть корректные DNS-записи, а сам сайт уже должен быть доступен хотя бы по http.

Я ничего не понял, какие еще DNS-записи? Как привязать домен к серверу? Тут все просто. Практически у каждого регистратора доменных имен, будь то РегРу или другой регистратор, есть для каждого домена некий редактор DNS. Это функционал в интерфейсе, позволяющий гибко настраивать DNS-записи.

Если говорить очень по-общему, то DNS — это, по сути, телефонная книга интернета. Человек открывает в браузере google.com, а браузеру нужно понять, на какой сервер вообще идти. Это ведь не обычный IP, по которому можно обратиться, а какой-то набор символов, из которого как-то этот айпи нужно вытянуть. Для этого он смотрит DNS-записи домена. Именно они и подсказывают, что браузеру нужно делать дальше. Простыми словами, DNS-запись — это правило для домена.

Например: “если кто-то открыл example.com, отправь его на IP 111.222.111.222”.

Для настройки сайта и SSL-сертификата вам чаще всего встретятся всего 4 типа записей: A, AAAA, CNAME и TXT.

A-запись — это самая понятная и самая частая. Она просто связывает домен с IPv4-адресом сервера (то есть привычным IP типа 1.2.3.4). IP сервера обычно показан в панели VPS/облака.

AAAA-запись — это почти то же самое, но уже для IPv6-адреса. Она нужна только в том случае, если у вашего сервера действительно есть рабочий IPv6 и вы понимаете, зачем он вам нужен. Если нет — лучше такую запись не добавлять.

CNAME-запись — это уже не привязка к IP, а алиас, то есть псевдоним одного имени для другого. Например: www.mymegasite.com -> mymegasite.com В таком случае www не хранит собственный IP, а просто ссылается на основной домен. Это удобно, если вы хотите, чтобы оба домена вели в одно место.

TXT-запись — это текстовая запись. Именно она часто используется не для “открытия сайта”, а для подтверждения владения доменом. То есть сервис вам прямо говорит: “добавьте вот такой текст в DNS, и я пойму, что домен действительно под вашим контролем”. TXT-записи давно используются для такой проверки. Самый удобный для нас пример: сервис Amvera тоже просит добавить TXT-запись с уникальным текстом к вашему домену для проверки и привязки.

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

  1. Сервис или ACME-клиент проверяет домен через HTTP. То есть он смотрит, отвечает ли нужный сервер по обычному веб-запросу. Причем эта проверка проходит именно по 80 порту, что может вызывать проблемы, если на вашем сервере стоит firewall, запрещающий входящие подключения.

  2. Проверка идет через DNS. Тут как раз и используется TXT-запись. Let’s Encrypt, например, предлагает добавить TXT-запись acme-challenge.<вашдомен>.

После добавления записей важно понимать еще кое-что: DNS не обновляется мгновенно во всем мире. Записи должны распространиться по DNS-серверам, и это может занять время. Обычно это длится до 24 часов, но может и дольше. Часто про это забывают и теряются, если после добавления записи центр сертификации не смог подтвердить владение доменом.

Практическая часть: выписываем SSL-сертификаты для двух сценариев

1. Платформа или хостинг берут выпуск сертификата на себя

Здесь все просто — зависит от платформы, но скорее всего вам просто нужно будет прописать A и TXT запись у регистратора и подождать несколько часов, после чего активировать в ЛК https-домен. В остальном это способ «привязанный к поставщику».

2. Сертификат нужно получать и настраивать самостоятельно

Допустим у вас есть VPS/VDS, домен уже указывает на сервер (то есть есть A-запись с IP вашего сервера), сайт как минимум открывается по http://, а сертификат нужно получить и подключить вручную.

Ниже я показываю команды для сервера VPS/VDS (то есть удаленного сервера) на Linux с доступом по SSH и правами sudo. Для большинства пользователей Let’s Encrypt рекомендует Certbot, а Certbot в официальных инструкциях для Linux советует ставить себя через snap. Для сценариев --nginx, --apache и --webroot предполагается, что сайт уже доступен по HTTP на 80 порту.

Вариант 2.1. Сайт работает на nginx

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

Шаг 1. Устанавливаем Certbot Если certbot уже ставился через пакетный менеджер, официальный сайт рекомендует удалить пакетную установку перед установкой snap-версии, чтобы потом не путались бинарники. Если вы не совсем поняли, о чем я — значит, скорее всего, вам ничего удалять не нужно 🙂

После этого ставим certbot и добавляем удобную ссылку на команду.

sudo apt-get remove certbot # Если certbot уже устанавливался. Если нет - не выполняйте эту командуsudo snap install --classic certbotsudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Если команда snap не найдена, сначала установите snapd

Шаг 2. Выпускаем сертификат и автоматически включаем HTTPS Теперь главный шаг:

sudo certbot --nginx

Именно такую команду Certbot рекомендует для сценария с nginx, если нужно получить сертификат и сразу дать возможность отредактировать конфигурацию веб-сервера.

После выполнения команды Certbot обычно попросит:

  1. Указать email;

  2. Согласиться с условиями Let’s Encrypt;

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

  4. Решить, нужно ли сразу включить редирект с HTTP на HTTPS.

Шаг 3. Проверяем, что все действительно сработало

Теперь открываем ваш сайт по адресу: https://ваш-домен

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

Если не хотите доверять Certbot правку конфига

В таком случае используйте команду:

sudo certbot certonly --nginx

Вариант 2.2. Сайт работает на Apache

С Apache история почти та же. Certbot умеет работать и с ним, причем тоже в автоматическом режиме.

Устанавливаем cerbot так же, как и в варианте 2.1; и выполняем следующую команду:

sudo certbot --apache

Именно эта команда официально рекомендуется для Apache.

Далее вас проведут через тот же диалог:

  1. email;

  2. Соглашение с правилами Let’s Encrypt;

  3. Выбор домена;

  4. Вопрос про редирект на HTTPS.

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

Если хотите получить сертификат, но править конфиг руками:

sudo certbot certonly --apache

Вариант 2.3. Если у вас не nginx и не Apache

Бывает и так, что сайт работает не за nginx и не за apache. В таком случае есть еще две развилки.

Способ 1. Standalone

Если никакой веб-сервер не использует 80 порт, Certbot может временно поднять собственный маленький сервер только ради проверки домена:

sudo certbot certonly --standalone

Еще раз проговорю: 80 порт должен быть доступен извне и не занят другим процессом.

Способ 2. Webroot

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

sudo certbot certonly --webroot

В этом режиме Certbot положит файл проверки в специальный каталог внутри сайта, а веб-сервер просто отдаст его наружу. Но сам Certbot предупреждает: для этого сервер должен корректно отдавать файлы из /.well-known/acme-challenge/.

Например, если ваш webroot находится по адресу /var/www/html, а домен mywebrootsite.ru, то команда будет выглядеть так:

sudo certbot certonly --webroot -w /var/www/html -d mywebrootsite.ru

Вариант 2.4. Если нужен DNS-способ

Когда нужен DNS-способ

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

Но иногда такой путь не подходит. Вот к примеру у вас может быть закрыт 80 порт, сайт может по политике сервиса вообще не отвечать по HTTP или нужен wildcard-сертификат типа *.example.com.

Если сильно упростить, то DNS-способ работает так:

  1. Вы запускаете выпуск сертификата через ACME-клиент;

  2. Let’s Encrypt выдает вашему клиенту специальный challenge-токен;

  3. ACME-клиент просит вас добавить TXT-запись в DNS, обычно по имени acme-challenge.<вашдомен>;

  4. Let’s Encrypt проверяет публичные DNS-сервера и смотрит, появилась ли там нужная запись;

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

На практике тут еще две развилки:

Ручной DNS-способ

Для обычного домена команда будет такой:

sudo certbot certonly --manual --preferred-challenges dns -d ВАШ-ДОМЕН

Для wildcard-сертификата:

sudo certbot certonly --manual --preferred-challenges dns -d ВАШ-ДОМЕН -d '*.ваш-домен'

После выполнения команды Certbot покажет имя записи и текстовое значение для TXT-записи. Вам нужно эту запись добавить, дождаться распространения и вернуться в Certbot, подтверждая продолжение.

Важный минус: сертификаты, выпущенные вручную через --manual не поддерживают автоматическое продление. Для автоматического продления рекомендуется использовать специальные hook-скрипты.

DNS-плагин

Если ваш DNS-провайдер поддерживает Certbot, то можно не добавлять TXT-запись каждый раз. Для этого существуют отдельные DNS-плагины. Такие плагины ставятся отдельно и обычно инструкция для их установки и применения есть на сайте DNS-провайдера. Например: очень удобный DNS-плагин есть у Cloudflare.

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

SSL Error или частые ошибки

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

Но я все же собрал основные причине неполадок.

1. Домен все еще смотрит не туда или DNS еще не разошелся

Это прям самая-самая распространенная причина, особенно если домен вы привязали совсем недавно.

Даже если у вас dig +short домен показывает запись корректно — просто подождите. Очень важно учитывать, что DNS-серверов в мире огромное количество и если в сервере, который находится к вам ближе всего изменение распространилось, то в другом оно может не распространиться.

2. Закрыт 80 порт, а вы пытаетесь пройти HTTP-проверку

Если вы используете обычный HTTP-способ выпуска сертификата, 80 порт обязательно должен быть открыт. Это не рекомендация, а часть механики http-01.

3. Сертификат выпустился, но сайт все равно “небезопасный”

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

Такой сценарий называется mixed content. Это происходит тогда, когда по каким-то причинам вложенная в сайт статика (JS, картинки и т.д.) грузятся по старому http://. Обычно это ошибка в коде.

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

4. Редирект на HTTPS не настроен или работает криво

Бывает и так, что сертификат есть, но http:// продолжает жить. В итоге кто-то попадает на старую http версию, а кто-то на корректную https.

Здесь уже вам просто нужно настроить редирект на уровне веб-сервера, будь то nginx или apache.

Итог настройки HTTPS

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

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

Если же что-то не получилось или в статье есть неточности, пишите комментарии — постараемся рассказать подробнее или исправить неточность.

ссылка на оригинал статьи https://habr.com/ru/articles/1022448/