Automating SSL Certificate Renewals for RDS and RDP Servers

Why RDS certificates are uniquely painful for MSPs

A certificate on a public-facing website can often be renewed automatically by the web server itself — the ACME client runs locally, responds to HTTP-01 challenges on port 80, and everything happens without human involvement. RDS and RDP servers don't work that way.

Windows Remote Desktop Services requires a certificate to be bound in a specific way across the RD Gateway, RD Web Access, and RD Connection Broker roles. The certificate has to land in the right place in the Windows certificate store. Port 80 is typically not open on these servers — and it shouldn't be, because opening it on an infrastructure server just to satisfy an ACME challenge creates a compliance problem you don't want to explain to a security auditor.

The result: most MSPs have been doing this manually. Log into each server, generate a certificate signing request, go through the CA's web interface, download the cert, run a PowerShell script to bind it to RDS, then remember to do it again in 12 months. With 90-day certs, that schedule compresses to every 60 days if you want any buffer at all. Across a client base with multiple servers each, the maths stops working quickly.

The certificate lifetime trend:

Let's Encrypt has always issued 90-day certificates. The CA/Browser Forum is moving toward shorter lifetimes industry-wide. Apple already announced that certificates with lifetimes over 47 days won't be trusted in Safari from late 2027. For MSPs still managing certs manually, this is a countdown to a staffing crisis.

The port 80 problem — and why DNS-01 solves it

The standard ACME challenge type — HTTP-01 — works by asking the certificate authority to call a URL on port 80 of the server you're issuing a certificate for. If the server answers with the right token, the domain ownership is confirmed and the cert is issued.

For RDS servers, this is a problem in three ways:

1. Firewall rules — RDS servers are typically only accessible on RDP-specific ports. Opening port 80 inbound means changing firewall rules on potentially hundreds of servers.
2. No web server — there's no IIS or nginx listening on port 80 by default. You'd need to stand up a temporary HTTP listener just to pass the challenge, which ACME clients can do but it's yet another moving part.
3. Compliance exposure — any inbound port on an infrastructure server that processes sensitive data expands the attack surface in ways that compliance frameworks — HIPAA, SOC 2, Cyber Essentials — take note of.

DNS-01 challenges sidestep all of this. Instead of proving domain ownership via an HTTP response, you prove it by creating a specific TXT record in the domain's DNS zone. The ACME client writes the record, Let's Encrypt reads it, the certificate is issued, and the TXT record is cleaned up. No port 80. No firewall changes. No compliance conversation.

DNS-01 requires DNS API access:

For DNS-01 automation to work end-to-end without human involvement, the ACME client needs to be able to create and delete TXT records in the domain's DNS zone via API. Most major DNS providers — Cloudflare, Route 53, DNSimple, and others — support this. If client domains are fragmented across registrars and DNS providers, obtaining and storing API credentials for each one becomes its own operational problem. Consolidating DNS management under the MSP eliminates this friction entirely.

The per-server approach doesn't scale

The instinctive fix is to put an ACME client directly on each server — a local agent that handles the DNS-01 challenge autonomously and imports the renewed certificate into the Windows store on schedule. For a single server at a single client, this works. When you're managing 50 clients with multiple RDS servers each, it creates a different set of problems:

→ Visibility — which certs are expiring in the next 30 days across all clients? There's no dashboard for this. You're either building it yourself or you find out when a client calls saying their RDS connection is throwing a certificate warning.
→ DNS credential management — a per-server ACME client needs API credentials for every DNS zone to do DNS-01 validation. Storing those credentials securely per-server, per-client, and keeping them updated as API tokens rotate is a hidden operational burden.
→ Renewal failure detection — if a renewal fails silently at 3am because a DNS TXT record didn't propagate in time, who finds out? The answer is usually: the client, when their certificate expiry date arrives and remote desktop starts throwing untrusted cert warnings.
→ Offboarding — when a client leaves, every scheduled task, stored API key, and cert configuration on their servers needs to be cleaned up. With ad-hoc per-server tooling, that inventory rarely exists.

The pattern that works at scale:

The MSPs who have solved this cleanly take a different approach: certificate issuance is not managed by the server. The server has a lightweight agent that polls a central system for a renewed certificate and installs it when one is available. The ACME challenge, the DNS interaction, the renewal schedule, and the failure alerting all happen in one place — not on 200 different Windows servers.

A centralized approach: issue once, deploy automatically

