Let's Encrypt on Windows Server: IIS Setup, Renewal, and Common Errors

Overview

If your goal is to deploy HTTPS on IIS with a Let’s Encrypt certificate and keep renewal automatic, the cleanest path on Windows Server is usually a dedicated ACME client built for the platform. In practice, many admins use win-acme for IIS Let’s Encrypt workflows because it can discover IIS sites, request a certificate, install it into the Windows certificate store, update IIS bindings, and configure scheduled renewal.

The high-level process looks like this:

1. Make sure the domain points to the correct server.
2. Confirm IIS is serving the intended site.
3. Choose a validation method, usually HTTP-01 for public websites or DNS-01 for special cases.
4. Request the certificate with your Windows ACME client.
5. Bind the certificate to the IIS site on port 443.
6. Test HTTPS, redirects, and application behavior.
7. Verify that renewal is scheduled and actually works.

That sequence stays stable even when tools evolve. The details change, but the operational checks do not. That is why this topic is worth revisiting whenever you rebuild a server, add hostnames, move DNS, or change reverse proxy behavior.

Before you begin, keep two assumptions in mind. First, Let’s Encrypt issues certificates only after your control of the domain is validated. Second, automation matters more than initial issuance. A certificate that installs correctly once but does not renew is not a finished setup.

If you manage mixed environments, it may also help to compare this Windows workflow with Linux guides such as Let’s Encrypt on Ubuntu: Step-by-Step Setup for Current LTS Releases or Let’s Encrypt on Debian: Step-by-Step Setup for Stable Releases. The platform steps differ, but the certificate lifecycle is the same.

Checklist by scenario

Use the checklist that matches your environment. The core idea is to reduce surprises before requesting the certificate.

Scenario 1: Single IIS site on one public Windows Server

This is the standard case for Let’s Encrypt Windows Server deployments.

• DNS: Confirm the A or AAAA record for the hostname points to the correct public IP.
• Port access: Ensure ports 80 and 443 are reachable from the internet and not blocked by perimeter firewall rules.
• IIS site binding: Verify the site exists in IIS and has the correct hostname binding.
• HTTP test: Browse to http://yourdomain.example and confirm the expected site responds.
• Validation path: Prefer HTTP-01 unless you have a reason to use DNS-01.
• Client installation: Install your chosen ACME client, commonly win-acme setup, on the server hosting IIS.
• Certificate request: Request a certificate for the exact hostname or hostnames needed.
• IIS installation: Let the client install the certificate into the Windows store and update HTTPS bindings.
• Redirect: Add an HTTP to HTTPS redirect once HTTPS is confirmed to work.
• Renewal: Verify the renewal task exists in Task Scheduler and note where logs are stored.

Scenario 2: Multiple hostnames on the same site

If one IIS site answers for several hostnames, think carefully about certificate scope before you request anything.

• List every hostname that must be covered, such as example.com and www.example.com.
• Remove old or unused bindings from IIS to avoid accidental selection mistakes.
• Decide whether you want a single SAN certificate for multiple names or separate certificates for different sites.
• Check that each hostname resolves publicly and reaches the same server if using HTTP validation.
• After issuance, test each hostname individually in a browser and with a TLS inspection tool.

This is where admins often assume that one successful certificate request covers every alias automatically. It does not. If a hostname is not included in the certificate request, browsers will still warn for that hostname.

Scenario 3: Site behind Cloudflare or another reverse proxy

Proxy services can simplify some parts of DNS and performance, but they also change validation behavior.

• Confirm whether the hostname is proxied or only using DNS.
• For HTTP-01, make sure requests to the ACME challenge path can reach the origin correctly.
• If proxy behavior interferes with validation, consider DNS-01 instead.
• Keep certificate mode decisions consistent between Cloudflare and your origin server so you do not create redirect loops or TLS mismatches.
• Test the origin directly if possible before blaming the ACME client.

If your environment depends on DNS-based validation, see Let’s Encrypt DNS-01 Automation by Provider: Cloudflare, Route 53, DigitalOcean, and More.

Scenario 4: Internal app, staging host, or non-public IIS service

Let’s Encrypt is designed for publicly reachable names. If the hostname is not publicly resolvable or not reachable for validation, adjust your plan before spending time troubleshooting the client.

• Check whether the hostname is a public DNS name.
• Confirm the validation method is possible from the public internet.
• If HTTP-01 cannot work because the service is private, use DNS-01 only if you control public DNS for that hostname.
• If the environment is purely internal and not publicly delegated, a private CA may be the better fit.

This is a common source of confusion with free SSL for IIS: the certificate authority still needs a valid public validation path.

Scenario 5: Renewal after migration or server rebuild

Renewal is where many otherwise successful deployments fail.

• Do not assume the old scheduled task carried over after migration.
• Confirm the ACME client’s configuration and renewal data exist on the new server.
• Check that the IIS site bindings on the new machine match the old environment.
• Verify the new server can write to the certificate store and update IIS.
• Run a manual renewal test well before expiry.

For a wider renewal workflow, see How to Renew Let’s Encrypt Certificates Automatically and Verify It Actually Works and Let’s Encrypt Expiry Monitoring: Best Tools, Alerts, and Dashboard Options.

What to double-check

Before and after issuance, these checks catch most avoidable problems.

1. DNS resolution matches the intended server

If the hostname points somewhere else, validation will fail or the wrong server will answer. Check both A and AAAA records if IPv6 is enabled. A surprising number of renew SSL on Windows Server issues come from old DNS records that nobody noticed after a host move.

2. Port 80 still matters

