Let’s Encrypt on IIS: free SSL certificates that renew themselves

Published 24 October 2026 · EverTLS

IIS doesn’t make Let’s Encrypt easy: certificates live in the Windows certificate store and every HTTPS binding has to be switched on each renewal. Here’s how to automate the whole thing, from one server to a load-balanced pool.

Why IIS needs more than a certificate file

On Linux, a web server reads a certificate from two PEM files and you reload it. IIS works differently: the certificate and its private key have to be imported into the Windows certificate store (LocalMachine\My), and each HTTPS binding points at a certificate by its thumbprint. Every renewal therefore means importing the new certificate, switching each binding to the new thumbprint, and cleaning up the old one. Let’s Encrypt certificates last at most 90 days, so doing that by hand isn’t realistic.

Your options

• A client on each server, such as win-acme or Certify The Web, requests and installs certificates on that one machine. Good for a single server. See our comparison.
• A central service with agents, like EverTLS: one dashboard for every certificate, and a small agent on each server that installs renewals, checks the site and alerts you if anything fails. Better once you have several servers, a team, or Linux servers too.

Step by step with EverTLS

1. Create an account and install the agent

Sign up at app.evertls.com, then go to Agents → Add agent and copy the install command. Run it on the IIS server in PowerShell as Administrator:

[Net.ServicePointManager]::SecurityProtocol = 'Tls12'; & ([scriptblock]::Create((irm https://evertls.com/agent/install.ps1))) -Token evta_YOUR_ENROLLMENT_TOKEN

The agent runs as a Windows service, only makes outbound HTTPS connections, and finds your IIS sites and their bindings by itself. Within a minute they appear on the agent’s page.

2. Prove you control the domain

Let’s Encrypt checks that you control each domain before issuing. The simplest way on IIS is a redirect, using the free URL Rewrite module. Add this rule to the site’s web.config:

<rule name="EverTLS ACME" stopProcessing="true">
  <match url="^\.well-known/acme-challenge/(.*)$" />
  <action type="Redirect" url="http://validate.evertls.net/.well-known/acme-challenge/{R:1}" redirectType="Permanent" />
</rule>

For wildcard certificates (*.example.com), use one of the DNS methods instead: a one-time CNAME record, your DNS provider’s API (Cloudflare, Route 53, Azure DNS and 190+ more), or a DNS key kept on the agent so it never leaves your server.

3. Request the certificate and choose the IIS site

Under Certificates → New certificate, enter your domain names. Choose An agent generates it on my server, so the private key is created on the IIS server and never leaves it, and under Install automatically pick the IIS site. EverTLS orders the certificate and the agent:

1. imports it into LocalMachine\My with a friendly name starting with “EverTLS”;
2. switches the site’s HTTPS binding to it;
3. checks the site actually serves the new certificate;
4. keeps the previous certificate, so it can roll back if the check fails.

4. Renewals

Nothing else to do. EverTLS renews when the certificate authority recommends (around two thirds into the certificate’s life), the agent installs and verifies, and you get an email, Slack or Teams alert only if something needs you.

Several IIS servers behind a load balancer

Put the agent on each server, add them to an agent group, and deploy the certificate to the group by IIS site name: every member installs it, and servers added later get it too. Or, if your IIS servers use the Centralized Certificate Store, one agent writes the PFX files to the shared folder (named the way IIS expects, like www.example.com.pfx) and every server picks them up.

Common problems

• The redirect isn’t followed: the URL Rewrite module isn’t installed, or port 80 is blocked by the firewall. HTTP validation always starts on port 80.
• Several sites on one IP address: use bindings with Require Server Name Indication, so each site can have its own certificate.
• Windows Server 2016 or older can’t open a PFX: older Windows only understands 3DES-encrypted PFX files. Tick Legacy encryption (3DES) when exporting.