Использование записей CNAME для перенаправления на HTTPS при активном HSTS
У нас есть веб-сайт, работающий в HTTPS по следующему URL-адресу: abc.example.com .
Проблема в том, что наш клиент решил, что URL любого веб-сайта должен начинаться с www , и напечатал www.abc.example.com на всех своих этикетках ...
] Нет проблем, я просто создал правило перенаправления, используя функцию перезаписи URL-адресов IIS, чтобы перенаправить все имена хостов на https://abc.example.com . Все идет нормально.
Несколько месяцев назад мы получили электронное письмо от их отдела информационных технологий, в котором говорилось, что на abc.example.com отсутствует заголовок Strict-Transport-Security . Они попросили нас реализовать следующий заголовок:
Strict-Transport-Security = max-age=31536000; includeSubDomains; preload.
В то время я не был полностью осведомлен о точной функции этого заголовка, поэтому я вслепую добавил его на веб-сайт. Я тестировал веб-сайт, просто никогда не тестировал его с помощью www.abc.example.com .
Я только сейчас узнал, что этот заголовок HSTS будет перенаправлять все URL-адреса HTTP на URL-адреса HTTPS самостоятельно, что привело к игнорированию моих пользовательских правил перенаправления. Проблема теперь в том, что пользователи вводят http://www.abc.example.com и перенаправляются на https://www.abc.example.com вместо ] https://abc.example.com , что приводит к ошибке сертификата SSL, потому что www.abc.example.com не имеет сертификата SSL.
Пока includeSubDomains активен, я, кажется, очень мало можно сделать, чтобы этого не произошло на веб-сервере, если я не настроил сертификат SSL специально для www.abc.example.com .
Вот почему я подумал о том, чтобы попытаться решить эту проблему путем перенаправления на уровне DNS с использованием записи CNAME: www.abc.example.com. CNAME abc.example.com.
У меня вопрос, будет ли это работать? Когда пользователь вводит http://www.abc.example.com , запись CNAME сначала перенаправляет этот URL на http://abc.example.com , а затем успешно перенаправляет на https: //abc.example. com с использованием заголовка HSTS? Или параметр preload предотвратит это, даже на уровне DNS?
Любые предложения или помощь приветствуются.
Нет, это не сработает. На уровне DNS нет такой вещи, как перенаправление; перенаправление - это функция протокола HTTP, в то время как записи DNS (как A , так и CNAME ) используются только для разрешения IP-адреса.
Также нет смысла пытаться отменить ситуацию с помощью удалив заголовок,
Strict-Transport-Security = max-age=31536000; includeSubDomains; preload.
, поскольку он будет кэшироваться в каждом браузере на 31536000 секунд, т.е. 365 дней.
Однако, если вы не реализуете HSTS таким образом, вы не получите много его преимущества, поскольку кто-то может попытаться изменить http://www.abc.example.com , прежде чем он будет перенаправлен на https: // .
Здесь единственный выход может получать подстановочный сертификат, охватывающий *. abc.example.com , или сертификат с несколькими именами хостов, имеющий оба значения как Альтернативное имя субъекта s.