現時点では、IISサーバーに悩まされていますが、残念ながら私の一番のテーマではありません(Apacheの方がずっとましです)。 IIS 7.5のWin 2008 R2サーバー上のサイトがあります。これは古いサイトであり、新しいサーバー上の新しいサイトで作業しています。ただし、新しいサイトが稼働するまで、古いサイトが必要です。
会社の名前は「examplesite」ですが、「example」と呼ばれています。
私には8つのURLがあり、次のすべての組み合わせがあります。
example.com
およびexamplesite.com
そして、私が欲しいのは、あなたがウェブブラウザのアドレスバーに何を書いても、あなたは次のように行きます:
https://example.com
私は数日間リライトとリダイレクトの両方を試してみましたが、機能させることができません。 (一部のアドレスは正常に機能していますが、すべてではありません)
どうすれば修正できますか?
追加して編集:
申し訳ありませんが、私の問題は最初から思っていたものとは別のようです。サーバーにはSSL証明書が1つだけあり、example.comの1つのバインディング証明書があります。私が理解しているように、サーバーのIPアドレスごとに1つのバインド証明書しか持てません。
したがって、現在機能しない部分は、www.example.com、examplesite.com、www.examplesite.comのhttps部分です。私はLet's Encryptを使用しており、「複数のIISサイトのすべてのバインディング用のSAN証明書」があります-証明書を作成するときにその選択を使用する方法を理解する必要があります。
URL書き換えモジュールを使用していると仮定すると、_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>
_
順序が重要になる可能性があります-ルールは上から下に処理され、「フォールスルー」できるため、後続のルールもリクエストに影響を与える可能性があります-この場合、アクションタイプはRedirect
、stopProcessing
ディレクティブはおそらく冗長です。
これらの各ルールは元のパスを尊重するため、_http://www.examplesite.com/folder/page1.aspx
_へのリクエストは最終的に_https://example.com/folder/page1.aspx
_で行われます。
ルールを説明するには:
examplesite.com
_または_www.examplesite.com
_から_https://example.com
_にリダイレクトされます。www.example.com
_から_https://www.example.com/
_にリダイレクトされます。http://example.com
_から_https://example.com
_にリダイレクトされます。これらのルールには冗長性の要素を意図的に残してあります。これにより、それぞれのルールが何をするかを読みやすく理解しやすくなると感じています。
予想される動作:
http://www.examplesite.com/
_は一致しますForceToExamplehttps://www.examplesite.com/
_は一致しますForceToExamplehttp://examplesite.com/
_は一致しますForceToExamplehttps://examplesite.com/
_は一致しますForceToExamplehttp://www.example.com/
_は一致しますForceFromWwwhttps://www.example.com/
_は一致しますForceFromWwwhttp://example.com/
_は一致しますForceToSslhttps://example.com/
_はどのルールにも一致せず、アプリケーションによって処理されます注意すべきいくつかの追加ポイント:
<rewrite>
_または_<rules>
_要素をweb.configファイルから移動した場合は、アプリケーションを再起動して変更内容を確認する必要があります。redirectType="Found"
_を使用することをお勧めします。これにより302リダイレクトが発行され、ブラウザは新しいリクエストをキャッシュしません。単一の証明書の問題をカバーするように編集します
通常、サーバーのIPアドレスごとに1つのSSLバインディングしか設定できませんが、 サーバー名識別(SNI) を使用すると、単一のIPアドレスに複数のSSLバインディングを設定できます。すべての最新のブラウザで動作します。
残念ながらIIS 7.5はこれをワイルドカード証明書に対してのみサポートし、さらに名前の先頭に_*
_を付けてインストールされた1つのワイルドカード証明書に対してのみサポートします(つまり、_*.example.com
_ではなく_Wildcard example.com
_) )。これにより、_https://www.example.com
_および_https://example.com
_へのリクエストを処理できますが、Let's Encrypt証明書またはexamplesite.com(ワイルドカードSANを取得できません)には役立ちません。証明書)。
考えられる解決策は、一部のCDN(CloudFlare、Azureフロントドアなど)のSSL終了機能を使用してCDNへの要求を保護し、CDNからサーバーへの要求が保護されずに送信されることです(これらは、クライアントブラウザー)を使用して、エッジでリダイレクトすることもできます(_www.example.com
_から_example.com
_へ)。これは役立つ場合があります。