Что нужно сделать, чтобы перевести сайт с HTTP на HTTPS
Что проверяют
Умеете ли вы превратить инфраструктурную задачу в план проверок. От тестировщика ждут не установки сертификата, а списка того, что ломается после переключения, и способа это поймать.
Как отвечать
Разложить по областям и сказать, что проверяете в каждой:
- сертификат: срок действия, полная цепочка с промежуточными, все нужные имена в SAN (апекс,
www, поддомены), отключённые старые версии протокола и слабые шифры, автопродление; - редиректы: HTTP отвечает постоянным редиректом на HTTPS, путь и параметры запроса сохраняются, цепочка в один шаг, для POST нужен код, который сохраняет метод и тело;
- смешанный контент: активные ресурсы (скрипты, стили, фреймы) по HTTP браузер блокирует, картинки помечает небезопасными. Ловится в консоли, лечится относительными путями и заголовком с политикой безопасности;
- сессии и куки: флаги
Secure,HttpOnlyиSameSite, повторная проверка логина, корзины, оплаты после смены схемы; - внешние точки входа: вебхуки, коллбэки платёжных систем, CORS, ссылки в старых письмах, мобильные клиенты, где сертификат может быть закреплён в коде;
- служебное: канонические ссылки, карта сайта, robots.txt, счётчики, отсутствие циклов в редиректах;
- заголовок HSTS включают последним и осознанно: браузер запомнит его на весь срок, и быстро откатиться не получится.
Где спотыкаются
Проверяют одну главную страницу в одном браузере и закрывают задачу. Достаточно единственного виджета, подключённого по HTTP на внутренней странице, чтобы замок пропал именно там, куда ходят пользователи.
Смотрят на факт редиректа, но не на его код и длину цепочки. Временный редирект вместо постоянного теряет накопленный вес страницы, а лишние прыжки между схемой и поддоменом замедляют ответ и рвут запросы с телом.
Забывают про то, что не открывается в браузере: API мобильного приложения, интеграции на старых версиях TLS, коллбэки внешних систем. Пока HTTP работает параллельно, это незаметно, и падает всё ровно в момент, когда старый порт закрывают.