Домены .app и .dev: почему HTTPS обязателен и как правильно настроить сайт

Домены .app и .dev очень популярны среди разработчиков и создателей мобильных приложений. Но многие после покупки сталкиваются с неожиданностью: файлы сайта загружены на сервер, DNS настроен правильно, а браузер сайт не открывает и показывает ошибку безопасного соединения. Причина в особом правиле этих зон: работать через незашифрованный HTTP в них невозможно в принципе. Разберём, как устроено это ограничение, какую пользу оно даёт и что сделать, чтобы сайт заработал правильно с первого дня.

Как работают HSTS и preload-список

HSTS (HTTP Strict Transport Security) — механизм, который сообщает браузеру: «связывайся с этим сайтом только по HTTPS». Обычно сайт отправляет это указание в заголовке ответа, и браузер запоминает его после первого успешного визита. Проблема в том, что самый первый визит ещё не защищён. Чтобы закрыть эту брешь, браузеры содержат так называемый preload-список: для доменов из него правило HTTPS зашито заранее и действует с самого первого подключения.

Реестр, управляющий зонами .app и .dev, внёс эти зоны в preload-список целиком. В результате Chrome, Firefox, Safari, Edge и другие современные браузеры никогда не обращаются к misol.dev или misol.app по обычному HTTP. Даже если пользователь наберёт http://, браузер сам заменит его на https:// ещё до отправки запроса на сервер. Правило распространяется и на все поддомены внутри зоны, например на api.misol.dev или staging.misol.dev.

Что будет без сертификата

Если на обычном сайте .uz или .com SSL-сертификат истёк или настроен неверно, браузер показывает предупреждение, но иногда предлагает кнопку «всё равно продолжить». На доменах под HSTS такой возможности нет: при недействительном сертификате пользователь просто не сможет открыть страницу. Поэтому своевременное обновление сертификата для .app или .dev — не удобство, а жизненно важное условие работы сайта.

То же правило касается смешанного контента. Если страница открыта по HTTPS, а картинка или скрипт внутри неё грузится с адреса http://, браузер может такие ресурсы заблокировать. Поэтому все ссылки, CSS- и JavaScript-файлы на сайте должны подключаться по HTTPS или относительным путём. В системах вроде WordPress полезно проверить, что адрес сайта в настройках начинается с https://.

Правильная настройка сервера

Если сайт размещён на виртуальном хостинге, проще всего выпустить бесплатный сертификат Let's Encrypt через панель и включить автоматическое продление. На хостинге sayt.uz такой сертификат предоставляется бесплатно и обновляется сам, поэтому после подключения домена .dev или .app достаточно первым делом проверить статус SSL. На собственном VPS сертификат можно получить через Certbot. Хотя Let's Encrypt проверяет владение доменом через порт 80, эта проверка выполняется на уровне сервера, а не браузера, поэтому HSTS ей не мешает.

sudo certbot --nginx -d misol.dev -d www.misol.dev
sudo certbot renew --dry-run

В конфигурации Nginx порт 80 не обязательно закрывать полностью. Рекомендуется оставить его и возвращать на все запросы 301-редирект на HTTPS: это удобно для проверок Let's Encrypt и старых клиентов без поддержки HSTS. Ниже простой пример конфигурации для misol.dev.

server {
    listen 80;
    server_name misol.dev www.misol.dev;
    return 301 https://misol.dev$request_uri;
}

server {
    listen 443 ssl;
    server_name misol.dev www.misol.dev;

    ssl_certificate     /etc/letsencrypt/live/misol.dev/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/misol.dev/privkey.pem;

    root /var/www/misol.dev;
    index index.html;
}

Поскольку HSTS уже включён на уровне зоны, добавлять заголовок Strict-Transport-Security не обязательно, но и вреда от него не будет. После настройки можно проверить, что сертификат выдан правильно и какой у него срок, следующими командами. Обратите внимание: curl не использует preload-список браузеров, поэтому через него может открыться и http://-адрес, а браузер так никогда не сделает.

# на кого и на какой срок выдан сертификат
openssl s_client -connect misol.dev:443 -servername misol.dev </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

# проверка ответа по HTTPS
curl -sI https://misol.dev | head -n 5

Не забывайте про поддомены

Частая ошибка — получить сертификат для основного домена и забыть про поддомены. Например, небольшая IT-команда из Самарканда запустила для клиентов страницу misol.app, затем добавила в DNS поддомен beta.misol.app для тестов, но сертификат для него не выпустила. В итоге клиент, который хотел открыть тестовое задание, увидел только окно с ошибкой. Решение — выпускать отдельный сертификат для каждого нового поддомена или получить wildcard-сертификат с подтверждением через DNS.

Не используйте .dev для локальной разработки

Когда-то разработчики любили открывать проекты на своём компьютере под вымышленными именами вроде misol.dev. После того как .dev стал настоящей зоной и попал в preload-список, такие локальные адреса начали требовать HTTPS в браузере, и многие среды разработки сломались. Для локальных проектов правильно использовать специально зарезервированные имена .test или .localhost. Они никогда не регистрируются как настоящие домены в интернете, и браузеры не навязывают им HTTPS.

127.0.0.1   misol.test
127.0.0.1   api.misol.test

Итак, обязательный HTTPS в зонах .app и .dev — это скорее защита, чем ограничение. Он оберегает пользователя от перехвата трафика в открытых Wi-Fi-сетях и от внедрения чужого кода в страницу. Нужно соблюдать лишь одно правило: сертификат должен быть готов до запуска сайта и продлеваться автоматически. Тогда домен .app или .dev работает так же беспроблемно, как любой другой.