Automated SSL certificate renewal for Kemp LoadMaster

A Kemp LoadMaster won't update a renewed certificate on its own. CertKit will.

A LoadMaster serves TLS from named certificates in its SSL Certificates store, and each Virtual Service is assigned a certificate by name. When a certificate renews, nothing changes on the load balancer until someone imports the new certificate, updates the Intermediate Certs store, and confirms every Virtual Service serves the new chain. Every 47 days. On every LoadMaster you manage.

CertKit centralizes certificate issuance and renewal, then pushes the renewed certificate to your LoadMasters automatically via the CertKit Agent and the LoadMaster REST API. The certificate is replaced in place under its existing name, so Virtual Service assignments keep working without rebinding.

Start free trial Watch demo

Built for Kemp LoadMaster

A pre-built LoadMaster template ships in your CertKit account. No scripting required.

CertKit renews your LoadMaster certificate for you. On every renewal it uploads any intermediate certificates the device doesn't already hold, then replaces the named SSL certificate through the API. Virtual Services assigned to that name serve the new certificate immediately. No WUI clicks, no manual import, no rebinding, no restart.

A pre-built LoadMaster template ships with your CertKit account. Point CertKit at your LoadMaster once and it handles every renewal after that. If you want to see or adjust exactly what runs, the full deployment script is right there in your account.

How to install an SSL certificate on Kemp LoadMaster

The manual process, if you want to do it yourself:

Get the renewed certificate. Generate a CSR on the LoadMaster under Certificates & Security → Generate CSR, or create the CSR and key externally, then submit it to a certificate authority. The same flow covers a wildcard certificate.
Add the intermediate certificates. Under Certificates & Security → Intermediate Certs, choose Add New and upload each intermediate in the chain. Skip this and strict clients fail the TLS handshake with "sslv3 alert certificate unknown".
Import the certificate. Under Certificates & Security → SSL Certificates, choose Import Certificate and upload the certificate and key as a PEM file, or a .pfx file with its passphrase, under a certificate identifier name.
Assign it to Virtual Services. If you imported under a new name, open each Virtual Service's SSL Properties and move the new certificate into the assigned list. If you replaced the existing identifier, the assignments hold.
Verify and clean up. Test the chain with a strict client, not just a browser that has the intermediate cached. Delete the old certificate once nothing is assigned to it, and repeat on every LoadMaster that serves the domain.

Every one of these steps is manual, and the LoadMaster 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 LoadMaster you manage. Miss one and every application behind that Virtual Service throws certificate warnings at once.

At 47 days, automation is the only sustainable way to run LoadMaster certificates. Here's how CertKit does it.

How it works

 Your network            CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│  ┌─────────────┐  │     │                  │    │             │
│  │Deploy Agent │◄─┼─────┤  Issue & Renew   │◄──►│             │
│  └──┬────┬─────┘  │     │   Certificates   │    │             │
│     │    │REST    │     │                ┌───┐  └─────────────┘
│     │    │ API    │     └───────────┬────│DNS│
│     ▼    ▼        │                 │    └───┘
│ ┌──────────────┐  │                 │
│ │ LoadMaster   │  │                 │
│ │ [x] Chain    │  │ ◄───────────────┘
│ │ [x] Replaced │  │       Verify
│ └──────────────┘  │
└───────────────────┘

CertKit issues and renews certificates centrally in the cloud using delegated DNS validation. You create a one-time CNAME record; CertKit handles every ACME challenge after that.

The deploy agent is a small service you run on a server inside your network. It makes an outbound HTTPS connection to CertKit to pull each renewed certificate, then connects to the LoadMaster over its REST API on your management network to upload the intermediates and replace the SSL certificate. The LoadMaster never talks to CertKit or the public internet directly, never runs ACME, needs no port 80 open, and never stores DNS credentials. One deploy agent can reach every LoadMaster and other appliance on that network, so there's nothing to install on the load balancers themselves.

CertKit makes what many companies struggle with much easier to manage while at the same time providing great value compared to the traditional vendors in the space.

Ben Story, Managed Services Director, RedEye Network Solutions

Two certificate stores, one working chain

A LoadMaster keeps certificates in two separate stores, and both have to be right for clients to trust the connection. CertKit ships a pre-built template that keeps both current.

SSL Certificates Leaf certificate and key, assigned to Virtual Services by name Intermediate Certs CA chain, auto-associated at serve time, no VS binding

The catch: intermediates embedded in the PEM you import as the SSL certificate are not served. The LoadMaster builds the TLS chain only from the Intermediate Certs store. A renewal that skips that store looks fine in a browser that has the intermediate cached, then fails for curl, Java clients, and mobile apps that don't. If your CA has rotated its chain since the last import, the certificate you just installed serves incomplete.

What CertKit handles

Issue certificates via ACME, centrally. Your LoadMasters have no ACME configuration, no open ports, no public DNS credentials. One CNAME record is all your domain contributes.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on any device.
Replace the certificate over the LoadMaster REST API. The CertKit Agent authenticates with your API user, checks whether the certificate identifier already exists, and creates or replaces it in one call. Virtual Services assigned to that name serve the renewed certificate immediately, with no rebinding.
Keep the Intermediate Certs store complete. The agent splits the CA chain into individual certificates and uploads each one the LoadMaster doesn't already hold. Each intermediate is named by a hash of its content, so a CA shared across certificates is stored once and never duplicated on renewal.
Work with self-signed management certificates. The agent reaches the LoadMaster API over HTTPS and tolerates the default self-signed management certificate that most LoadMasters ship with.
Verify the deployment, not just the script. After each renewal, CertKit connects to your Virtual Service's published address and confirms the new certificate is actually being served. It checks the serial number, SANs, and expiry. If something is wrong, you find out before your users do.
Alert on failure. Deployment failures, API errors, verification mismatches, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and device. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit. Every renewal challenge after that is automatic.
Enable the API and create a user. Under Certificates & Security → Remote Access, enable the API interface. Create a user with the Certificate Creation and Intermediate Certificates permissions. That's all the access the deployment needs.
Install the CertKit Agent. One command on any Windows host with HTTPS reachability to the LoadMaster management interface. The agent runs as a background service and needs no inbound firewall rules.
Add the LoadMaster deployment script. The pre-built Kemp LoadMaster template is in your account. Set your management address, credentials, and certificate identifier. CertKit runs it on every renewal.

See the full architecture →

Why not use the LoadMaster's built-in Let's Encrypt client?

Recent LoadMaster firmware ships an ACME client that can fetch Let's Encrypt certificates directly. It validates with HTTP-01 only, and that's the limitation: the domain has to resolve to a Virtual Service the public internet can reach on port 80. Internal VIPs can't validate at all, and wildcard certificates are off the table because they require DNS validation. Each LoadMaster also manages its own account and renewals, so a fleet of them means a fleet of separate ACME configurations with no shared inventory and no verification that the renewal actually took.

CertKit issues the certificate via delegated DNS validation, which covers internal VIPs and wildcards, then the agent handles the intermediate upload and the in-place replace as one verified step, with no ACME client on the load balancer.

Kemp LoadMaster is just one part of your network edge

Most networks have more than one place where TLS certificates live: other load balancers like F5 BIG-IP and Citrix NetScaler, the web servers behind the Virtual Services, and firewall vendors like Fortinet, Palo Alto, SonicWall, and Cisco Firepower. CertKit automates all of it from one account.

See all integrations

Start automating Kemp LoadMaster certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing