本地Webpack+Azure Docker容器ASP.NET Core的HTTPS配置及生产部署疑问

Great work getting your local HTTPS development setup sorted out! Let's walk through exactly how to configure your production environment on Azure, so you don't have to mess with embedding certificates in your container.

The Short Answer #

You don't need to configure Kestrel to use Azure's CA certificate in production. Azure App Service handles all the HTTPS termination for you, so your containerized Kestrel can safely run over HTTP internally. Your existing portal configurations are already the core of what you need.

Breakdown of Why & How #

Here's the full picture of how production works, and what you need to verify:

1. Azure's Reverse Proxy Handles HTTPS Termination

   • When public users send HTTPS requests to your app, Azure's front-end proxy (part of App Service) uses your uploaded CA certificate to decrypt the TLS connection.
   • The proxy then forwards the request to your Linux container over HTTP (not HTTPS) to the port Kestrel is listening on (like your local 8085). This internal traffic is secure within Azure's network, so no need for HTTPS between the proxy and Kestrel.

2. Keep Your Existing Portal Configurations
   You already have the right foundation in place—just confirm these are set:

   • TLS/SSL Binding: Your CA certificate is correctly bound to your custom domain in the TLS/SSL -> Bindings section.
   • Force HTTPS: Enabled in the TLS/SSL Settings to redirect all HTTP traffic to HTTPS for public users.
   • Container Port: Ensure Azure App Service is configured to route traffic to the same port Kestrel is listening on (e.g., 8085) in your container settings.

3. Adjust Your Code for Environment Differences
   You'll want to disable the local HTTPS certificate logic in production to avoid unnecessary overhead or errors. Here's how to modify your F# code to handle development vs production:

   let configure_host (settings_file : string) (builder : IWebHostBuilder) = 
       builder.ConfigureAppConfiguration((fun ctx config_builder -> 
           config_builder 
               .SetBasePath(Directory.GetCurrentDirectory()) 
               .AddEnvironmentVariables() 
               .AddJsonFile(settings_file, false, true) 
               .Build() |> ignore)) 
       .ConfigureKestrel(fun ctx opt -> 
           eprintfn "JWTIssuer = %A" ctx.Configuration.["JWTIssuer"] 
           opt.AddServerHeader <- false 
   
           // Only enable HTTPS with self-signed cert in development
           if ctx.HostingEnvironment.IsDevelopment() then
               let certificate_file = ctx.Configuration.["CertificateFilename"] 
               let certificate_password = ctx.Configuration.["CertificatePassword"] 
               let certificate = new X509Certificate2(certificate_file, certificate_password) 
               opt.Listen(IPAddress.Loopback, 8085, (fun opt -> opt.UseHttps(certificate) |> ignore)) 
           else
               // Production: Listen on HTTP (Azure proxy handles HTTPS)
               opt.Listen(IPAddress.Loopback, 8085) 
       )
       .UseUrls("http://localhost:8085") // Update to HTTP for production (or let Kestrel use the listen config)
       |> ignore 
   builder
   

4. Add Forwarded Headers Support
   To make sure your ASP.NET Core app correctly identifies that the original public request was over HTTPS (instead of the internal HTTP from Azure's proxy), add forwarded headers middleware. This ensures things like generated links and redirects use HTTPS:

   // In your Configure method (Startup equivalent)
   app.UseForwardedHeaders(fun options ->
       options.ForwardedHeaders <- ForwardedHeaders.XForwardedProto
   )
   

Final Checks #

• Test your production deployment: Visit your custom domain over HTTPS to confirm traffic is routed correctly, and no certificate warnings appear (since you're using a CA-issued cert).
• Ensure your container doesn't include any local self-signed certificates or production-unrelated configs—keep your production image clean.

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