IIS URL Rewrite/SSL-сертификаты

Question

Я буду использовать многодоменные сертификаты DigiCert для следующих целей:

  www.example.com
  example.com
  sub1.example.com
  www.sub1.example.com
  sub2.example.com
  www.sub2.example.com

     etc...

Я использую IIS URL Rewrite для удаления www. со всех доменов, что дает мне:

  example.com
  sub1.example.com
  sub2.example.com

Я также использую URL Rewrite для маршрутизации всех http:// на https://.

Мои вопросы:

1. Нужен ли мне www. доменные сертификаты, так как я перенаправляю на урезанную версию URL?
2. Являются ли www. сертификаты с префиксом, необходимые для согласования начального соединения SSL?

Если возможно, я хотел бы устранить все www. . сертификаты

отредактированный

Для полноты я добавил два перенаправления, которые я использую.

<rewrite>
  <rules>
    <rule name="Remove www" stopProcessing="true">
      <match url="(.*)" ignoreCase="true" />
      <conditions logicalGrouping="MatchAll">
        <add input="{HTTP_HOST}" pattern="^www\.(.+)$" />
      </conditions>
      <action type="Redirect" url="https://{C:1}/{R:0}" appendQueryString="true" redirectType="Permanent" />
    </rule>
    <rule name="Redirect to http" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
      <match url="*" negate="false" />
      <conditions logicalGrouping="MatchAny">
        <add input="{HTTPS}" pattern="off" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" />
    </rule>
  </rules>
</rewrite>

Спасибо...

Обновление: нежелательные побочные эффекты

После большого тестирования я обнаружил некоторые нежелательные побочные эффекты при удалении www. из URL. При определенных условиях пользователь увидит предупреждение системы безопасности о том, что сайт НЕ является безопасным, что на наш взгляд очень плохо.

Возможные введенные пользователем URL:

example.com, www.example.com, http:// или https:// with example.com или www.example.com

Желаемый URL переписать:

https:// + example.com

Различия между браузерами

URL https:// + www.example.com/ НЕ перезаписывается на нужный URL в IE, Edge, Safari и Firefox, НО перезаписывается с помощью Chrome. Подумав об этом некоторое время, я не уверен, почему Chrome позволяет переписывать HTTPS, так как был введен жестко запрограммированный URL HTTPS.

Chrome направляет https:// + www.example.com/ на https:// + example.com. Никакие сбои сертификата не отображаются пользователю.

IE кеш коррупция?

После ввода URL-адреса https:// + www.example.com в IE он, похоже, повредил кеш истории.

Если вы введете www.example.com после ввода предыдущего URL, браузер перенаправит на https:// + www.example.com/. Это приводит к плохому сообщению о сертификации, что не очень хорошо.

IE может быть закрыт и снова открыт, и аномалия продолжится, если вы снова зайдете на www.mydomain.com.

Если я вручную очищаю кэш неверного URL-адреса https:// + www.example.com, а затем ввожу www.example.com, IE перенаправляет на https:// + example.com, что является желаемым результатом.

Повреждение кэша Temp Safari?

Мне удалось продемонстрировать подобный сбой в MAC Safari для тех же условий тестирования, которые я использовал для IE, но Safari восстановился после перехода к другим URL-адресам и возврата ИЛИ закрытия / повторного открытия браузера.

Заключение для нашей модели использования

Ликвидация www. это не хороший вариант.

Answer 1

Сеанс TLS устанавливается перед любой обработкой, включая перезапись. Поэтому, чтобы избежать ошибок браузера, вы должны убедиться, что ваш сертификат содержит записи Subject Alternate Name для всех DNS-имен, которые вы ожидаете от клиентов в своих браузерах. Это включает в себя www .

Единственным исключением будет случай, когда вы перенаправляете с http://www.example.com (без TLS) на https://example.com (TLS). В этом случае перезапись будет происходить через http и, следовательно, не будет включать TLS и сертификаты.

Answer 2

У меня почти такая же проблема, но вот в чем проблема. Chrome перезаписывает URL-адрес (удаляет www) на сайтах, которые не переписывают URL-адреса. Перезапись URL, похоже, не имеет отношения к Chrome.

Chrome обрабатывает сайты с префиксом www по-другому?

Майк