3

I followed

to secure RDP with a proper cert instead of the self-signed Windows one. This all works well. Until I run

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

This command only results in "Invalid param".

The same command works well with the hash of the original (self-signed Windows) cert. So I guess something must be wrong with my cert. It seems to be properly installed in the cert store (with private key & under "Remotedesktop" subsection).

Looking at the cert details in the certification MMC snapin my imported cert has a yellow exclamation mark next to:

Key Usage = Digital signature, key encryption (a0)

and the additional field

Base Limitations = Type of requester: end unit

While the self-signed cert that Windows generates for the RDP connection has:

Key Usage = Key encryption, data encryption (30)

Is there anyway to change this, or is it just not possible to use this cert for RDP?

Some additional info:

  • The cert is a COMODO PositiveSSL Wildcard cert,
  • I converted the cert from the original PEM form to PKCS7 and from PKCS7 to PKCS #12/PFX using OpenSSL prior to importing it to the Windows cert store,
  • Another difference between the certs is that the Windows one is a sha1 one while the Comodo cert is a sha256 one,
  • It's a Win10 workstation,
  • The workstation is not member of any domain but a stand-alone installation.
Community
  • 1
s1lv3r
  • 1,155
  • 1
  • 14
  • 24

2 Answers2

3

I'm afraid I must answer my own question and the answer seems to be No. Using the command openssl x509 -in cert.crt -purpose -noout -text it turns out the original cert delivered by Comodo already lacks the needed flags in the Key Usage field. It doesn't have the Data Encipherment feature.

The Comodo cert looks like this:

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Basic Constraints: critical
            CA:FALSE
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication

While the Windows self-signed cert has the following flags:

    X509v3 extensions:
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication
        X509v3 Key Usage: 
            Key Encipherment, Data Encipherment
s1lv3r
  • 1,155
  • 1
  • 14
  • 24
1

I don't know if you still need the answer for this problem, but if any one still needs it here you have it.

You really don't need the attributes specified by you.

Following the steps from this post, you will succeed the installation of any CRT (Wildcard or Normal) on a computer/domain controller.

I didn't test without the AD CS but I think it works.

The only thing you need to do is to convert the CRT/p7b to cer and then to pfx (pkcs12) using the key and the bundle. Then manually import it into your operating system.

https://blogs.technet.microsoft.com/enterprisemobility/2010/04/09/configuring-remote-desktop-certificates/ - this is the post.

https://www.sslshopper.com/ssl-converter.html - here you can find how to convert the certificates.

By the way, you can skip the WMI script part and use the following command from powershell with administrative rights:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="YOUR-THUMBPRINT-GOES-HERE"

It worked for me on Windows Server 2016/Windows 10.

Hope it helps! :)

Gavrila Bogdan
  • 11
  • 3
  • Thank you for your answer. It's very much appreciated. That's somewhat weird, because I contacted the COMODO support back than and they reassured me, that this doesn't work with their wildcard SSL product and that you would have to buy single certs, which have the needed attributes, instead. I will be sure to try your way and accept your answer instead of mine, if this works out. – s1lv3r Apr 19 '17 at 09:44
  • Ok s1lv3r! Please let me know how it goes. – Gavrila Bogdan Apr 19 '17 at 13:03
  • I can confirm that both RDP and WinRM work fine with a COMODO wildcard SSL cert. – georgiosd Nov 20 '17 at 09:44