Довідник помилок / HSTS preload submission rejected
Заявку на HSTS preload відхилено
HSTS preload означає, що ваш домен вшитий у самі браузери: вони відмовляються зʼєднуватися з ним по звичайному HTTP ще до того, як побачили сайт. Домен подають на hstspreload.org, там працює автоматична перевірка, і заявку відхиляють, якщо не виконано всі чотири вимоги: дійсний сертифікат; перенаправлення з HTTP на HTTPS у межах того самого хоста; усі піддомени доступні по HTTPS; і на базовому домені по HTTPS віддається заголовок HSTS із max-age не менше 31536000 (один рік), директивою includeSubDomains і токеном preload. Зазвичай із цим стикаються власники та адміністратори, які давно перевели сайт на HTTPS і вважали preload формальністю. Відхилення нічого не ламає: домен просто не потрапляє до списку, доки ви не виправите умову і не подасте заявку знову.
Перевірте свій сайт
Через що виникає
Найчастіше винен сам заголовок: max-age менший за 31536000, немає includeSubDomains або немає токена preload. Далі за частотою йде перенаправлення: перший перехід з http://example.com має вести на https://example.com, тобто на той самий хост, а типова схема «з HTTP одразу на https://www» вимогу не виконує. Третя причина - піддомени: будь-який хост під вашим доменом, який відповідає лише по HTTP або має недійсний сертифікат, робить домен непридатним для списку, і забуті dev., staging., mail. чи webmail. теж рахуються. Ще одна поширена ситуація: заголовок віддається тільки на www, тільки по HTTP або його додає CDN, тоді як сам сервер його не надсилає.
Як виправити
- Запустіть перевірку на цій сторінці для базового домену (без www) і подивіться на три умови заголовка окремо: значення max-age, наявність includeSubDomains, наявність preload. Та умова, яку перевірка позначить як відсутню або замалу, майже напевно і є причиною відхилення, бо саме заголовок неможливо оцінити на око. Якщо всі три в порядку, заголовок нормальний, а проблема в тому, чого ця перевірка за вас підтвердити не може: сертифікат, перенаправлення або якийсь піддомен.
- Випишіть усі хости вашого домену з DNS-зони в панелі хостингу і відкрийте кожен по HTTPS. Найчастіше страждають забуті dev., old., staging., mail. і webmail. Усе, що не вміє HTTPS із дійсним сертифікатом, треба полагодити, перенести або видалити до подання заявки: після потрапляння в preload директива includeSubDomains зробить такі хости недоступними для всіх відвідувачів, і швидко це не відкотити.
- Перевірте перший крок перенаправлення: curl -sI http://example.com має віддати Location зі значенням https://example.com, тобто той самий хост. Перехід спершу на https://www.example.com або на інший домен вимогу не виконує, навіть якщо відвідувач зрештою опиняється на HTTPS.
- Переконайтеся, що заголовок HSTS віддається саме на HTTPS-відповіді базового домену, а не лише на www і не лише з боку CDN. Якщо заголовок додає проксі, перевірте, що його надсилає і сам сервер; а якщо по HTTPS віддається ще одне перенаправлення, заголовок має бути в самій відповіді-перенаправленні, а не тільки на сторінці, куди воно веде.
- Нарощуйте max-age поступово, а не одразу до року: 300, потім 86400, потім 604800, перевіряючи піддомени на кожному кроці, і лише тоді 31536000 разом з includeSubDomains. Токен preload додавайте останнім, коли річне значення вже певний час пропрацювало без скарг на зламані хости.
- Подайте заявку на hstspreload.org повторно, коли зміни вже на бойовому сайті, і закладайте час: запис доходить до людей лише з новими версіями браузерів, а видалення йде тим самим повільним шляхом, тому домен зі зламаним піддоменом залишиться зламаним місяцями для всіх, хто не оновлюється.