Направьте домен на сервер и получите SSL-сертификат

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

Интересный шаг - ожидание, потому что именно в нём живут все сбои. При выпуске сертификата проверяется, что имя действительно указывает на сервер, который его запрашивает, а это значит, что сертификат нельзя получить для имени, которое всё ещё разрешается на ваш старый хост, которое припарковано у регистратора, у которого есть запись CAA с указанием другого центра или которое спрятано за CDN с недоступным origin. В этой статье - что делает каждая запись, как проверить то, что видит остальной мир, а не то, что закэшировала ваша собственная машина, и шесть причин, по которым сертификат не выпускается.

Что делает слот прокси#

В тарифы для приложений и сайтов входит слот обратного прокси. Именно он превращает https://app.example.com в соединение с вашим контейнером: принимает запрос на публичном адресе, завершает там TLS и пересылает обычный HTTP-запрос на единственный порт, который слушает ваше приложение.

Два следствия такой схемы важны для остальной части статьи.

Ваше приложение никогда не видит TLS. Оно получает обычный HTTP на своём порту. Поэтому приложение, настроенное перенаправлять каждый запрос без HTTPS на HTTPS, за прокси попадает в бесконечный цикл, и поэтому настоящий адрес клиента приходит в заголовке X-Forwarded-For, а не в самом соединении. Общий случай разобран в статье что делает обратный прокси.

Это HTTP, а не всё подряд. Слот прокси обрабатывает веб-трафик. До игрового сервера так не добраться: серверу Minecraft или Valheim нужно, чтобы имя указывало прямо на адрес сервера через A-запись, а игроки подключались к игровому порту напрямую. Об этом рассказано в статье как привязать домен к игровому серверу, а как скрыть от игроков нестандартный порт - в статье SRV-записи для Minecraft.

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

Какие записи нужны#

Для поддомена - одна запись. Для всего домена обычно две.

На чём спотыкаются:

Apex не может быть CNAME. Спецификация DNS не разрешает CNAME сосуществовать с другими записями, которые обязан иметь apex домена. Многие провайдеры предлагают ALIAS, ANAME или CNAME flattening, чтобы обойти это, и это нормально; если у вашего такого нет, используйте запись A на apex и CNAME на www.

Выберите один основной хост. Обслуживайте сайт либо на example.com, либо на www.example.com, а другой перенаправляйте на него. Если работают оба независимо, ваша выдача в поиске и ваши cookie делятся надвое. Обоснование и правила редиректа есть в статье www или apex: домен и редиректы.

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

Не публикуйте запись AAAA, которую не можете обслужить. Если у вашего сервера нет адреса IPv6, запись AAAA, оставшаяся от прежнего хоста, хуже, чем бесполезна: браузеры и удостоверяющий центр попробуют её первой и потерпят неудачу. Удалите её. Когда IPv6 всё-таки нужен, читайте статью IPv6 и игровые серверы.

Поддомен на каждую службу - дёшево. app.example.com, api.example.com, status.example.com стоят по одной записи и разделяют сертификаты и маршрутизацию. См. поддомены для серверов.

Снизьте TTL до того, как что-то переносить#

У каждой DNS-записи есть TTL - число секунд, на которое резолверу разрешено кэшировать ответ. У большинства провайдеров по умолчанию стоит 3600 или 14400, а это значит, что до одного или четырёх часов часть резолверов продолжает отдавать старый адрес после того, как вы его изменили.

Решение - планировать на шаг вперёд. Минимум за сутки до того, как вы собираетесь менять запись, установите её TTL в 300. Каждый резолвер, обновившийся за это время, подхватит короткое значение, а когда вы внесёте настоящее изменение, мир последует за ним за пять минут, а не за четыре часа. Верните 3600 через день после переезда.

Это разница между переключением, которое занимает минуты, и таким, при котором треть посетителей видит старый сайт до конца дня. И это самое полезное из всего сказанного в этой статье, если вы переносите работающий сайт, причём делать это нужно заранее: снижение TTL в момент изменения ничего не даёт, потому что в кэше уже лежит старый TTL.

Проверяем, что видит мир#

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

# What the record is, from a resolver that is not yours$ dig +short app.example.com A @1.1.1.1203.0.113.10# Follow the delegation from the root, which shows the authoritative answer$ dig +trace app.example.com# Is anything restricting which authority may issue certificates?$ dig +short example.com CAA0 issue "letsencrypt.org"

