web-dev-qa-db-fra.com

Comment implémenteriez-vous des redirections pour la canonisation de domaine, no-www et HTTPS pour IIS 7.5

Pour le moment je suis coincé avec un serveur IIS, malheureusement pas mon meilleur sujet (je suis beaucoup mieux avec Apache). Nous avons un site sur un serveur Win 2008 R2 avec IIS 7.5. C'est un ancien site et nous travaillons sur un nouveau site sur un nouveau serveur. Mais jusqu'à ce que le nouveau site soit opérationnel, nous avons besoin de l'ancien site.

La société porte le nom "examplesite" mais est appelée "example".

J'ai 8 URL, avec toutes les combinaisons de:

  • HTTP et HTTPS
  • www et no-www
  • example.com et examplesite.com

Et je veux, peu importe ce que vous écrivez dans la barre d'adresse d'un navigateur Web, vous irez à:

https://example.com

J'ai essayé pendant quelques jours maintenant avec la réécriture et la redirection et je ne peux pas le faire fonctionner. (Je reçois certaines adresses qui fonctionnent correctement, mais pas toutes)

S'il vous plaît, comment puis-je résoudre ce problème?

Modifier pour ajouter:

Désolé, mais mon problème semble être un autre que je ne le pensais depuis le début. Je n'ai qu'un seul certificat SSL sur le serveur, un seul certificat de liaison pour example.com. Si je comprends bien, je ne peux avoir qu'un seul certificat de liaison par adresse IP sur le serveur.

La partie qui ne fonctionne pas maintenant est donc la partie https pour www.example.com, examplesite.com et www.examplesite.com. J'utilise Let's Encrypt et ils ont "un certificat SAN pour toutes les liaisons sur plusieurs sites IIS") - je dois comprendre comment utiliser ce choix lorsque je crée le certificat.

301-redirecthttpsurl-rewritingiis7
4
user255136

En supposant que vous utilisez le module de réécriture d'URL, vous pouvez utiliser l'ensemble de règles de réécriture suivant dans le web.config:

<system.webServer>
  <rewrite>
    <rules>
      <rule name="ForceToExample.com" stopProcessing="true">
        <!-- Match any path -->
        <match url="(.*)" />
        <conditions>
          <!-- Domain is "examplesite.com" regardless of any subdomain -->
          <add input="{HTTP_Host}" pattern="^.*examplesite\.com" />
        </conditions>
        <action type="Redirect" url="https://example.com/{R:1}" redirectType="Permanent" />
      </rule>
      <rule name="ForceFromWww" stopProcessing="true">
        <!-- Match any path -->
        <match url="(.*)" />
        <conditions>
          <!-- Domain starts with "www." regardless of actual domain -->
          <add input="{HTTP_Host}" pattern="^www\..*" />
        </conditions>
        <action type="Redirect" url="https://example.com/{R:1}" redirectType="Permanent" />
      </rule>
      <rule name="ForceToSsl" stopProcessing="true">
        <!-- Match any path -->
        <match url="(.*)" />
        <conditions>
          <!-- If the request wasn't secure, regardless of domain -->
          <add input="{HTTPS}" pattern="ON" negate="true" />
        </conditions>
        <action type="Redirect" url="https://example.com/{R:1}" redirectType="Permanent" />
    </rules>
  </rewrite>
</system.webServer>

L'ordre peut être important - les règles sont traitées de haut en bas et peuvent "tomber", de sorte que les règles suivantes peuvent également affecter une demande - dans ce cas, car le type d'action est Redirect, le stopProcessing la directive est probablement redondante.

Chacune de ces règles respectera le chemin d'origine, donc une demande à http://www.examplesite.com/folder/page1.aspx Devrait se terminer sur https://example.com/folder/page1.aspx.

Pour expliquer les règles:

  • ForceToExample.com
    Cela redirigera toute demande vers examplesite.com Ou www.examplesite.com Vers https://example.com, Quel que soit le schéma d'origine (http ou https).
  • ForceFromWWW
    Cela redirigera toute demande (qui n'était pas déjà redirigée) de www.example.com Vers https://www.example.com/, Quel que soit le schéma d'origine.
  • ForceToSsl
    Cela redirigera toute demande (qui n'a pas déjà été redirigée) de http://example.com Vers https://example.com

J'ai délibérément laissé l'élément de redondance dans ces règles car je pense que cela facilite la lecture et la compréhension de ce que chacune fait.

Comportement attendu:

  • http://www.examplesite.com/ Correspondrait ForceToExample
  • https://www.examplesite.com/ Correspondrait ForceToExample
  • http://examplesite.com/ Correspondrait ForceToExample
  • https://examplesite.com/ Correspondrait ForceToExample
  • http://www.example.com/ Correspondrait à ForceFromWww
  • https://www.example.com/ Correspondrait à ForceFromWww
  • http://example.com/ Correspondrait ForceToSsl
  • https://example.com/ Ne correspondrait à aucune règle et sera géré par votre application

Quelques points supplémentaires à noter:

  1. Si vous avez déplacé les éléments <rewrite> Ou <rules> De votre fichier web.config, vous devrez redémarrer l'application pour voir vos modifications en action.
  2. Pendant les tests, je préfère utiliser redirectType="Found" Dans l'action - cela émet une redirection 302 et votre navigateur ne met pas en cache la nouvelle demande.

Modifier pour couvrir le problème du certificat unique

Vous avez raison de dire que normalement vous ne pouvez avoir qu'une seule liaison SSL par adresse IP sur un serveur, cependant Server Name Identification (SNI) vous permet d'avoir plusieurs liaisons SSL sur une seule adresse IP d'une manière qui fonctionne avec tous les navigateurs modernes.

Malheureusement IIS 7.5 ne le prend en charge que pour les certificats génériques et même dans ce cas uniquement pour un certificat générique, installé avec un * En tête dans le nom (c'est-à-dire *.example.com Plutôt que Wildcard example.com). Cela vous permettrait de gérer les demandes à https://www.example.com Et https://example.com, Mais ne vous aiderait pas avec les certificats Let's Encrypt ou examplesite.com (vous ne pouvez pas obtenir un caractère générique SAN).

Les solutions possibles consisteraient à utiliser les fonctionnalités de terminaison SSL de certains CDN (CloudFlare, Azure Front Door et d'autres par exemple) pour sécuriser les demandes à leur CDN, puis les demandes du CDN à votre serveur sont envoyées non sécurisées (elles ne sont pas vues par le navigateur client) et ils vous permettent également de faire des redirections sur Edge (de www.example.com à example.com), ce qui pourrait vous aider.

2
Zhaph - Ben Duguid