Share via

Windows server 2016 RDP TLS /SSL certificate

sara rashid 20 Reputation points
2026-06-10T14:47:44.7633333+00:00

I am reviewing the TLS/SSL certificate configuration used for remote desktop services on windows server 2016 VM and would like some help

During the review of the remote desktop certificate . i observed a message "The root CA certificate is not trusted because it is not in the trusted root certification authorities store"

Can someone please confirm

  1. how can i definitely determine whehther the currently assigned cert is default self signed or issued by internal CA.
  2. if the certificate is the default self-signed RDP cert
    1. what is recommended process for replacing it with CA-issued certification?
    2. if there are more tha one VM, should individual CSR's be generated per VM using each server FQDN?
    3. Is there a process of generating CSR on VM?
    4. Once cert issued, what is the preferred installation and binding process for RDP services on each VM?

Thanks

sarah

Windows for business | Windows Server | Directory services | Certificates and public key infrastructure (PKI)
0 comments

Answer accepted by question author

Quinnie Quoc 11,565 Reputation points Independent Advisor
2026-06-10T15:25:03.5+00:00

Dear sara rashid,

To determine whether the current Remote Desktop certificate is the default self‑signed one or issued by your internal CA, open the Certificates MMC on the Windows Server 2016 VM and check under Computer → Remote Desktop → Certificates. The default self‑signed RDP certificate will show “Issued To” and “Issued By” as the server’s own hostname, with a validity of one year. If it is CA‑issued, the “Issued By” field will reference your internal CA and the trust chain will validate against Trusted Root Certification Authorities. The warning you observed confirms that the root CA is not present in the trusted root store, which is why the certificate is not trusted.

The recommended process is to generate a certificate request (CSR) per VM using its fully qualified domain name, submit it to your internal CA, and then install the issued certificate into the local computer’s personal store. Once imported, bind it to RDP by running Set-RDCertificate -Role RDGateway -Thumbprint <certthumbprint> or using the Remote Desktop Deployment Properties in Server Manager. Each VM should have its own certificate matching its FQDN to avoid validation errors. CSR generation can be done with the Certificates MMC or PowerShell (New-SelfSignedCertificate for testing, or certreq for CA submission).

If my answer is useful for you, please hit Accept the answer to support me.

Thank you,

QQ.

Was this answer helpful?

2 people found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-10T14:48:56.93+00:00

    To determine and manage the RDP TLS/SSL certificate on Windows Server 2016, use the certificate stores and RDP listener configuration.

    1. Determine whether the current RDP certificate is self-signed or CA-issued
    2. Open the Certificates MMC for the local computer:
      • Run mmc → File → Add/Remove Snap-in → Certificates → Add → Computer account → Local computer.
    3. In the console tree, expand Certificates (Local Computer).
    4. Check the RDP certificate in one of these locations (depending on configuration):
      • Remote Desktop → Certificates (for the default RDP self-signed cert), or
      • Personal → Certificates (for custom/server-auth certificates used by RDS roles).
    5. Open the certificate and review:
      • Issued by:
        • If it shows the server name itself, or a generic “Remote Desktop” issuer, it is typically the default self-signed RDP certificate.
        • If it shows an internal CA name (for example, a corporate CA), it is CA-issued.
      • Certification Path tab:
        • If the root CA is not in Trusted Root Certification Authorities, you see the message that the root CA is not trusted.

    Additionally, for older or manually configured listeners, check the registry binding:

    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
    • Value SSLCertificateSHA1Hash (if present) contains the thumbprint of the bound certificate. Match this thumbprint to a certificate in the Personal or Remote Desktop store to see which cert is actually bound.
    1. Recommended process if the certificate is the default self-signed RDP cert

    a) Replace with a CA-issued certificate

    1. Ensure the CA-issued certificate meets RDS requirements:
      • Server Authentication EKU (1.3.6.1.5.5.7.3.1).
      • Enhanced Key Usage (OID 2.5.29.37) and Key Usage (OID 2.5.29.15).
      • Issued by a CA trusted by the servers and clients.
      • Exportable private key and available as .pfx if needed.
    2. Request/issue a certificate whose Subject or SAN includes the server’s FQDN used by clients.
    3. Install the certificate into the Personal store of the computer account on each RDS server.
    4. Bind the certificate to the RDP listener:
      • For pre-2012 style configuration (or when using the listener directly):
        • Set SSLCertificateSHA1Hash under RDP-Tcp to the certificate thumbprint (no spaces, comma-separated bytes when exported as REG_BINARY).
        • Ensure the NETWORK SERVICE account has Read permission on the certificate’s private key (via Manage Private Keys in the Certificates MMC).
      • For RDS deployments using RDS roles, use the RDS management tools to assign the certificate to the appropriate roles (RD Gateway, RD Web, RD Connection Broker, etc.) as documented in the RDS certificates guidance.

    b) One VM vs multiple VMs – CSR and FQDN

    • Each RDP endpoint (each Windows Server) typically presents a certificate whose name matches the server FQDN that clients connect to.
    • In a simple per-VM scenario:
      • Yes, it is standard to issue a separate certificate per VM, with the CN or SAN set to that server’s FQDN.
    • In more advanced RDS deployments (for example, with a Connection Broker and DNS load balancing), a shared certificate for the farm name may be used, but that is outside the basic per-VM scenario.

    c) CSR generation on the VM

    • When using an internal AD CS, CSRs are typically generated via:
      • Certificates MMC → Personal → Certificates → All Tasks → Advanced Operations → Create Custom Request, or
      • Using AD CS web enrollment or templates.
    • The context provided emphasizes that if using AD CS, a certificate template (for example, a duplicate of the Web Server template) can be created and used to issue appropriate server-auth certificates for RDS.
    1. Installation and binding process (per VM)

    For each Windows Server 2016 VM:

    1. Install the CA-issued certificate
      • Import the certificate (with private key) into Certificates (Local Computer) → Personal.
    2. Ensure trust chain
      • Install the issuing CA and root CA certificates into Intermediate Certification Authorities and Trusted Root Certification Authorities stores as appropriate so that the chain is trusted and the “root CA not trusted” warning disappears.
    3. Grant private key access
      • In Certificates MMC, right-click the certificate → All Tasks → Manage Private Keys → add NETWORK SERVICE with Read permission.
    4. Bind the certificate to the RDP listener
      • For direct listener configuration (pre-2012 style):
        • Set SSLCertificateSHA1Hash under RDP-Tcp to the certificate thumbprint as described in the “Remote Desktop listener certificate configurations” guidance.
      • Restart Remote Desktop Services (TermService) or the server so the listener picks up the new certificate.
    5. Verify
      • From a client, connect via RDP and inspect the certificate presented; confirm it shows the CA-issued certificate with a trusted chain and the correct subject name.

    If at any point the RDP self-signed certificate is used or needs to be re-created, the documented procedures for deleting the existing certificate from Remote Desktop\Certificates and restarting the Remote Desktop Services/Configuration services will regenerate it, provided the MachineKeys permissions and required services are correctly configured.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.