SSL/TLS offloading protects browser traffic by terminating HTTPS at a reverse proxy, which forwards requests to the application over HTTP. The application therefore avoids managing TLS certificates itself while users still connect securely. section 28.1 section 28.5
A typical offloading arrangement works as follows:
- The browser connects to the reverse proxy using HTTPS and a TLS certificate. section 28.1
- The reverse proxy decrypts the request and forwards it to the ASP.NET Core application over HTTP. section 28.5
- The proxy adds X-Forwarded-Proto so ASP.NET Core can recognize that the original request used HTTPS. section 28.4.2
- ForwardedHeadersMiddleware updates the request, allowing HTTPS redirection and other secure-request behavior to work correctly. section 28.4.2
Production deployment
Place IIS, NGINX, or HAProxy in front of the application, or use a service such as Cloudflare. Configure the intermediary with the production certificate, let it handle HTTPS, and configure ASP.NET Core to trust forwarded headers. The application can then receive HTTP from the proxy without configuring Kestrel with its own production certificate. section 28.5 section 28.4.2
Figure 28.3 You have two options when using HTTPS with a reverse proxy: SSL/TLS passthrough and SSL/TLS offloading. In SSL/TLS passthrough, the data is encrypted all the way to your ASP.NET Core app. For SSL/TLS offloading, the reverse proxy handles decrypting the data, so your app doesn’t have to.
Compare SSL/TLS passthrough, which keeps traffic encrypted to the application, with offloading, which has the reverse proxy decrypt it. section 28.1
