Great question—this is a super common point of confusion when setting up SSL with ASP.NET Core behind IIS! Let’s break down both approaches and when each makes sense for your setup.

When to Use IIS + web.config #

Since you’re using IIS as a reverse proxy, this is typically the primary and most straightforward approach for production scenarios:

• IIS handles SSL termination directly: You install your SSL certificate via IIS’s Server Certificates feature, bind it to your site in IIS Manager, and that’s where the public HTTPS connection is established with clients.
• By default, IIS communicates with your ASP.NET Core app over local HTTP (via the ASP.NET Core Module), so your app doesn’t need to manage SSL certificates or encryption for that internal traffic.
• In web.config, you’ll add URL Rewrite rules to enforce HTTPS (redirecting HTTP requests to HTTPS) and ensure necessary headers like X-Forwarded-Proto are passed to your app. Here’s a quick example of the rewrite rule:

  <rewrite>
    <rules>
      <rule name="HTTP to HTTPS Redirect" stopProcessing="true">
        <match url="(.*)" />
        <conditions>
          <add input="{HTTPS}" pattern="off" ignoreCase="true" />
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
      </rule>
    </rules>
  </rewrite>
  

• This approach leverages IIS’s native tools that most Windows admins are familiar with, keeping SSL management (certificate renewals, bindings, etc.) centralized in one place.

When to Use C# Code Configuration #

Code-based setup (like UseHttpsRedirection, UseHsts, or configuring Kestrel for SSL) has its place too, especially in these scenarios:

• If you’re not using IIS as a proxy (e.g., running Kestrel directly on Linux/macOS, or using Nginx instead). In those cases, Kestrel needs to handle SSL itself, so you’d define certificate paths or load certificates in code (or via appsettings.json).
• Even with IIS, you should add code to ensure your app recognizes the original request scheme. For example, using UseForwardedHeaders makes sure Request.IsHttps works correctly by respecting the X-Forwarded-Proto header from IIS:

  app.UseForwardedHeaders(new ForwardedHeadersOptions
  {
      ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
  });
  
  app.UseHsts(); // Enforce HTTPS Strict Transport Security
  

• Note: If IIS is already handling HTTP-to-HTTPS redirects, you might not need UseHttpsRedirection in code—but adding it adds an extra safety net if someone accesses the app directly bypassing IIS.

Which is "Correct"? #

Neither approach is inherently wrong—it’s about matching your setup:

• For your scenario (IIS as reverse proxy), start with IIS/web.config for SSL termination and redirects. This is the standard, Microsoft-recommended approach for IIS deployments.
• Pair it with code-based configuration like UseForwardedHeaders and UseHsts to ensure your app respects the original request context and enforces security best practices at the application level.

The core idea is that IIS manages the public SSL connection, while your ASP.NET Core app just needs to know the original request was HTTPS (via forwarded headers) and can enforce additional security rules if needed.

内容的提问来源于stack exchange，提问作者Viacheslav Yankov