iis http https redirect

HTTP Redirects

The element configures settings for Internet Information Services (IIS) 7 that redirect client requests to a new location.

There are several reasons why you might want to redirect clients to a new location. For example, if your company is migrating to a new Web site, you could redirect all requests from the old Web site to the new Web site. Likewise, if you have deployed a new application on a Web server, you could redirect all requests for the old application’s URL namespace (for example, http://www.contoso.com/app_v1.0/ ) to the new applications location (for example, http://www.contoso.com/app_v2.0/ ).

In the simplest configuration, you need only set the enabled and destination attributes of the element in order to redirect clients to a new location. However, additional elements like the exactDestination and httpResponseStatus attributes allow you to configure the end-user experience of the redirection by respectively specifying whether IIS 7 will return the destination URL exactly as entered and which HTTP response code to return to the Web client.

Compatibility

Setup

HTTP Redirection is not available on the default installation of IIS 7 and later. To install it, use the following steps.

Windows Server 2012 or Windows Server 2012 R2

Windows 8 or Windows 8.1

Windows Server 2008 or Windows Server 2008 R2

Windows Vista or Windows 7

How To

There is no user interface for adding wildcard HTTP redirects for IIS 7. For examples of how to add elements to the element programmatically, see the Code Samples section of this document.

How to add an HTTP redirect rule to a Web site or application

Open Internet Information Services (IIS) Manager:

If you are using Windows Server 2012 or Windows Server 2012 R2:

If you are using Windows 8 or Windows 8.1:

If you are using Windows Server 2008 or Windows Server 2008 R2:

If you are using Windows Vista or Windows 7:

In the Connections pane, expand the server name, expand Sites, and then navigate to the Web site or application that you want to configure custom error pages for.

In the Home pane, double-click HTTP Redirect.

In the HTTP Redirect pane, check the box to redirect requests and enter the destination URL.

You can optionally specify any of the following options:

Configure the redirection destination to be the exact destination as entered.

Configure the redirection destination to be limited to the destination URL’s root folder, not subfolders.

Configure the HTTP status code, which can be one of these three options:

IIS 7 will respectively return the following actual HTTP response statuses for each of the above options:

When you have finished all the above changes, click Apply in the Tasks pane.

Configuration

Attributes

Specifies a URL or virtual path to which to redirect the client.enabledOptional Boolean attribute.

Specifies whether redirection is enabled (true) or disabled (false).

Specifies that the destination value should be considered an absolute target location, not a relative location.

Specifies type of redirection.

Child Elements

Adds a wildcard redirection rule to the collection of redirection rules.clearOptional element.

Removes all references to wildcard redirection rules from the collection of redirection rules.removeOptional element.

Removes a reference to a wildcard redirection rule from the collection of redirection rules.

Configuration Sample

The following default element is configured in the root ApplicationHost.config file in IIS 7 when the HTTP Redirection role service is installed. This configuration section inherits the default configuration settings unless you use the element.

The following configuration sample enables redirection and configures the destination URL to which clients are redirected.

The following configuration sample adds a wildcard redirection entry that redirects all requests for PHP files to the home page of your Web site.

This example is useful if you have removed all ASP-based applications from your Web site and you wanted client requests for the old applications to be redirected to the root of your Web site rather than receiving an HTTP 404 Not Found response.

Sample Code

The following code samples configure the Default Web Site to redirect all requests to http://www.contoso.com using an HTTP 302 status code.

AppCmd.exe

VB.NET

JavaScript

VBScript

The following code samples adds a wildcard redirection entry that redirects all requests for ASP files to the home page of your Web site.

This example is useful if you have removed all ASP-based applications from your Web site and you wanted client requests for the old applications to be redirected to the root of your Web site rather than receiving an HTTP 404 Not Found response.

Источник

🌐 Как перенаправить HTTP на HTTPS в IIS

Это руководство поможет вам настроить IIS для перенаправления любого URL-адреса с HTTP на HTTPS.

Это хорошая практика, чтобы рабочие URL-адреса всегда были на безопасной странице.

После завершения этого руководства все незащищенные (HTTP) запросы к вашим веб-сайтам будут перенаправлены на защищенные (HTTPS) в IIS в Windows.

Прежде чем мы начнем

Мы предполагаем, что вы уже установили SSL-сертификат в IIS.

Также добавлена привязка SSL к вашим сайтам с портом 443 и установленным сертификатом.

Шаг 1 – Установите модуль URL-Rewrite

Мы будем использовать модуль URL Rewrite на IIS для перенаправления трафика с HTTP на HTTPS.

Прежде всего, вам необходимо скачать и установить этот модуль отсюда:

Шаг 2. Настройка редиректа трафика с HTTP на HTTPS

Шаг 2. Настройка перенаправления HTTP на HTTPS

После завершения установки выполните следующие шаги для завершения перенаправления HTTPS в IIS.

1. Запустите IIS Manager и выберите веб-сайт в разделе подключений слева.

2. Вы увидите все параметры конфигурации в среднем окне. Просто дважды щелкните по значку URL Rewrite.

Проверка

Для проверки откройте ваш URL в браузере через http, и он должен автоматически перенаправить вас на https.

День добрый.
Хорошо когда все срабатывает.
Хуже когда нет. И всю голову раскурочил – не работает и всё тут.
Уже каждый раз чищу всю историю с кукисами – ничего не помогает. Не перенаправляет, зараза, и всё тут.
Куда копать – не понимаю.

Добрый день, а сам сайт работает на 443 порту? С сертификатом все ок?

Тоже ничего не получалось. Создал привязку для сайта по 80 порту (в дополнение к уже созданной по 443) и все заработало.

Anything in here will be replaced on browsers that support the canvas element

Источник

Iis http https redirect

Once the SSL certificate is installed, your site still remains accessible via a regular insecure HTTP connection. To connect securely, visitors must specify the https:// prefix manually when entering your site’s address in their browsers.

In order to force a secure connection on your website, it is necessary to set up a certain HTTP/HTTPS redirection rule. This way, anyone who enters your site using a link like “yourdomain.com” will be redirected to “https://yourdomain.com” or “https://www.yourdomain.com” (depending on your choice) making the traffic encrypted between the server and the client side.

Below are steps to setup a IIS HTTPS redirect:

— Select Matches the Pattern in the Requested URL drop-down menu
— Select Regular Expressions in the Using drop-down menu
— Enter the following pattern in the Match URL section: (.*)
— Check the Ignore case box

— Enter as a condition input
— Select Matches the Pattern from the drop-down menu
— Enter ^OFF$ as a pattern
— Press OK

NOTE: There are 4 redirect types of the redirect rule that can be selected in that menu:
— Permanent (301) – preferable type in this case, which tells clients that the content of the site is permanently moved to the HTTPS version. Good for SEO, as it brings all the traffic to your HTTPS website making a positive effect on its ranking in search engines.
— Found (302) – should be used only if you moved the content of certain pages to a new place *temporarily*. This way the SEO traffic goes in favour of the previous content’s location. This option is generally not recommended for a HTTP/HTTPS redirect.
— See Other (303) – specific redirect type for GET requests. Not recommended for HTTP/HTTPS.
— Temporary (307) – HTTP/1.1 successor of 302 redirect type. Not recommended for HTTP/HTTPS.

OPTION 2: Specify the Redirect Rule as https:/// and check the Append query string box. The Action type is also to be set as Redirect.

The IIS redirect can be checked by accessing your site via http:// specified in the URL. To make sure that your browser displays not the cached version of your site, you can use anonymous mode of the browser.

The rule is created in IIS, but the site is still not redirected to https://

Normally, the redirection rule gets written into the web.config file located in the document root directory of your website. If the redirection does not work for some reason, make sure that web.config exists and check if it contains the appropriate rule.

To do this, follow these steps:

Источник

IIS как пограничный веб-сервер (теперь haproxy)

В этой статье я хочу описать не самый типичный сценарий, который, тем не менее, имеет право на жизнь.
Дело в том, что мы используем IIS как прокси для других веб-серверов компании. Я расскажу, как это реализовано и с какими трудностями пришлось столкнуться​.

Постановка задачи
Разберём на примере сервера YouTrack. Он представлен неприглядным srv-youtrack-01.local.domain и находится на веб-сервере внутри компании. Задача заключается в том, чтобы обеспечить доступ к нему из интернета по красивому имени yt.company.ru. При этом обязательно должен использоваться https.

Реализация
Для начала работы нам понадобится установить компонент URL Rewrite. Это можно сделать при помощи web platform installer, а также вручную. После его установки мы увидим в диспетчере служб IIS новый ярлык
переопределение URL-адресов».

При помощи этого инструмента можно создать правило переопределения адресов «обратный прокси-сервер».

При создании правила нужно указать URL сервера (без префикса http:// — его IIS добавит автоматически), на который будет происходить проксирование. В итоге мы получим правило, доступное для редактирования. Оно применяется не ко всем запросам, а только к тем, которые подходят под критерии, которые мы можем настраивать. Для начала проверяется URL на соответствие шаблону, после чего в ход идут проверки по другим критериям.

Сразу оговорюсь, что тут есть два пути: первый путь — создать набор правил с разными шаблонами URL-адресов для разных ресурсов на одном IIS-сайте; а второй — создать по сайту для каждого проксируемого ресурса и в каждом из них сделать по одному правилу. Понимая, что первый путь более джедайский, я все-таки избрал путь второй — пусть не такой красивый, зато я не рискую написав неправильное регулярное выражение для одного сайта сломать всю маршрутизацию. Поэтому шаблон URL-адреса у меня везде дефолтный «(.*)».

Итак, я создаю сайт yt.company.ru с биндингами на 80 и 443 порт и обязательным указанием имени узла, чтобы IIS знал, к какому сайту я обращаюсь. Про получение и установку сертификата для 443 позволю себе не упоминать. Обращу лишь внимание, что сам сервис настраивать на использование https не нужно — внутри сети шифроваться не от кого, а внешние запросы будут соединяться по ssl с пограничным сервером, который будет уже по незащищенному каналу проксировать запросы внутри сети.

Покуда обязательным требованием является использование https, будем проксировать только те запросы, которые приходят на 443 порт, для чего создадим простое условие. При его создании предлагается выпадающий список возможных вариантов.

Отлично, теперь все запросы yt.company.ru проксируются на внутренний сервер с неприглядным именем srv-youtrack-01.local.domain прозрачно для пользователя.

Однако, все запросы yt.company.ru отсекаются с ошибкой 403, что не очень красиво. Для решения этой проблемы можно либо создать index.html с редиректом, либо еще одно правило URL Rewrite, у которого в поле «действие» выберем постоянное перенаправление на нужный нам URL.

Следует обратить внимание, что правила для сайта применяются по порядку, поэтому сначала нужно расположить правило с условием, а потом правило без условий. При этом, так как второе правило применяется ко всем URL без исключения, для первого правила необходимо поставить (оставить поставленной) галочку «Остановить обработку последующих правил».

После манипуляций с графическим интерфейсом в корне нашего сайта создается web.config, который содержит все созданные правила. Поэтому если требуется проксировать еще какой-то сайт, то эти манипуляции повторять не нужно, можно просто скопировать web.config и изменить в нем требуемый URL или после копирования воспользоваться графическим интерфейсом для изменения правил. Более того, можно вообще не пользоваться интерфейсом, а писать сразу туда — кому как нравится.

Подводные камни
При переходе на вкладку «Agile boards» YouTrack генерит URL-адрес вида yt.company.ru/rest/agile/Overview-0/sprint/Iteration+24. Далее, при переключении между спринтами yt.company.ru/rest/agile/Overview-0/sprint/Iteration%252023?q=. При переходе на эти урлы IIS стал возвращать мне 404 ошибку. Это свидетельствовало о том, что запросы не проксируются. При этом переходы между сохраненными запросами вида yt.company.ru/issues/IT?q=%23+Assigned+to%3A+me+updated%3A+ вполне корректно отрабатывали.

Эксперименты с добавлением знака вопроса в середину проблемного URL закончились тем, что я стал получать 404 ошибку уже от YouTrack-сервера, а не IIS. Это натолкнуло меня на мысль, что IIS по каким-то своим соображениям (привет, Microsoft) интерпретирует URL и это надо исправить.

Проблема со знаком «плюс» в середине адреса решилась добавлением параметра requestFiltering allowDoubleEscaping=«true»:

Но после этого все еще не работало переключение между спринтами. Выяснилось, что IIS считает такие запросы небезопасными. Эту проверку тоже пришлось отключить:

Вот какой web.config получился после всех манипуляций:

Итоги
Вероятно, решения, которые я нашел, не являются оптимальными и вместо разрешения всего подряд нужно было аккуратно прописать правила, подходящие в конкретном случае. Но сейчас это работает. Буду рад выслушать ваши соображения и предложения.

Таким образом у нас в организации проксируются абсолютно все веб-серверы, которым нужен доступ извне, среди которых есть и nginx, и apache, и svn, и gitlab, и exchange web access.

Основная проблема, которая заставляет меня находиться в поиске решения заключается в том, что через прокси не работает NTLM-авторизация, так нужная для многих сервисов компании Microsoft. Мёртвый продукт TMG использовать не хочется, поэтому сейчас пытаюсь разобраться с новой службой Windows Server 2012 R2 под названием Web Application Proxy параллельно поглядывая на nginx и apache, которые, кажется, тоже пока не умеют проксировать NTLM.

Ссылки

Большой update:
В комментариях мне посоветовали попробовать haproxy. Зайдя на сайт я сделал поиск по странице «ntlm» и нашел «full HTTP keep-alive for better support of NTLM and improved efficiency in static farms», что придало мне уверенности.
После нескольких дней активной возни в консоли я таки осилил этот замечательный инструмент и теперь IIS в качестве прокси-сервера мне больше не нужен. Отдельную статью про это, думаю, писать не стоит, поэтому решил обновить топик.

Работает всё это дело достаточно просто и из коробки:
1. Устанавливается из backports при помощи apt-get (предпочитаю debian)
2. Пишется конфиг. Слегка правятся настройки проксируемых приложений
3. Переключается iptables на новый прокси

На втором пункте остановлюсь подробнее.
В секцию defaults конфига дописал

Последний пункт нужен для того, чтобы бакенду передавалось имя хоста, остальные — «как у всех».

Далее создаются фронтенды для 80 и 443 портов, которые будут слушать и решать, на какой бакенд посылать запрос в зависимости от некоторых условий. А условие у меня только одно — пришедшее имя хоста.

С https несколько сложнее. На помощь пришёл соседний топик, в комментариях которого рекомендовали использовать SNI. Его и использовал

Это оказалось очень просто! Первым делом генерируются сертификаты для всех бакендов — именно они и будут отдаваться клиентам. Я использую PKI от Микрософта, поэтому пришлось немного повозиться с генерацией реквестов, выдачей и передачей на прокси этих сертификатов. Допускается, кстати, использование *.company.name, но я решил что это как-то не очень солидно, тем более при таком малом количестве бакендов. После того, как сертификаты готовы, нужно написать их тупо в строчку как на примере выше, а дальше написать правила для бакендов — сертификаты будут подсовываться по порядку.
Конструкция с использованием sni настолько простая, что даже объяснять не надо. Правда, вышло так, что большинство почтовых клиентов андроида не умеют (или не хотят) sni, и шлют запросы на 443 порт без указания имени хоста. Не беда! Для таких случаев есть

(я, кстати, не проверил, какой сертификат подсовывается в этом случае)

Ну а дальше описываются бакенды. С http всё тривиально:

Здесь it.company.name — это имя хоста, которое будет передано на srv-web-01. Мне это нужно по тому, что IIS на этом сервере использует идентификацию по имени хоста.

Для https вот такие конструкции

Тут можно разгрузить SSL, указав 80 порт — тогда шифроваться будет трафик между клиентом и проксей, а внутри сети не будет. А можно и дальше использовать https (verify none означает «не придираться к сертификату»). Стоит, однако, понимать, что клиент все-таки получает тот сертификат, который мы вписали при создании фронтенда. Если нужно подсовывать именно сертификат конечного сервера, то можнжо использовать способ, описанный в топике, который я указал выше.

Ещё один момент: хочется красиво редиректить http на https для некоторых серверов. Для этого я создал специальные бакенды с постфиксом _r, которые аккуратно перекидывают ничего не подозревающего пользователя на https.

Закомментированную строку не стал убирать сознательно — изначально использовался такой вариант, но он перенаправлял меня в корень сайта, что очень неудобно, если пользователь нажал на длинную ссылку http ://site.company.name/lib/doc/Русские%20буквы%20в%20названии.docx, а его перекинуло на главную страницу без всякой надежды найти свой документ. Велика вероятность, что он закроет её и попробует пройти по ссылке снова, но опять ничего не получит и очень расстроится. Чтобы такого не произошло, нам помогает конструкция redirect scheme https, которая аккуратно перенаправляет пользователя, подставляя весь URL.

Подробно обо всех тонкостях конфигурирования на странице документации cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2

Спасибо за внимание. Надеюсь, кому-то мой опыт окажется полезным.

Источник

Перенаправление с HTTP на HTTPS-IIS 7.5

я реализовал https в своем приложении, и теперь я пытаюсь сделать IIS перенаправить весь http-запрос на https, чтобы пользователь даже не заметил этого изменения.

Я изменил и попробовал некоторые параметры IIS, но не повезло.

Как я могу это сделать?

Я использую IIS 7.5 и ASP.NET 2.0

5 ответов

вы можете установить RewriteModule и следуйте инструкциям на на этой странице.

подход, описанный в этой статья в блоге работает хорошо.

резюме:
1) включите параметр «требовать SSL» для сайта.

2) в конфигурации настроек ошибок для 403 ошибок установите его в «ответить с перенаправлением 302» с новым URL-адресом, установленным на полный URL-адрес с префиксом https://.

вы можете сделать простую проверку на мировую.asax, на beginRequest, что-то вроде этого кода:

ps. У меня не было проверки этого кода, я просто набираю его сейчас.

на случай, если кто-то еще столкнется с сайтом http://, который не будет перенаправляться. Вы также должны иметь привязку порта 80, добавленную на сайт.

перенаправление с HTTP на HTTPS в IIS 7

URL переписать тесно интегрирован с IIS Manager для лучшего управления(скачать изhttps://go.microsoft.com/?linkid=9722532)

Настройка Параметров Правил

соответствующий URL-адрес вкладки:
name= перенаправить 2 HTTPS
URL-адрес= (.*)

условия добавить запись
вход= <протокол HTTPS>
pattern= ^OFF$

действие:
type= Redirect
URL перенаправления= https:/ / /
redirectType= постоянный

Источник