We are having an issue with Accessing the Staging API ( https://acme-staging-v02.api.letsencrypt.org/directory) from Server 2012 r2! The server has TLS 1.2 enabled and it is set as the server's default. We have noticed that you have only enabled these three cipher suites for TLS 1.2
Here is a doc that lists the cipher suites supported by Windows 8.1 and 2012 R2. It does not include any of the three suites supported by the Staging endpoint.
@rg305's IIS Crypto recommendation is generally a good one. But it can't solve the fact that the OS just doesn't support those cipher suites even when fully patched. So any ACME client that relies on the OS's TLS stack won't work with the Staging server (and will eventually stop working against Production if/when they start restricting the ciphers there as well). I think @rg305's screenshot using OpenSSL only works because it does not use the OS's TLS stack.
Windows Server 2012 R2 went out of mainstream support 4 years ago (Oct 2018) and transitioned to extended support which means there will be no new features or capabilities added and only security updates released until extended support expires in October 2023.
So yeah, you're going to want to upgrade that OS sooner rather than later. If you absolutely need to use the Staging server from it, you'll have to find another ACME client that doesn't rely on the Windows TLS stack.
We are currently testing a new TLS configuration in staging. We intend to support a larger set of ciphers than what you're seeing, which is surprising to me. It's possible that the new configuration has a mistake.
I will investigate. Thank you for pointing this out!
And to directly answer your question: Windows 2012 R2 is still getting fixes by Microsoft for the next year, so we should continue to support it for at least that long.
I am glad to hear it. Thank you for making this post as well, as it alerted me to the problem. While we would have done more testing before going to production, it's quite possible we wouldn't have tested old versions of Windows and missed this incompatibility. I have a "Windows Server 2012R2 evaluation edition" VM now, so I'll make sure to test that specifically.