Using Remote Desktop Services with a self-signed SHA256 (SHA-2) certificate - help! RRS feed

  • Question

  • Hello,
    I've searched the internet high and low to find the answer to this problem and have not come up with much.

    I run a remote desktop protocol in order to access my PC remotely. The self-signed certificated which is auto-generated by Windows (in order to support the TLS encryption) is SHA1. I work in the security industry and I understand that SHA1 is phasing out.

    What is the process to upgrade this auto-generated certificate so that it will use SHA256? The closest article I've been able to find is here:, but it discusses replacing the RDP certificate with a custom SHA1 cert: it says nothing about SHA2.

    Does anybody know how to accomplish this?

    Friday, March 11, 2016 6:57 PM


All replies

  • Hi, 

    How many RDS roles and how each of them is distributed?

    How was the new certificate generated, did you install it into the Computer Personal store on RDS server?

    RDS certificate can be managed through

    Server Manager -> Remote Desktop Services -> Overview -> Tasks -> Deployment Properties -> Certificates.

    More information for you:

    Certificate Requirements for Windows 2008 R2 and Windows 2012 Remote Desktop Services

    You can try the upgrade method in this blog:

    Migrating your Certification Authority Hashing Algorithm from SHA1 to SHA2

    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact

    Monday, March 14, 2016 3:17 PM
  • Hello Kate,

    This is a Windows 10 Professional system running Remote Desktop. I don't have the "Server Manager" option.

    Where is the RDP server cert (with the SHA-1 has) stored in Windows 10?



    • Edited by rbelusko Thursday, April 14, 2016 3:02 PM
    Thursday, April 14, 2016 3:02 PM
  • Kate,

    I have the same question, and I don't think you're quite understanding what Bo is asking:

    During the installation of Windows, especially a Windows machine as part of an AD Domain, many certificates are auto-generated by the OS to facilitate secure communication from a server to a client. One of these, for example, is the certificate that handles secure communication from an RDC client to an RDC target. These certificates are self-signed and self-generated by the local machine. If you look at the certificate you'll see that the Issued to: and Issued by: fields show the name of the local machine.

    The question is: how do these auto-generated, self-signed certificates, which are currently SHA1, get upgraded to SHA2? Remember, these are not created by the local Enterprise CA, they're auto-generated by the local machine itself for Microsoft-branded software such as AD and RDC.

    Brian Brehart Network Administrator SurePayroll, Inc.

    Tuesday, August 16, 2016 8:27 PM
  • I followed this thread when it was posted wondered if someone had answer. The best I could find is MS said SHA256 for web and some other traffic, so guess RDP client certs will happen then they happen. So no answer to this thread.
    Tuesday, August 16, 2016 8:37 PM
  • The question is: how do these auto-generated, self-signed certificates, which are currently SHA1, get upgraded to SHA2?


    I haven't got a crystal ball or even a phone number of the RDS product group, but I think the answer is: they will not. It's not like Windows will stop supporting SHA-1 signed certs per se in 2017, only those issued by public CAs that MSFT themselves choose to trust.

    That said, there may be a Windows Update one day that will regenerate any auto-issued self-signed certs (which, if not handled correctly, will cause security pop-ups and, ultimately, support calls). Or, if you really would like to have SHA-2 certs on your RDS hosts, whip up a CA, make it trusted in your environment and issue them. Or issue self-signed certs by means of openSSL.

    Evgenij Smirnov

    msg services ag, Berlin ->
    my personal blog (mostly German) ->
    Windows Server User Group, Berlin ->
    Mark Minasi Technical Forum, reloaded ->

    In theory, there is no difference between theory and practice. In practice, there is.

    Tuesday, August 16, 2016 8:37 PM
  • We are having the same problem where we need to update the Remote Desktop cert from SHA1 to SHA2 due to a Nessus finding.   Hopefully someone can shed some light on this for us!
    Tuesday, August 16, 2016 10:18 PM
  • Same here, exact same situation.  I see that my home PC is running SHA-256, so what made the change there and why not on my 2012 R2 server?!

    Thursday, November 10, 2016 3:42 PM
  • Hi we have the same issue, Nesus find the that sefsigned certificate is vulnerable because use SHA1.As we have not private CA to issue certificates for RDPauth. I try to generate certificate using certreq and inf.file below. Certificate is generated successfully, I installed on affected machine and disable true registry generating old one SHA1 . But I can not able to login via RDP . Also OID=; Remote Desktop Authentication is visible as Unknown Key Usage ( after certificate is generated. n

    Do somebody have some experience

    Signature="$Windows NT$"

    Subject = "CN=DC.contoso.local"
    Exportable = true
    ProviderName="Microsoft Enhanced Cryptographic Provider v1.0"


    OID= ; Server Authentication
    OID= ; Client Authentication
    OID=; Remote Desktop Authentication

    • Edited by Chris_twin Friday, March 10, 2017 8:39 AM
    Friday, March 10, 2017 8:34 AM
  • Hello, Bo.

    Look this link:

    Use the Nartac software or configure steps in Windows Server. This post resolv my problem.

    Abs Eduardo Popovici |MTI|MCT|MCSA|MS|MCTS|

    Wednesday, March 29, 2017 6:14 PM
  • This work for me.. Thanks

    Carlos Vargas

    Thursday, August 10, 2017 10:19 PM
  • Could you please share me english version.. I am facing similar issue in my env.. 

    Thank you..

    Friday, August 11, 2017 2:13 PM
  • Praveen,

    I used Google Translate and got this. However, there is an easier answer which I will reply to separately.

    Forcing SHA-256 (or higher) with RDP on port 3389 (tested and approved) | Using Remote Desktop Services with a self-signed SHA256 (SHA-2) certificate

    Key Text: Using Remote Desktop Services with a self-signed SHA256 (SHA-2) certificate

    There has been a nice change over the policy of using digital certificates applied by Microsoft where SHA1 is being discontinued. Well, where does this impact effectively? For example, auto-signed certificates need to become more secure for access to numerous accesses, including remote access over RDP over TCP port 3389. This requirement (to this day) allows companies to become adherent or better saying "Compliant," with various security standards by related organizations, such as PCI.

    To summarize the story, Microsoft discontinued subscriptions created on the basis of SHA1 on SSL and code signing certificates by January 1, 2017 (that is, this has already happened). Natively a framework with Windows Server does not migrate its workstations and servers to the new format, so the change must be done manually. Well ... this post tells a bit about the issue of digital certification and puts a quick tool to increase the security of servers and act with the digital certification in SHA-256 format or higher.

    All certificates must have SHA2 (or greater) signature to perform remote access through the Terminal Service using RDP. In practice this policy affects "only" the certificates issued by CA that are members of the Windows root certificate program. This means that certificates issued by other CAs (including enterprise CAs) may still issue certificates signed by SHA1 after that date and will function normally (without too much trouble).

    It is good to remember that most modern applications support the SHA2 family of algorithms, so Microsoft recommends that your CA be able to sign certificates with SHA2 signature algorithms (SHA256, SHA384, SHA521). It should also be remembered that it is important to verify the existence of legacy applications within the enterprise that can sense the impact of that change. You need to ensure that a legacy application from your company supports switching from SHA1 to SHA2 or higher.

    Since the release of Windows Vista (over 7 years ago), we can say that the CNG (ECC Encryption) algorithm package is not yet widely supported and used even by the entire line of the strongest and most current products from Microsoft. For example, cloud infrastructure: System Center, Windows, and Azure do not support CNG. This is because all of these products depend on .NET that do not have full adherence. However, however and in the meantime ... there are alternative and not so complex solutions that can be made.

    Users imagine that their certificates (SSL, code signing, client authentication) must use CNG certificates to get the SHA2 signature, which is not quite the case. In fact, there is no relationship between GNC and SHA2 and no matter which public key algorithm is used in the final entity certificate is not stored in the certificate. The signature is generated by a signing authority. That is, only the CA server should use the provider that is capable of producing SHA2 signatures. Clients can use legacy providers for public keys and have SHA2 signature. The signature is generated by a sending CA.

    If you are using Windows Server 2008 (or later) with an active CA, you can move the entire PKI to make use of SHA2 without reinstalling the CAs. Although, it is possible to configure only a single CA to use the SHA2 signature, it makes no sense to perform this activity since other CAs still make use of the SHA1 legacy.

    Rule of thumb (by MVP, Vadims Podāns): All PKI must share the same public key algorithm, public key length, and signature algorithm between CAs in the tree. Do not make any errors when the root CA uses the 2048-bit RSA public key with SHA1 signature and intermediate CAs use a 4096-bit RSA public key with SHA521 signature. It is obvious that the root CA will be the target of an attack because it uses weaker keys and signatures.

    In other words, the effective security level of the PKI tree is determined by the lower and weaker properties of CAs in the tree. For example, the Root CA is 512 bits RSA and SHA256, Intermediate ECC ECDS_P256 and SHA1 will result in effective properties: Key Algorithm: RSA, Key Length: 512, Signature: SHA1.

    Use Nartac Software software to fix this problem
    (Download link:

    01. Download and install the programs from the link above;

    02. Click Best Practices;

    03. In the protocols column, leave only TLS 1.2 active;

    In the hashes column, disable MD5 and SHA;

    05. Click

    Corey Ames

    Thursday, March 1, 2018 4:02 PM
  • To anyone wanting an easier solution, I came across it here:

    The answer is to check the box in Remote Desktop setup to only allow computers to connect using Network Level Authentication.  Gotta love Spiceworks.


    Corey Ames

    Thursday, March 1, 2018 4:06 PM
  • You and Kate get it but you were able to generate a cert. I've been able to disable tls 1, get rid of older ciphers and I tried to use a trusted MS cert and got it to load but the client side said nal was not working and dropped connection. Thankfully one can log back on and the SHA1 answers. I only have Win 7 Pro and no access to Servers. Did you have success in creating a Cert? I have figured out the cert  does

    Server Authentication ( enhanced key and Key Encipherment, Data Encipherment (30).

    Ha paste killed font, Maybe leave out the client and rda OIDs? PS: This my first time doing a reply. Usually just read. Hoping you can help.

    Thursday, May 10, 2018 5:52 PM