Hosts: where certificates go
A host is one place a certificate is installed. Add it once and every renewal is installed there automatically.
Push or pull
- Push: NeverLapse connects to the server and installs the certificate (Windows over WMI, Veeam over WMI and PowerShell, OPNsense over its API). Needs the NeverLapse server to reach that server. Windows and Veeam push need NeverLapse on a Windows server; on Linux or Docker use the agent types.
- Pull: a small agent on the server checks in with NeverLapse over HTTPS (every minute by default; set Agent check-in on the host's page, 1 to 1440 minutes) and installs anything new. Nothing connects into that server, so it works behind NAT, in another domain, at a customer's site or in the cloud. The Hosts list's Agent column shows each agent's version, when it last checked in, and whether it needs anything (see which agent version is where).
Pick a type
| Type | Model | Use it for |
|---|---|---|
| Windows (domain-joined) | Push | Windows servers in the same domain as NeverLapse. Uses the NeverLapse service's own identity. Needs NeverLapse on Windows. More |
| Windows (workgroup) | Push | Windows servers outside the domain but reachable; uses a stored local admin login. Needs NeverLapse on Windows. More |
| Windows - IIS (agent, pull) | Pull | IIS servers NeverLapse can't reach directly. Imports and rebinds IIS sites. More |
| Windows - General (agent, pull) | Pull | Windows servers without IIS: writes PFX or PEM files to a folder, optionally runs your script. |
| Windows - Apache Tomcat (agent, pull) | Pull | The same for Tomcat on Windows (the Tomcat service). More |
| Linux - Apache | Pull | Apache: picks the sites, writes the files and HTTPS config, reloads Apache. More |
| Linux - nginx (agent, pull) | Pull | nginx: picks the server blocks, writes the files, points nginx at them, tests, reloads and checks; rolls back on failure. More |
| Linux - Apache Tomcat (agent, pull) | Pull | Apache Tomcat on Linux: writes a keystore, points server.xml's HTTPS connector at it, restarts Tomcat and checks; rolls back on failure. More |
| Linux - HAProxy | Pull | HAProxy: one certificate per frontend, or every certificate in an SNI folder. More |
| Linux - General | Pull | Anything else on Linux: PEM or PFX files in a folder, plus your script. |
| Veeam Cloud Connect | Push | A reachable Veeam Backup & Replication server: imports and assigns the Cloud Connect gateway certificate. Needs NeverLapse on Windows; otherwise use the agent type below. More |
| Veeam Cloud Connect (agent, pull) | Pull | The same, for a Veeam server behind NAT or in another domain. |
| Microsoft Exchange (agent, pull) | Pull | Exchange servers, one host per server: imports the certificate and enables it for IIS, SMTP, POP or IMAP with Exchange's own cmdlets. No script needed. More |
| Microsoft Remote Desktop Services (agent, pull) | Pull | Remote Desktop deployments, one host per deployment, agent on the RD Connection Broker: puts the certificate on RD Gateway, RD Web Access and the broker roles with Set-RDCertificate, checks it and rolls back. No script needed. More |
| OPNsense (HAProxy) | Push | OPNsense firewalls running the HAProxy plugin, through OPNsense's API. More |
| VMware Cloud Director cell (agent, pull) | Pull | One host per VMware Cloud Director cell: swaps the cell's certificate with VMware's cell-management-tool and restarts vmware-vcd. More |
Veeam Enterprise Manager and Veeam Service Provider Console are ordinary Windows hosts; Exchange has its own type. See Veeam, OPNsense and Exchange. FortiGate, Cisco ASA and Firepower firewalls aren't a host type yet: download the certificate and import it there, see Firewalls.
VMware Cloud Director cells
For VMware Cloud Director 10.4 and newer, where one certificate covers the portal, the API and the console proxy. Add one host per cell, with the type VMware Cloud Director cell (agent, pull), and install the native Linux agent on that cell (see Agents). When the cell gets a new certificate, the agent:
- backs up the cell's current
certificates.pemand key to/var/lib/neverlapse-pull/vcd-backup, - converts the new key to a password-protected PKCS#8 key (with a one-time password),
- imports it with VMware's
cell-management-tool certificates, - restarts
vmware-vcd: that cell's portal, API and consoles are down for a few minutes, - waits up to 15 minutes until the cell serves the new certificate on 443 and answers
/api/versions.
- If the swap fails, the agent puts the old files back, restarts the cell again, and waits 6 hours before trying that certificate again.
sudo neverlapse-agent run --forceretries straight away. - No restart when the cell already serves the certificate.
- The appliance management page on port 5480 isn't touched.
- Several cells: give each its own host, and let them take turns (one cell at a time), so the others keep serving while one restarts.
- Load balancer in front: with SSL passthrough, nothing is needed on the load balancer. If the load balancer ends TLS itself, it needs the certificate too; this host type doesn't do that, so add the load balancer as its own host.
- Things that trusted the old certificate, such as VMware Cloud Director Availability, may need to be told to trust the new one.
Add a host
- Hosts > Add.
- Enter a name, pick the Type and the Certificate it should get. The form shows only the fields that type needs.
- Save. For pull types, the host's page then shows the agent download and install command (see Pull agents).
- Click Deploy all now on the Dashboard, or wait: push hosts are done at the next renewal check, agents at their next check-in.
Settings several types share
- Certificate store (Windows types): where the certificate is imported, usually Personal (
My) of the local computer. - Keep PFX on host (Windows push types and Windows - IIS agent): also write the
.pfxfile to a path, for other software on that server that wants the file. - Target directory and format (General types): the folder, and either one PFX file or PEM files (
cert.pem,chain.pem,privkey.pem,fullchain.pem). - Custom post-deploy script: runs on the host after each install, for anything else (restart a service, tell another program). Paste it into Script content, or give the path of a script already on that server. On Windows hosts the script gets the new certificate's thumbprint as the first argument and the PFX password as the second; anything in Extra arguments follows. A script that exits with an error is reported as a failed deployment. Not available for OPNsense.
- Private key passphrase (Linux agent types): writes the private key encrypted. The web server then needs the passphrase at every start, which is why most people leave this off; HAProxy can't use an encrypted key at all.
Logins for push hosts
Windows (workgroup) and Veeam Cloud Connect (push) hosts (NeverLapse on Windows only), and OPNsense hosts, need a login. Pick a saved account or fill in Add new account; it's saved encrypted and can be reused for every host with the same login. Change it later under Credentials.
More than one certificate on a server
Apache, nginx, HAProxy and IIS agent hosts can carry several certificates, one per site, frontend or binding. General agent hosts (Windows, and Linux with the native agent; version 1.2.7 and later) can too: each extra certificate goes into its own sub-folder. Other types take one certificate per host entry; add a second host entry for the same push server if it needs two. See several certificates.