Certificate Lifecycle · For Real Fleets

Certificates That Renew
Themselves.

Centralized inventory, automated issuance and renewal, and zero-touch deployment to F5, NGINX, IIS, and Kubernetes. Every cert in one place, every expiry handled before someone gets paged.

ACME + Internal CA Vault Native F5 / NGINX / K8s Expiry Alerting
// Book a Discovery Call

30 minutes. Let's talk certs.

Pick a free slot — we'll learn your cert sprawl, current renewal pain, and where automation could prevent the next expiry outage.

Loading available times…
We'll only use your email to schedule the call.
0
Manual renewals
1
Inventory of record
30d+
Pre-expiry alerting
0
Cert-driven outages
Why Certs Still Break Things

Spreadsheets Don't Scale.

  • ✗ Cert inventory lives in three different spreadsheets and one engineer's head
  • ✗ Renewal is a manual ticket dance — CSR, approval, download, deploy, reload
  • ✗ Each platform — F5, NGINX, IIS, K8s — has its own bespoke deploy step
  • ✗ Expiry alerts are email-based. Until they hit a busy inbox and get missed
What MutexOps Does

One Inventory. Every Endpoint.

A Python control plane that owns your certificate lifecycle end-to-end — from discovery and inventory to renewal, deployment, and rotation across every platform that serves TLS.

// 01 — DISCOVERY & INVENTORY

Find Every Cert. Know Every Expiry.

Active scanning, agent-based collection, and pull from each issuer. One inventory, source of truth, queryable.

  • Scan endpoints on standard and custom ports
  • Pull from F5, NGINX, IIS, Kubernetes Secrets, Vault PKI
  • Reconcile against ACME and internal CA issuance logs
  • Tag by owner, environment, criticality from CMDB
  • Tiered expiry alerts to Slack, ServiceNow, PagerDuty
  • Drift detection between deployed cert and CA record
// 02 — RENEW & DEPLOY

Issue, Renew, Rotate — Hands-Free.

ACME for public, your internal CA for private. Same workflow. Deploys to whichever platform actually serves the cert.

  • ACME (Let's Encrypt, ZeroSSL, internal) + Microsoft AD CS
  • Private key generated in-platform — never leaves Vault
  • Idempotent deploy to F5, NGINX, IIS, K8s Secrets
  • Graceful reload — no service interruption
  • Health check after deploy, rollback on failure
  • Every issuance logged with full chain of custody
How It Works

From Discovery to Auto-Renewed — In One Pipeline.

Once a cert is under management, every subsequent renewal happens without human intervention.

01
Discover
Scan + agent + CA reconciliation
02
Inventory
Tag, classify, assign owner from CMDB
03
Renew
ACME or internal CA — key in Vault
04
Deploy
F5 / NGINX / IIS / K8s — idempotent
05
Verify
TLS handshake check + Git audit log
Stop Expiry Outages

How many certs do you actually know about?

30-minute discovery call. We'll talk through your cert estate — public vs private, issuer mix, deploy targets — and where automation could prevent the next expiry incident.

// Book Your Discovery Call

Pick a time below.

One click. We'll follow up with a Teams invite.

Loading available times…
No SDR sequence. One email, one calendar invite.
FAQ

Common Questions.

Any RFC 8555 (ACME) provider — Let's Encrypt, ZeroSSL, Google Trust Services, plus internal ACME-compatible CAs. For non-ACME issuers we support Microsoft AD CS via DCOM/REST, DigiCert/Sectigo/Entrust via their REST APIs, and HashiCorp Vault PKI as both an issuer and a key store.

In your HashiCorp Vault (or supported alternative). Keys are generated inside Vault, never written to disk on the MutexOps controller. Deploy steps fetch keys via short-lived tokens, push to the target platform's native key store (F5 sys file ssl-key, K8s Secret, Windows cert store), then forget them.

Discovery picks them up via scanning and platform pulls. You can either bring them under automated renewal (after re-issuing with a known key), or just track them in inventory for expiry alerting. The system never silently rotates a cert it doesn't have the key for.

iControl REST upload of the new cert and key, create-if-missing the SSL profile reference, swap the client-ssl profile on the relevant virtual servers, then verify the TLS handshake from outside. Rollback restores the prior profile binding if the post-deploy handshake fails.

Yes — MutexOps is a consumer of your PKI, not a replacement. Issuance still goes through your CA. The PKI team keeps policy control; MutexOps handles the request, retrieval, deployment, and renewal mechanics for the platforms that consume the certs.