2

Platform Details: C#, .Net Core 2.0, WS 2016, IIS & Kestrel in reverse proxy

My web app must use HTTPS and TLS 1.2. It was running fine with SSL already, but that is inadequate. I found details online about registry edits needed for TLS 1.2 as default on my web server, and made those changes. After these registry edits, my original code still worked. To force the use of TLS1.2 I added the following to my UseKestrel() in the buildwebhost method.

options => { options.Listen(System.Net.IPAddress.Loopback, 443, listenOptions => { listenOptions.UseHttps(new HttpsConnectionAdapterOptions { SslProtocols = SslProtocols.Tls12 }); } }))

Now the site is throwing a 502.5. IIS is configured with the original certificate and the site is bound to port 443. I've been told the cert itself is the same between SSL and TLS, so I don't need to get another. When I attempt to debug the code with local host my VS returns an error saying

System.ArgumentException: 'The server certificate parameter is required.'

I have found detail of an "X509Certificate2" object, and some different implementations where the author is using a load method to stream that certificate from a location on the server, but I don't know if that's what's needed here.

Improve this question
3
  • You don't need to do anything special. The default is to use the OS's option, which means the strongest available algorithm is used first. On WS 2016, that is TLS 1.2. You'd need to specify something only if you wanted to disable eg TLS1.1. Commented Jan 11, 2019 at 16:46
  • 1
    The out-of-the-box ASP.NET Core 2.1 template configures TLS, HSTS etc in its default configuration. Check Scott Hanselman's article from August 2018. 2.0 is already out of support. The long term release version in the 2.x series is 2.1 Commented Jan 11, 2019 at 16:51
  • If you want to disable lesser versions of TLS, you must do so at the OS level. As @PanagiotisKanavos said, the server will always use the highest compatible version, but if a really old client comes by asking for TLS 1.0, it'll be served over that unless it's disabled by the OS. In which case, the client would then simply denied access altogether. Commented Jan 11, 2019 at 17:00

1 Answer 1

Reset to default
1

The answer is in the comments of the question. The server was provided with an image that didn't include TLS 1.2 by default so the registry edits we did were actually required, but nothing more

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Please choose your answer as the correct answer with more details about your issue.
As the comments pointed out, the WS2016 OS should have been configured to use TLS 1.2 by default. Part of the organization's provisioning process removed TLS1.2 from the server, so editing the registry to re-enable TLS1.2 was the solution. There was no further change needed.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.