Even if your long-term goal is HTTPS-only, HTTP access is commonly needed for HTTP-01 validation. If port 80 is blocked, redirected incorrectly, or intercepted by another application, certificate issuance can fail. Do not close port 80 until you fully understand your validation method and renewal path.

3. IIS bindings are explicit and clean

Review site bindings in IIS Manager:

• correct hostname
• correct port
• correct IP assignment, if you use specific addresses
• HTTPS binding attached to the expected certificate

Messy bindings create hard-to-diagnose behavior, especially on servers with many sites.

4. The certificate private key is usable

A certificate in the Windows store is not enough by itself. IIS must be able to use the associated private key. If the key is missing, inaccessible, or imported incorrectly, HTTPS may fail even though the certificate appears present.

5. Scheduled renewal is visible and testable

Do not stop at “the task exists.” Open Task Scheduler and verify:

• the task is enabled
• the run account is appropriate
• the executable path is correct
• recent runs show success
• logs are available if it fails

Then run a safe manual renewal check. Automation is only trustworthy once you have seen it execute correctly.

6. Redirect logic does not break validation or app behavior

HTTP to HTTPS redirect rules belong after successful certificate installation and testing. Keep them simple. Watch for:

• redirect loops
• mixed-content issues after enabling HTTPS
• application hard-coded URLs pointing to HTTP
• conflicts between IIS rewrite rules and upstream proxy redirects

If your application is WordPress on IIS or mixed hosting, related HTTPS cleanup patterns may overlap with Let’s Encrypt for WordPress: Hosting Requirements, Plugin Options, and HTTPS Fixes.

7. Certificate coverage matches reality

Open the site in a browser and inspect the certificate subject and SAN entries. Confirm every public hostname users actually type is covered. This includes common variations like apex and www.

Common mistakes

The fastest way to troubleshoot IIS Let’s Encrypt problems is to start with the mistakes that recur most often.

Requesting a certificate before DNS is fully switched

Admins often start issuance while a domain is still pointing at the previous host or while a load balancer is split between old and new origins. Validation becomes inconsistent. Finish DNS changes first, then verify externally, then request the certificate.

Forgetting that another service is listening on port 80

Non-IIS software, security tooling, or an old development service can claim port 80. The ACME challenge reaches the server but not the site you expect. Confirm the actual listener and test from outside the server.

Using the wrong validation method for the environment

HTTP-01 is usually simplest for a normal public website. DNS-01 is better when:

• the site is behind restrictive network controls
• you need a wildcard certificate
• proxy behavior interferes with HTTP validation
• the server itself should not expose port 80 publicly

Do not force HTTP validation into a design that clearly wants DNS validation.

Assuming installation equals renewal

A successful first run does not guarantee future success. Scheduled tasks can be disabled, service accounts can change, file paths can move, and DNS can drift over time. This is why renewal checks belong in your operating procedure, not as a one-time thought.

Installing HTTPS without testing application-level behavior

The certificate may be valid while the site still behaves poorly over HTTPS. Watch for login redirects, API callback failures, mixed content, HSTS added too early, and legacy integrations pinned to HTTP URLs.

Leaving old certificates and bindings in place indefinitely

Windows servers that have been upgraded several times often accumulate stale certificates and overlapping IIS bindings. That clutter increases the odds of selecting the wrong certificate during updates or renewals. Periodic cleanup reduces ambiguity.

Ignoring monitoring until close to expiry

By the time a browser warning appears, the response window is short and user-visible. Basic expiry monitoring is cheap insurance. Even a simple reminder plus a monthly verification habit is better than waiting for complaints.

If you are comparing ACME clients beyond Windows, this broader overview may help: Certbot Alternatives for 2026: When to Use acme.sh, Dehydrated, Win-ACME, or Caddy.

When to revisit

This checklist is most useful when something changes. Revisit your Let’s Encrypt Windows Server setup in these situations:

• Before seasonal planning cycles: review certificate expiry dates, scheduled tasks, DNS ownership, and documented recovery steps.
• When workflows or tools change: if you switch ACME clients, upgrade Windows Server, rebuild IIS, or alter proxy behavior, re-test issuance and renewal.
• After a DNS provider or registrar change: validate that A, AAAA, and any DNS automation assumptions still work.
• After site migrations: check bindings, firewall rules, and external reachability on the new host.
• When adding hostnames: confirm the existing certificate still covers the new names or request an updated certificate.
• When tightening security controls: verify that new firewall or WAF rules do not block renewal.

A practical maintenance routine can be very simple:

1. List every public IIS hostname and its certificate expiry date.
2. Document which ACME client is installed and where its logs live.
3. Open Task Scheduler once a month and confirm renewal tasks are healthy.
4. Run an external HTTPS check against each important hostname.
5. Test a non-production renewal path or dry-run equivalent where your tooling allows it.
6. Clean up stale bindings and old certificates during normal maintenance windows.

If you are evaluating where Windows-based sites should live long term, hosting choices also affect SSL reliability, firewall access, and operational simplicity. These related guides may help: Best Hosting for Let’s Encrypt Support: Shared, VPS, Cloud, and Managed Options, Let’s Encrypt for Apache: Complete Setup, VirtualHosts, and Renewal Checklist, and Let’s Encrypt for Nginx: Complete Setup, Redirects, and Renewal Checklist.

The main takeaway is simple: on Windows Server, the real job is not just getting a certificate once. It is building a repeatable IIS workflow that survives DNS changes, migrations, renewals, and routine maintenance. If you treat issuance, binding, redirect logic, and renewal verification as one checklist instead of four separate tasks, your HTTPS setup stays much easier to trust.