В Windows без dig первое из этого делает nslookup app.example.com 1.1.1.1. Онлайн-сервисы «DNS checker», опрашивающие два десятка резолверов по всему миру, полезны, чтобы убедиться, что изменение разошлось, и бесполезны для всего остального.

На что смотреть:

• Ответ в точности совпадает с адресом на слоте прокси.
• Рядом нет устаревшей записи AAAA.
• Нет забытой записи CNAME, указывающей на ваш старый хост.
• TTL в полном выводе dig, который показывает, сколько ещё осталось жить текущему закэшированному ответу.

Если dig +trace даёт другой ответ, чем dig @1.1.1.1, то изменение авторитетно и просто ещё не устарело в публичном резолвере. Это нормально, и остаётся только ждать.

Как выпускается сертификат#

Сертификаты выпускает удостоверяющий центр, который сначала проверяет, что имя контролируете вы. Обычный для такого хоста метод - HTTP-проверка: центр запрашивает по порту 80 для этого имени хоста определённый файл в /.well-known/acme-challenge/, и прокси на него отвечает. Если ответ приходит правильный, сертификат выпускается, обычно за секунды.

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

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

Два ограничения, которые стоит знать, прежде чем начинать повторять попытки в цикле. Удостоверяющие центры ограничивают частоту выпуска на домен и на идентичный набор имён, а многократные неудачные проверки засчитываются в отдельный лимит, так что двадцать попыток за час могут заблокировать вас дольше, чем заняло бы простое исправление DNS. Актуальные цифры Let's Encrypt публикует на letsencrypt.org/docs/rate-limits, и они меняются. Устраните причину, а потом попробуйте один раз.

Ещё люди спрашивают о wildcard. Wildcard-сертификату нужна проверка через DNS, а не через HTTP, то есть центру требуется TXT-запись, создаваемая по запросу у вашего DNS-провайдера. Поскольку записи здесь живут у вашего провайдера, а не в нашей панели, практический ответ - добавить в слот конкретные имена, которыми вы пользуетесь. Три поддомена - это три имени и никакой дополнительной работы. Способы проверки как следует разобраны в статье HTTPS и Let's Encrypt простыми словами.

Почему выпуск не удался#

В том порядке, в каком это происходит на самом деле:

1. Имя ещё не разрешается сюда. Самая частая причина с большим отрывом. Проверяйте через dig @1.1.1.1, а не через браузер. Если запись правильная, а ответ неверный, вы находитесь внутри старого TTL, и остаётся ждать.

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

3. Запись CAA запрещает. В записи CAA перечислены центры, которым разрешено выпускать сертификаты для вашего домена. Если она есть и не включает используемый центр, каждый запрос отклоняется - чётко и непонятно. Проверьте командой dig +short example.com CAA. Либо удалите её, либо добавьте нужный центр. Это редкость, но пока не посмотришь, не видно.

4. Впереди стоит CDN в неверном режиме. Если ваш домен проксируется Cloudflare или чем-то подобным, origin всё равно должен быть достижим для проверки. Обычное решение - выключить прокси для этой записи (серое облако), получить сертификат, затем включить обратно и выставить режим origin у CDN в full или strict. Если сделать в другом порядке, получите цикл перенаправлений или ошибку 526. Что оранжевое облако делает и чего не делает, описано в статье Cloudflare для сайтов и игровых серверов.

5. Запись AAAA указывает в никуда. И браузеры, и серверы проверки предпочитают IPv6, если запись AAAA существует. Если она указывает на адрес, который не ваш или на котором ничто не слушает, попытка проваливается до того, как будет опробован IPv4. Удалите её.

6. Имя в слоте не совпадает с именем в записи. Опечатка, точка в конце или app.example.com.example.com, потому что DNS-провайдер дописывает имя зоны к тому, что вы вводите в поле имени. Смотрите на запись так, как её показывает провайдер после сохранения, а не так, как вы её набрали.

После того как HTTPS заработал: редиректы, заголовки и настоящий IP клиента#

Сертификат - это ещё не финиш. Четыре вещи нужно настроить в приложении за прокси.

Доверяйте прокси. Пока вы этого не сделали, каждый запрос выглядит пришедшим с собственного адреса прокси, что ломает ограничение частоты, блокировку злоупотреблений, аналитику и ваши журналы доступа. В Express это app.set("trust proxy", 1); в Django - SECURE_PROXY_SSL_HEADER; в Laravel есть middleware TrustProxies; WordPress за прокси обычно требует нескольких строк в wp-config.php, которые читают X-Forwarded-Proto. Версия для Node в контексте есть в статье развёртывание приложения Node.js из GitHub.

