Automated SSL certificate renewal for Total Uptime

Total Uptime won't renew the certificates on your Packs. CertKit will.

Total Uptime Cloud Load Balancing terminates TLS in its own regions, using key and certificate pairs you upload and attach to each Pack. It doesn't issue certificates for you. A renewed certificate does nothing until someone uploads the key and certificate, pairs them, links the intermediate, and swaps the pair on every Pack. Every 47 days.

CertKit issues and renews the certificate centrally, then the CertKit Agent uploads it through the Total Uptime API and moves your Packs to it once every region has it installed.

Start free trial Watch demo

Built for Total Uptime

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

On every renewal, the agent uploads the key and certificate as a new pair, links Total Uptime's copy of the issuing intermediate, and waits until every region has installed it. Then it attaches the pair to each Pack you listed, as the default certificate or as an SNI certificate, and deletes the earlier CertKit uploads that no Pack uses. RSA and ECDSA certificates both work, and a deployment usually takes 2 to 10 minutes.

Total Uptime can't hold the old and new certificate side by side, so each region serves no certificate for those hostnames for about a minute while it switches, and some connections fail. Set a deploy window so renewals land at 2am Sunday, not during your busiest hour.

How to install an SSL certificate on Total Uptime

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

Upload the private key. In the Total Uptime portal, open Networking → TLS/SSL and upload the key under SSL Keys as its own PEM file. Total Uptime doesn't accept a PFX, so split it first. A PKCS#8 key can fail later with "Could not create certificate-key pair".
Upload the certificate. Under SSL Certs, upload the renewed certificate on its own, without the chain.
Pair them. Under SSL Key/Cert Pairs, add a pair from the key and the certificate you just uploaded.
Link the intermediate. Select the pair, choose Link, and pick the issuing intermediate from Total Uptime's shared store. You can't upload your own intermediate, so a missing one means a support ticket.
Swap it on every Pack. In the Configuration Builder, open each Pack, detach the old pair, and attach the new one. Check SNI if the Pack serves a certificate per hostname. Then delete the old pair, key, and certificate.

Every one of these steps is manual, and Total Uptime won't repeat any of them when the certificate renews. With lifetimes shrinking to 47 days, that's twelve times a year, on every Pack. Miss one and every visitor to the sites behind that Pack gets a certificate error.

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

The whole process was extremely easy, it's a great product.

Adam Carson, Senior Manager, Drug ARM

How it works

 Your network            CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│  ┌─────────────┐  │     │                  │    │             │
│  │CertKit Agent├──┼────►│  Issue & Renew   │◄──►│             │
│  └──────┬──────┘  │     │   Certificates   │    │             │
│         │         │     │                ┌───┐  └─────────────┘
└─────────┼─────────┘     └────────────────│DNS│
          │ HTTPS API                      └───┘
          ▼
┌───────────────────┐
│  Total Uptime     │
│  [x] Pair loaded  │
│  [x] All regions  │
│  [x] Packs moved  │
└───────────────────┘

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

The CertKit Agent runs on a Windows server. It pulls each renewal from CertKit over outbound HTTPS, then calls the Total Uptime API as a Total Uptime API user. The API password is stored encrypted in CertKit and handed to the agent only when a deployment runs. CertKit never connects into your network.

Default or SNI on every Pack

A Pack serves either one default certificate or a set of SNI certificates, one per hostname. Pick the placement that matches the Pack, and CertKit checks it before changing anything. An SNI certificate on a Pack that doesn't use SNI would switch the Pack to SNI, and Total Uptime would then reset every visitor whose hostname has no SNI certificate of its own. When the placement doesn't match, the deployment stops and the Pack stays as it was.

Default Replaces the Pack's one certificate SNI Replaces the SNI certificate for the same hostnames and leaves the others alone

What CertKit handles

Issue and renew centrally. The one-time CNAME covers every renewal challenge. There's no ACME client to run and no DNS credentials to store.
Upload and pair. The key and certificate go up as a new pair with a certkit- name. If the identical certificate is already in a pair, that pair is reused.
Link the right intermediate. The pair is linked to Total Uptime's copy of the issuing intermediate. When the store doesn't have it, the deployment stops before changing anything and names the certificate to ask Total Uptime support to add.
Wait for every region. Packs move only after every region has installed the new pair. If that takes more than 15 minutes, the deployment stops without touching the Packs, and the next one finishes the switch.
Attach to every Pack you list. One deployment can cover several Packs. Deployments on the same Total Uptime account wait for each other, because Total Uptime applies an account's changes one at a time.
Clean up only its own uploads. Earlier CertKit pairs are deleted once no Pack uses them. Anything without the certkit- prefix is never deleted.
Alert on failure. A failed deployment emails the agent's alert list with the API error, so you know which Pack or region stopped it.
Audit every change. Every issuance, renewal, and deployment is logged. 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.
Create a Total Uptime API user. Add a separate user in Total Uptime for CertKit and set it up as an API account.
Install the CertKit Agent. One command on a Windows host with outbound HTTPS.
Add the Total Uptime deployment script. Choose the Total Uptime template, then enter the API user, the Pack names, and default or SNI.

See the full architecture →

Why not follow Total Uptime's Let's Encrypt guide?

Total Uptime's own Let's Encrypt article has you run an ACME client yourself and push each certificate through the API every 90 days: add the key and certificate, pair them, link the intermediate, detach the old pair, attach the new one, unlink, and delete. Its sample hard-codes the ID of one Let's Encrypt intermediate.

That's a renewal script you write, schedule, and fix when it breaks, on a server that holds your DNS or web credentials for ACME. CertKit runs the same sequence from a template, finds the intermediate for each certificate, and validates through a single CNAME.

Total Uptime is just one part of your application delivery stack

Most networks have more than one place where TLS certificates live: load balancers in your own data center like F5 BIG-IP, Citrix NetScaler, Kemp LoadMaster, and A10 Thunder, and the web servers behind your Packs, like IIS and nginx. CertKit automates all of it from one account.

See all integrations

Start automating Total Uptime 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