REPLACE SELF-SIGNED MICROSOFT RDP/RDS/JUMP SERVER CERTIFICATES: A Practical Guide for Secure Environments

I previously worked with a company that was struggling to replace the self-signed certificate automatically generated when the Remote Desktop Services (RDS) role is installed on a Windows Server. This task, while seemingly straightforward, becomes a bit more complex on Windows Server 2012 and newer, since the legacy Remote Desktop Listener MMC snap-in is no longer available.

In today’s enterprise environments—especially those leveraging jump servers, Red Forest architectures, or tiered administrative models—certificate trust is not just important, it’s mandatory. These segmented environments are often used to restrict access between security tiers, reducing the blast radius in the event of a credential compromise.

For example, an administrator's regular domain account may not be permitted direct access to a secure environment. Instead, they must "check out" a privileged 2FA-enabled account, and use it to connect via a hardened jump server. However, when the RDS role is installed, Windows automatically provisions a self-signed certificate for the RDP listener, which generates a security warning on every connection.

For organizations managing their own Public Key Infrastructure (PKI), this behavior is a problem. Self-signed certificates violate internal policies, are untrusted by design, and lead to user confusion and poor security hygiene.

Since the certificate is created silently—without administrator input—and the GUI tools to replace it are deprecated, I’ve documented the method I use to replace the self-signed certificate with a valid PKI-issued certificate, eliminating the warning and complying with internal security policies.

🛠️ How to Replace the Self-Signed RDP Certificate

The process applies to both Remote Desktop Session Hosts and Remote Desktop Licensing Servers.

🔗 Reference:

Microsoft KB3042780 – Remote Desktop Listener Certificate Configurations

🚧 "Let Me Fix It" – Method 2 Implementation

✅ Step 1: Create a Certificate Signing Request (CSR)

Generate the CSR directly from the target server using your internal PKI. Use the following settings:

Subject & SAN (Subject Alternative Names):

• Use your company’s naming conventions and include relevant SANs (e.g., FQDN of the RDP server).

Key Usage:

• Key Encipherment
• Digital Signature

Enhanced Key Usage:

• Server Authentication

Private Key Options:

• Change default key size from 1024 to 2048 bits
• If issuing for a cluster or multiple servers:

Template to Use:

• A Web Server template that includes the private key (check with your PKI team to confirm compatibility).

✅ Step 2: Install the Certificate

Once you receive the certificate:

1. Install it into the “Remote Desktop” certificate store on the local computer.
2. Retrieve the certificate thumbprint:

• Open certmgr.msc
• Locate the certificate under Remote Desktop > Certificates
• Copy the thumbprint into Notepad
• Remove all spaces
• Delete any hidden or non-printable characters (especially at the beginning — sometimes a Unicode character appears invisible in Notepad but breaks the script)

✅ Step 3: Assign the Certificate via PowerShell / WMIC

Replace THUMBPRINT in the following command with the cleaned thumbprint, enclosed in quotes:

Copy and paste this into CMD or PowerShell:

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

🛠 Tip for THUMBPRINT Placeholder:

Replace "THUMBPRINT" with the actual thumbprint of your installed certificate, with no spaces or hidden characters.

✅ Step 4: Validate and Clean Up

• Reconnect to the RDP session and verify that the certificate warning is gone.
• You can safely delete the old self-signed certificate from the store.

🧠 Final Thoughts

This small, but important task can easily be overlooked during deployments—especially in high-security environments using jump servers or tiered access controls. Replacing the self-signed RDP certificate ensures trust, reduces end-user confusion, and aligns with strong internal security policies.

Let me know in the comments if you use a different approach or if you've automated this in your environment. Always happy to collaborate and learn from others in the field.

COPYRIGHT

Content Disclaimer: This article and its contents are provided "AS IS" with no warranties, and they confer no rights. Script samples are provided for informational purposes only and no guarantee is provided as to functionality or suitability. The views shared in this article reflect those of the author and do not represent the views of any companies that may be mentioned. Content Ownership: All content posted here is intellectual work and under the current law, the poster owns the copyright of the article. Terms of Use Copyright © 2011 - 2017.