IIS binds to a specific certificate thumbprint in the Windows Certificate Store. When a certificate renews, the thumbprint changes, but IIS keeps serving the old one until someone manually imports the new PFX and updates every affected binding. Every 47 days. On every server in your fleet.
CertKit centralizes certificate issuance and renewal, then pushes updated certificates to your IIS servers automatically via the CertKit Agent.
The pre-built IIS deployment template ships in your CertKit account. No scripting required.
The CertKit Agent writes the PFX to disk and runs the deployment script automatically. It imports the certificate into the Windows Certificate Store, updates the IIS site binding to the new thumbprint, and removes the old certificate.
The pre-built IIS template ships with your CertKit account. Configure the site name once. CertKit handles every renewal after that.
The manual process, if you want to do it yourself:
*.yourdomain.com to
install a wildcard certificate, and use a 2048-bit key or larger.
Every one of these steps is manual, and IIS won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, installation stops being an annual chore and becomes a recurring task: eight times a year, on every binding, on every server in the fleet. Miss one and it's an outage.
At 47 days, automation is the only sustainable way to run IIS certificates. Here's how CertKit does it.
Your IIS server CertKit ACME CA ┌───────────────────┐ ┌──────────────────┐ ┌─────────────┐ │ │ │ │ │ │ │ ┌───────────────┐ │ Issue & Renew │◄──►│ │ │ │ CertKit Agent │◄──┤ Certificates │ │ │ │ └─────────┬─┬───┘ │ ┌───┐ └─────────────┘ │ │ │ │ └───────────┬────│DNS│ │ Cert store ◄─┘ │ │ │ └───┘ │ [x] Updated │ │ │ │ │ │ │ │ IIS binding ◄───┘ │ ◄───────────────┘ │ [x] Updated │ Verify └───────────────────┘
CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record and CertKit handles every ACME challenge after that. Your IIS servers do not run ACME, no open ports, no DNS credentials. They just run the agent.
CertKit is an invaluable tool for administrators managing public TLS certificates in Microsoft environments like Always On VPN (SSTP) and DirectAccess (IP-HTTPS), as it simplifies and fully automates Let's Encrypt certificate issuance and renewal. CertKit eliminates the security risks and complexities of manual DNS challenges or API key exposure.
Richard Hicks, Consultant and Microsoft MVP
certreq and Windows ACME Simple (WACS) both run per-server, which means ACME credentials or HTTP-01 validation on every machine. In private networks and hardened environments that isn't an option. When multiple IIS instances share a certificate, there is no standard distribution mechanism. The common answer is a shared folder, which is a dependency that fails silently.
CertKit uses delegated DNS validation handled centrally, so no server needs port 80 open or ACME credentials on disk. It issues once and the agent handles distribution. There is no per-server ACME configuration to manage and no shared folder to maintain.
Most Windows environments have more than one place where certificates live: Exchange, SQL Server, Reporting Services, Remote Desktop, AD FS, and Palo Alto appliances. CertKit automates all of it from one account, and where the certificates come from an internal root, it chains to your Active Directory Certificate Services CA instead of a public one.
Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.