IIS Centralized Certificate Store with Let’s Encrypt

Published 24 October 2026 · EverTLS

The Centralized Certificate Store lets every server in an IIS farm read its certificates from one shared folder. Here’s how it works, how to set it up, and how to keep the PFX files in it renewed automatically.

What the Centralized Certificate Store is

Normally each IIS server keeps its certificates in its own Windows certificate store, and each HTTPS binding points at one of them. With several servers behind a load balancer, every renewal has to be imported and bound on every server.

The Centralized Certificate Store (CCS), built into IIS 8 and later, changes that: all servers read their certificates as PFX files from one shared folder. When a request arrives for www.example.com, IIS looks for www.example.com.pfx in that folder. Replace the file and every server serves the new certificate, without touching a binding.

How IIS finds the right file

• Each host name has its own file, named after it: www.example.com.pfx, shop.example.com.pfx.
• A wildcard certificate uses an underscore for the star: _.example.com.pfx serves *.example.com.
• All files in the store share one PFX password, which you enter once in IIS.
• Sites are bound on HTTPS with Require Server Name Indication and Use Centralized Certificate Store, so the binding has no certificate of its own.

So a certificate covering example.com and www.example.com needs two files with the same content, one per name.

Setting up the store

1. Share a folder on a file server, for example \\fileserver\iis-certs. The IIS servers need read access to it.
2. On every IIS server, add the role feature Centralized Certificate Support (under Web Server → Security).
3. In IIS Manager, select the server, open Centralized Certificates, choose Edit Feature Settings, enable it, enter the share and an account that can read it, and enter the PFX password.
4. Bind each site on HTTPS with Require Server Name Indication and Use Centralized Certificate Store.

Automating renewals with EverTLS

The missing piece is something that writes renewed PFX files into the share, named the way IIS expects. An EverTLS agent does exactly that, on one machine only:

1. Install the agent on one server that can write to the share. It can be one of the IIS servers or the file server.
2. Give that computer write access: on the share, give the agent server’s computer account (SERVER$) Modify. The agent runs as SYSTEM, so on the network it uses that account.
3. Allow the folder on the agent (agents only write where you allow), in PowerShell as Administrator:

   & "C:\Program Files\EverTLS\evertls-agent.exe" folders allow "\\fileserver\iis-certs"

4. Choose the store as the target. On the certificate, under Install automatically, choose Files or PFX, then For IIS Centralized Certificate Store, and enter the share. The dashboard shows the exact file names it will write.
5. Pick the PFX password: either stored only on the agent’s server (evertls-agent pfx-password set ccs, so EverTLS never sees it), or typed in the dashboard and stored encrypted. Use the same password you entered in IIS.

From then on, every renewal replaces the files in the share and every IIS server picks them up. If any server runs Windows Server 2016 or older, tick Legacy encryption (3DES), since those versions can’t open modern AES-encrypted PFX files.

CCS or agents on every server?

EverTLS supports both. Use CCS when your servers already share storage and you want one agent and no per-server bindings. Use agent groups when you’d rather keep certificates in each server’s own store: install an agent on each server, add them to a group, and deploy to the group by IIS site name. Every member imports the certificate and switches its binding, and servers added to the group later get it too.

Troubleshooting

• A site serves the old or a default certificate: check the binding uses both SNI and the Centralized Certificate Store, and that the file name matches the host name exactly.
• “Access denied” from the agent: the agent server’s computer account needs Modify on the share and its folder, not just on one of them.
• IIS can’t read a file: the password in IIS’s Centralized Certificates settings must match the one the agent uses, for every file.