Automating Remote Desktop Services certificate installation with PowerShell

If you are not taking advantage of Automatic Certificate Management, you are officially a dinosaur, desperately clinging to the good old days, when certificate issuance required blood tests, DNA samples, and voice identification.

If you have tried getting a certificate from Digicert recently, you've noticed they now insist on speaking to the organization owning the domain name, through publicly verifiable contact information. Try doing that for a lab network! Thankfully, using the ACME tools now offered by Lets Encrypt and other CAs, you can bypass all these shenanigans and get your certificates with minimal fuss and without the burdensome human interaction we IT professionals despise so much.

Another benefit of using the ACME tools is that for those junior techs who struggle with the process of getting certificates issued and installed, you can rely on automation to do the job even when certificates expire and you are on a beach somewhere.

Most of the organizations I manage are small; only one or two use Remote Desktop Services. This means for our small band of indomitable IT engineers, there is a mad scramble once or twice a year, usually while I am on vacation, to reissue an expired certificate for a Remote Desktop server that has been forgotten, with a sincere promise that next year will be different.

To that end, having previously written and implemented automatic certificate renewal for our Fortinet routers, the few RDS Servers we manage were next on the list.

Part of the Posh-ACME PowerShell module allows you to use automated DNS challenges to verify domain ownership. Having to manually complete the challenge would negate the automated nature of an automated process. To complete these challenges automatically, your domain must be hosted with a service that has API-based access to create and manage DNS records.

Amazon's Route 53 is one such service; however, I have been reluctant to move all our client domains to this service, as it is frankly a lot of work. However, if we simply delegate a portion of the domain name space to Route 53, we can take advantage of the API and keep the domain where it was originally.

To do so, have a look at my post here. Just to recap, you add a new zone to Route53, and then add the DNS records for that zone to your original zone. Finally, add a CNAME for your DNS Challenge.

The result is that any Posh-ACME request for a certificate for that FQDN is now automatically processed and issued. You can then use the normal RDS PowerShell tools to install your new certificate. Wrap this all up in a PowerShell script and a scheduled task, and you no longer get calls about expired certificates for your RDS Deployments.

Non expiring certificate

Non expiring certificate

My full script is below. But first, here's an interesting point to keep in mind. One of our clients is running a Windows Server 2012 as their RDS host. Yes, it is old now, but it is not due for renewal. In any event, the real issue is that when you install PowerShell 5.1 (or WMF 5.1) on Server 2012, a new 'feature' is enabled which breaks many of the PowerShell RDS cmdlets. However, if you enter a remote PowerShell session to the same server, from a newer server on the same network, the RDS cmdlets run perfectly well.

Expiring certificate

Expiring certificate

The script uses the Posh-ACME and AWSPowerShell modules. PowerShell remoting must be enabled on your RDS Server. The script also makes use of SMTP for notifications. If you require SMTP authentication or non-standard ports, you will need to make changes to accommodate them.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account