Built for Remote Desktop
Pre-built templates for the RDP listener and standalone RD Gateway ship in your CertKit account. No scripting required.
Out of the box, Remote Desktop presents a self-signed certificate, so every connection starts with "the identity of the remote computer cannot be verified." Bind a real certificate and the warning goes away, until the certificate renews and the listener, which pins it by thumbprint, quietly falls back or goes stale. Every 47 days. On every RDP host and every RD Gateway.
CertKit centralizes certificate issuance and renewal, then pushes the renewed certificate to your Remote Desktop hosts via the CertKit Agent, updates the RDP listener, and rebinds standalone RD Gateways.
Pre-built templates for the RDP listener and standalone RD Gateway ship in your CertKit account. No scripting required.
The CertKit Agent imports the renewed PFX and points the RDP-tcp listener at the new thumbprint through WMI. No service restart, no dropped sessions, and the next connection presents the trusted certificate. On a standalone RD Gateway, the agent rebinds the gateway certificate and restarts the service so remote clients tunnel over the renewed certificate.
Both pre-built templates ship with your CertKit account. Enable them once per host. CertKit handles every renewal after that.
The manual process, if you want to do it yourself:
Win32_TSGeneralSetting, SSLCertificateSHA1Hash), set it
with PowerShell. No restart needed, the next session uses it.
Every one of these steps is manual, and Remote Desktop won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, installation stops being an annual chore and becomes a recurring task: eight times a year, on every host. Miss the gateway and remote access breaks. Miss a host and the warning is back, and users click through it, which is exactly the habit the certificate was supposed to end.
At 47 days, automation is the only sustainable way to run Remote Desktop certificates. Here's how CertKit does it.
Your RDP host / gateway CertKit ACME CA ┌───────────────────┐ ┌──────────────────┐ ┌─────────────┐ │ │ │ │ │ │ │ ┌───────────────┐ │ Issue & Renew │◄──►│ │ │ │ CertKit Agent │◄──┤ Certificates │ │ │ │ └─────────┬─┬───┘ │ ┌───┐ └─────────────┘ │ │ │ │ └───────────┬────│DNS│ │ Cert store ◄─┘ │ │ │ └───┘ │ [x] Updated │ │ │ │ │ │ │ │ RDP listener ◄──┘ │ ◄───────────────┘ │ [x] Rebound │ Verify └───────────────────┘
CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record and CertKit handles every ACME challenge after that. Your Remote Desktop hosts never run an ACME client and never hold DNS credentials. The agent imports the certificate and updates the listener locally.
CertKit is an invaluable tool for administrators managing public TLS certificates in Microsoft environments like Always On VPN (SSTP) and DirectAccess (IP-HTTPS), as it simplifies and fully automates Let's Encrypt certificate issuance and renewal. CertKit eliminates the security risks and complexities of manual DNS challenges or API key exposure.
Richard Hicks, Consultant and Microsoft MVP
A fresh Windows host generates its own self-signed RDP certificate, and no client trusts it, so the warning appears on every connection. Most organizations either teach users to click through, which erases the one signal that would catch a man-in-the-middle, or bind a real certificate and inherit the renewal chore this page describes. An expired certificate brings the same warning back, which is why "remote desktop certificate expired" is one of the most-searched RDP problems.
The durable fix is a trusted certificate that matches the connection name and never reaches expiry. That's a renewal automation problem, not a one-time setup problem.
The RDP listener has no certificate picker. It pins a SHA1 thumbprint in WMI, and nothing in the GUI updates it, so a renewed certificate sits unused in the store while the listener presents the old one or falls back to self-signed. The private key ACL is the other silent failure: if NETWORK SERVICE can't read the key, the listener ignores your certificate without an error anywhere you'd look.
Scripting it means WMI property writes, thumbprint formatting, per-host loops, and a separate code path for gateways. We built and tested both deployments so you don't have to. CertKit issues the certificate via delegated DNS validation, then the agent handles the import, the listener update, and the gateway rebind as one verified step, with no ACME client on any host.
Most Windows environments have more than one place where certificates live: IIS, Exchange, RRAS, and Always On VPN. CertKit automates all of it from one account.
Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.