Не принуждайте к HTTPS внутри приложения. Прокси говорит с вашим контейнером по обычному HTTP, поэтому приложение, которое проверяет «защищён ли этот запрос» и перенаправляет, если нет, будет перенаправлять бесконечно. Проверяйте X-Forwarded-Proto или оставьте редирект прокси.

Исправьте смешанное содержимое. Страница, отданная по HTTPS и загружающая скрипт или изображение по HTTP, блокируется браузером, и признак этого - наполовину отрисованная страница, а не заметная ошибка. Для CMS это обычно старые абсолютные адреса в базе данных; лечится поиском и заменой по всему содержимому, а как сделать это безопасно, рассказано в статье перенос WordPress на новый хостинг.

Осторожнее с HSTS. Заголовок Strict-Transport-Security велит браузерам никогда больше не использовать HTTP для вашего домена на срок, указанный в max-age. Это хорошо, когда всё стабильно, и больно, пока вы ещё что-то переносите, потому что браузер, закэшировавший его, не даст вам вернуться назад. Начните с max-age=300, поднимите до года, когда будете уверены, и не трогайте список preload, пока не убедитесь, что никогда не будете отдавать этот домен по HTTP.

Перенос работающего сайта без перерыва#

Последовательность, при которой старый сайт продолжает работать, пока новый не готов:

1. За день до этого снизьте TTL записей, которые собираетесь менять, до 300.
2. Соберите сайт на новом сервере и проверьте его до каких-либо изменений DNS, используя запись в файле hosts на своей машине, которая сопоставляет домен с новым адресом. Вы увидите новый сайт, пока все остальные видят старый.
3. Копируйте данные в последнюю очередь. Сначала файлы, затем база данных, затем всё, что изменилось в промежутке. Если можете, заморозьте запись на старом сайте на время финальной синхронизации: час только для чтения лучше, чем день потерянных заказов.
4. Смените запись A. Наблюдайте через dig @1.1.1.1, пока не вернётся новый адрес.
5. Дождитесь сертификата. Его нельзя выпустить, пока имя не указывает сюда, поэтому после смены DNS есть окно в минуту-две, когда посетители могут увидеть предупреждение. Если переключить в тихий час, это окно ничего не стоит.
6. Оставьте старый хост работать на неделю. Резолверы с долго кэшируемыми ответами, корпоративный DNS и несколько упрямых устройств продолжат приходить туда. Это стоит ещё месяц хостинга и избавляет от спора о том, кто потерял заказы.
7. Верните TTL в 3600, когда всё уляжется.

FAQ#

Сколько времени занимает обновление DNS?

До TTL изменённой записи, как он закэширован в каждом резолвере: час при TTL по умолчанию 3600, четыре часа при 14400 и около пяти минут, если вы снизили его до 300 за день до этого. Совершенно новое имя, которое никто ещё не запрашивал, разрешается сразу, потому что в кэше нечему истекать.

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

Почти всегда потому, что имя ещё не разрешается на этот сервер или разрешается на ваш прежний хост. Проверьте dig +short yourname @1.1.1.1 из-за пределов вашей сети. После этого поищите запись CAA, ограничивающую центр, устаревшую запись AAAA, прокси CDN, скрывающий origin, и опечатку в имени записи. Устраните причину и попробуйте один раз, а не повторяйте многократно, потому что неудачные проверки ограничиваются по частоте.

Нужно ли продлевать сертификат каждый год?

Нет. Продление идёт автоматически в последние 21 день срока действия. Остановить его может только то, что имя перестало сюда разрешаться, и из-за длинного окна продления эта неудача проявляется через недели после изменения DNS, которое её вызвало.

Можно ли использовать домен с игровым сервером?

Да, но через обычную запись A, указывающую на адрес сервера, а не через слот прокси: игровой трафик - не HTTP. Игроки тогда подключаются к имени и игровому порту. Для Minecraft запись SRV дополнительно позволяет игрокам вообще не указывать порт.

Можно ли купить домен здесь?

Нет. Мы не регистрируем домены и не предоставляем редактор DNS-зоны, так что ваш домен остаётся у вашего регистратора или DNS-провайдера, и записи вы создаёте там. От нас нужен только адрес, показанный на слоте прокси.

А как насчёт www и apex - нужны ли два сертификата?

Один сертификат может покрывать оба имени, но оба должны быть добавлены в слот и оба должны разрешаться сюда. Добавьте их, а затем перенаправьте одно на другое в вашем приложении или CMS, чтобы основным осталось одно, - так аналитика и поисковая выдача не разделятся надвое.