Encryption with HTTPS is a key piece of the web security puzzle. Learn how ASP.NET Core handles HTTPS and how the configuration will vary depending on your hosting choices.
- [Instructor] Using HTTPS or connection level encryption is a very important part of keeping a modern web application secure. ASP.NET Core has always supported HTTPS but starting with ASP.NET Core 2.0, HTTPS is enabled by default. When you create a new application from the built-in templates, HTTPS is enabled using a local development only certificate. In the project properties panel in the Debug tab, you can see Enable SSL turned on and a separate HTTPS port for the application.
When I run this application, I can see in my browser that I get a HTTPS connection and it's secure, even on my local machine. This helps you test HTTPS locally while you work on your project but when it comes time to deploy to production you need to plan how you'll install a real HTTPS certificate. As I mentioned in the server architecture overview, you have two options depending on what your infrastructure looks like. If your application is hosted on an edge server with no reverse proxy, you'll configure and install the certificate at the Kestrel or Http.sys layer.
That way the server can encrypt responses that it sends back to browsers and clients. If you are using a reverse proxy or load balancer, you'll install and configure the certificate at the proxy layer instead. The proxy will forward requests over plain HTTP to your internal servers along with special headers that indicate that the request is being forwarded. You'll need to add a few lines of code to your ASP.NET Core application to recognize these headers. I'll dive into both of these scenarios in more detail, next.
- Setting up your ASP.NET project
- Choosing a deployment strategy
- Configuring HTTPS and forwarding
- Deploying to IIS
- Deploying to Azure
- Deploying to Linux
- Deploying with Docker