An HTTPS certificate helps protect traffic between a browser and an application. Without HTTPS, someone on the network may read or change requests and responses, including sensitive details or authentication cookies. “SSL certificate” is a common name, but TLS is the newer standard. section 28.1
A TLS certificate has public and private parts. The server sends the public part to the browser and keeps the private key to itself. For the browser to trust that it has reached the intended server, the certificate must be signed through a chain leading to a trusted root certificate. A development or self-signed certificate lacks that browser trust by default, so the browser warns before connecting. section 28.2
Trust a local development certificate
ASP.NET Core can use its development certificate for local HTTPS when no other certificate is configured. On the development machine, run `dotnet dev-certs https --trust` to trust it and remove the browser warning. Do not use that certificate for production visitors: their browsers will not trust it. section 28.2
For production, obtain a signed certificate from a provider such as Let’s Encrypt or a cloud provider. Proving ownership of the domain is part of that process; the exact steps depend on the provider and operating system. If Kestrel serves HTTPS directly, configure it to use the certificate rather than its development default. Kestrel can load certificates from a .pfx file, paired .pem/.crt and .key files, or an operating-system certificate store. section 28.2 section 28.3
Listing 28.1 Configuring the default HTTPS certificate for Kestrel using a .pfx file
{
"Kestrel": { #1
"Certificates": { #1
"Default": { #1
"Path": "localhost.pfx", #2
"Password": "testpassword" #3
}
}
}
}
A JSON example sets Kestrel’s default HTTPS certificate with a .pfx file path and password. Kestrel loads the configured certificate when the application starts; this option needs no application code change. section 28.3 section 28.5
Direct Kestrel configuration is not the only deployment choice. With TLS passthrough, traffic stays encrypted through a reverse proxy to the application. With TLS offloading, the proxy decrypts it and handles the certificate instead. Whichever component handles the certificate, HTTP-to-HTTPS redirection and HSTS address a separate concern: steering browser requests toward HTTPS. section 28.1 section 28.5
