4

We have a Server 2016 running AD Certificate Services. Our team was asked to create a new RDP certificate so that the self-signed certificate errors would go away when RDP'ing into the system. Went ahead and generated the new certificate and installed within "Machine Certs > Personal" with the following attributes:

Key Usage = Key Encipherment / Data Enchipherment

Enhanced Key Usage = Server Authentication

Used the command in the following article: Configure custom SSL certificate for RDP on Windows Server 2012 (and later) in Remote Administration mode?

wmic /namespace:\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

Replaced "THUMBPRINT" with the thumbprint of the new certificate we created. The command was issued successfully. However, now whenever we attempt to RDP into the system we receive the following error: "Internal Error has occurred" Useful, right?

Looking at the Server 2016 Event Viewer > System logs displays the following error: "An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed."

Performed a Wireshark capture on an RDP client. As soon as the TLS 1.2 Client Hello is sent, the server immediately responds with a TCP RST. So there's some sort of cipher mismatch going on that I'm not sure how to find. Also am not able to revert back to using the old self-signed RDP certificate because the "wmic" command above seems to not like the self-signed cert thumbprint (gives me a invalid property error).

  1. We don't want to delete / rename C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, as this server is hosting AD Certificate Services and don't want to cause any further certificate errors.
  2. -Ensured that HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2 is set to Enabled=1

Anybody have any ideas as to what the cause could be?

kahuna09
  • 81
  • 1
  • 3
  • 2
    Perhaps compare the properties of the new certificate (in terms of key size and which ciphers are being used) with the properties of the self-signed one? And if appropriate try generating a new certificate that is more similar to the self-signed one. – Harry Johnston Jan 07 '20 at 04:39
  • 1
    Try with the `digitalSignature` and `keyAgreement` bit set on your `Key Usage` extension. More info in [RFC 5280](https://tools.ietf.org/html/rfc5280#section-4.2.1.3). – garethTheRed Jan 07 '20 at 07:39
  • Thanks for your suggestions. I should have mentioned in the previous post that in the new RDP certificate I actually modified the Key Algorithm to utilize ECDSA-384, whereas the self-signed RDP certificate used RSA-2048. I recreated the custom RDP certificate to use RSA-2048 and connectivity's now restored. – kahuna09 Jan 07 '20 at 16:08
  • If you're keen to try ECC, note that ECDSA will require the `digitalSignature` bit set (the DS in ECDSA), which wasn't the case in your original attempt. – garethTheRed Jan 08 '20 at 06:47

0 Answers0