The architecture that scales is straightforward. A central platform handles the ACME lifecycle — requesting the certificate, completing the DNS-01 challenge against the domain's DNS zone, storing the renewed certificate securely, and triggering renewal 30 days before expiry. The Windows server runs a small scheduled polling agent that checks in periodically and imports a fresh certificate whenever one is available.

This decoupling has several concrete benefits for an MSP managing a large client fleet:

→ No DNS credentials on servers — the DNS API key lives in one place. The server never needs to know anything about the DNS provider. When you rotate a credential, you do it once.
→ Fleet-wide visibility — all certificates are in one inventory. Expiry dates, renewal status, last-seen timestamps from the agent — everything is visible from a single view rather than inferred from scheduled task logs on individual servers.
→ Failure alerts before expiry — if the DNS-01 challenge fails, the platform sends an alert immediately rather than letting the certificate quietly expire. You have time to investigate before the client is affected.
→ Client-scoped access — certificates are organised by client. Adding a new certificate for a client, viewing their expiry timeline, or revoking a compromised cert is done in one place with full audit history.
→ Works with managed DNS — if the client's DNS is already managed by the MSP, the DNS-01 challenge is fully automated with no additional credential management. No new API keys, no per-client DNS configuration on servers.

How it works in Albaspot

Albaspot's Certificates feature is built for exactly this architecture. You request a certificate for a domain — an RDS server FQDN, a VPN gateway, a Remote Desktop Web Access endpoint — and Albaspot handles the Let's Encrypt DNS-01 challenge automatically against the domain's DNS zone. No port 80. No firewall changes. No changes to the Windows server until the certificate is ready to deploy.

Once issued, a PowerShell installer is generated from the certificate detail page. Run it once on the Windows server as Administrator — it sets up a Scheduled Task that polls the Albaspot API for renewed certificates and imports them into the Windows certificate store automatically. Renewal at 30 days is handled centrally. The server wakes up, finds a fresh certificate, imports it, and reports back. You don't need to touch the server again.

The certificate detail page shows agent connectivity and last-seen timestamps so you can confirm the agent is running on each server. If a renewal fails — DNS propagation delay, rate limit, domain no longer in your DNS account — an email alert goes out with the specific failure reason and a Retry button. The auto-renewal flow also sends email at 30, 14, and 7 days before expiry so there's always a backstop.

Works best alongside managed DNS:

When a client's DNS is already managed through Albaspot, the DNS-01 challenge requires zero additional setup. No API keys to store, no per-client DNS configuration. The certificate request, DNS challenge, and renewal all run through the same platform. See DNS management for how Albaspot centralises client DNS zones.

What about client DNS you don't yet manage?

Albaspot's DNS-01 implementation is built around the DNS zones the MSP manages through the platform. Certificate issuance is only available for domains whose DNS is already in Albaspot — there's no separate credential entry for external providers. This is a deliberate constraint: it keeps credentials centralised and removes the attack surface of storing third-party API keys on individual servers.

For MSPs mid-transition, the path is to bring the client's domain into Albaspot first — either by pointing nameservers to Albaspot's DNS or by transferring the domain registration — then issue the certificate. The migration is a one-time step; every certificate request and renewal for that domain is then fully automated in the same platform with no further credential management.

Taking ownership of client DNS is one of the highest-leverage things an MSP can do — not just for certificate automation, but for DMARC enforcement, subdomain hygiene, domain renewal tracking, and every other DNS-dependent workflow. Certificate issuance is often the immediate forcing function that drives the conversation forward.

Preparing for 47-day certificate lifetimes

Apple's announcement that Safari will reject certificates with lifetimes over 47 days from late 2027 is not a distant problem. The CA/Browser Forum is moving in the same direction. When that change lands, any certificate management process that requires human involvement at renewal time becomes untenable: 47-day intervals across a fleet of 200 servers means someone is renewing certificates every single week.

The MSPs who will handle this without additional headcount are the ones who have already decoupled certificate renewal from manual intervention. The ones who are still relying on calendar reminders and RDP sessions will be in a very uncomfortable position when clients start seeing browser warnings on their RDS Web Access portals.

The 90-day window for action:

Let's Encrypt 90-day certs already give you a useful test bed. If your renewal process works fully automatically on 90-day certs today — no human touches required, failures alerting before expiry, agent-deployed renewals confirmed — then 47-day certs will just run twice as often. If your process requires manual steps on 90-day certs, use that as the forcing function to fix it before the timeline compresses further.

Automating SSL Certificate Renewals for RDS and RDP Servers Across Every Client