Windows servers and IIS

Imports the certificate into the Windows certificate store and, for IIS, points the site's HTTPS binding at it after every renewal.

Push or agent?

The two push types need NeverLapse running on a Windows server. With NeverLapse on Linux or Docker, use the agent types.
  • Windows (domain-joined): the NeverLapse server can reach it over the network (TCP 135, 445 and dynamic RPC) and is in the same domain. NeverLapse connects as its own service account, so that account needs to be an administrator on the target (pick a domain account in the installer, or use a workgroup-style stored login instead).
  • Windows (workgroup): reachable, but not in the domain. Needs a stored local administrator login.
  • Windows - IIS (agent, pull) or Windows - General (agent, pull): anything NeverLapse can't reach: behind NAT, firewalled, another domain, a customer's site. No stored passwords, no inbound ports. See the Windows agent. To remove it, use Settings > Apps (NeverLapse Cert Agent) or NeverLapseAgent.exe /UNINSTALL from an elevated prompt; certificates it placed stay (details).

Set up a push host

  1. Hosts > Add, type Windows (domain-joined) or Windows (workgroup).
  2. Enter the server's name or IP, pick the certificate, and the certificate store (usually Personal).
  3. Workgroup only: pick a saved Windows account or add one (a local administrator on that server).
  4. If the server runs IIS, tick This host runs IIS and choose bindings (below).
  5. Save, then Deploy all now on the Dashboard to install it right away.

IIS bindings

New to this? Follow the step-by-step walkthrough with screenshots: from an issued certificate to a working HTTPS site with the IIS agent.

Importing a certificate doesn't make IIS use it. NeverLapse also binds it to the sites you pick: it creates the HTTPS binding if there isn't one, attaches the certificate to it, and moves it to the new certificate on every renewal. This works the same for push hosts and the IIS agent.

  • For push hosts NeverLapse reads the server's IIS sites live when you tick This host runs IIS. For Windows - IIS (agent, pull) hosts that box isn't shown: the list of sites comes from what the agent found on its last check-in.
  • Existing HTTPS bindings are listed ready to rebind. Sites with only HTTP can get a new HTTPS binding: set the IP address and, for several HTTPS sites on one IP and port, the host name (SNI).
  • After every renewal the picked bindings are moved to the new certificate.
  • Changing which bindings are picked (or Keep PFX on host) is installed at the next check-in or deployment, even though the certificate itself didn't change.
  • If binding fails, the IIS agent shows the reason as Last error on the host's page and tries again on every check-in.
Before version 1.3.5, IIS binding didn't work, for push hosts or the IIS agent: sites got an HTTPS binding with no certificate attached, and browsers showed a TLS or handshake error. Upgrade NeverLapse Cert to 1.3.5 or later. Then update the IIS agents from the Hosts page (or turn on automatic agent updates); they bind correctly on their next check-in; for push hosts, click Deploy on the Hosts page. From 1.3.6, an HTTPS binding NeverLapse created stays ticked on the host's page; on older versions, saving the host again dropped it, and the next renewal didn't rebind IIS.

On an IIS agent host each binding can use a different certificate; see several certificates on IIS. A Windows General agent host can also take several certificates, each in its own sub-folder; see General hosts.

Veeam Enterprise Manager and VSPC

Both are IIS sites. Add the server as a Windows host (with NeverLapse on Linux or Docker: a Windows - IIS (agent, pull) host), tick This host runs IIS and pick the Veeam site's binding. Every renewal is imported and bound without touching IIS Manager.

If a push fails

  • Access denied: the account isn't an administrator on the target, or (workgroup) the stored password changed.
  • RPC server unavailable: a firewall blocks TCP 135, 445 or the dynamic RPC ports from the NeverLapse server. Open them, or switch the host to the agent type.
  • The reason for each failed host is on the Certificates page and in the alert email.
Previous Hosts: where certificates go NextWalkthrough: IIS with the agent