CERTIFICATE LIFECYCLE MANAGEMENT
ViperCLM issues, tracks and renews TLS certificates from public CAs and your internal Microsoft PKI — then pushes them onto the servers that actually serve them. It runs on your own infrastructure and never needs an inbound port open.
// CERTIFICATE COMMAND
THE PROBLEM
Certificate estates sprawl across public CAs, internal PKI, load balancers and Windows servers. The tracking lives in a spreadsheet, the renewal lives in somebody's head, and the install is a manual PFX import at 11pm.
Certs are issued by whoever needed one that day, from whichever CA had budget. There is no single list, so there is no single warning.
HTTP-01 wants port 80 reachable from the internet. Internal hosts and segmented networks simply can't play, so they get manual certs instead.
A renewed certificate sitting in a folder protects nothing. The last mile — onto the IIS binding, onto the NGINX vhost — is where renewals actually fail.
CAPABILITIES
Let's Encrypt, ZeroSSL, SSL.com and Google Trust Services over ACME — with External Account Binding handled where the CA requires it. Accounts are keyed per authority and environment, so staging and production never cross wires.
Hostnames match to the right DNS credential by longest zone suffix, so multiple zones across IONOS and ClouDNS work side by side. Nothing needs to resolve publicly, and nothing needs to be reachable.
Enrol against your own AD CS certificate authority for internal names that no public CA will ever sign — template selection included — and keep those certificates in the same inventory as everything else.
IIS over WinRM: imports the PFX and repoints the site's HTTPS binding. NGINX and Apache over SSH: writes the fullchain and key, then runs your reload command. Load balancers, firewalls and Java keystores are coming down the same path. The renewal isn't done until it's live.
Service accounts and SSH keys live once under Security and are referenced by devices. One credential serves many targets, and rotating it is one edit rather than a hunt.
Every request moves through pending → dns_challenge → issued in view, with deployment jobs tracked separately against each device. Overview charts break the estate down by authority and expiry window, so the next thirty days are never a surprise.
HOW IT WORKS
Add your IONOS or ClouDNS credential once per zone. It's encrypted before it touches the database and can be rotated from the UI without a restart.
Choose a public CA — with EAB credentials if it needs them — or point the request at your internal AD CS. Start on staging, flip to production when you're happy.
ViperCLM publishes the DNS-01 TXT record, waits for propagation, completes the challenge and stores the certificate with its key encrypted at rest.
Attach the certificate to an IIS site or a Linux vhost. From then on, renewal and redeployment happen on the same path — no 11pm PFX imports.
THE CONSOLE
Pick the authority, type the hostname. ViperCLM works out which DNS credential owns the zone, publishes the challenge and tracks it through to issued.
// ISSUANCE & INVENTORY
Public ACME CA — validated via DNS-01 using the DNS credential whose zone matches the hostname.
SUPPORTED
SECURITY POSTURE
ViperCLM was designed for segmented estates and internal PKI first. The threat model is written down, and the defaults follow it.
Ask us anythingDNS and CA secrets and every issued private key are AES-256-GCM encrypted with your master key before reaching Postgres, and decrypted in memory only at the moment of use.
The master key and the admin credential are deploy-time environment variables, never editable through the UI. Stolen Postgres data alone yields neither access nor a working decryption key.
Nothing needs to be reachable from the internet. The app needs egress to your CA and DNS APIs — put the admin UI behind your own VPN or reverse proxy as your boundary dictates.
WinRM sessions are Kerberos-sealed at the message layer, so certificate material crosses the wire encrypted without loosening a single setting on the target host.
SELF-HOST
One Go binary and a Postgres database, both in Docker Compose. No frontend build, no external services, no agent to install on the hosts you're issuing for.
# secrets it needs
$ openssl rand -base64 32
$ docker compose run --rm app hash-password
# bring it up
$ docker compose up -d
# verify what you were issued
$ openssl x509 -in cert.pem -noout -issuer
issuer=C=US, O=Let's Encrypt, CN=R11
GET IN TOUCH
Whether it's a handful of public certificates or a few hundred spread across internal PKI and Windows servers, we'll tell you straight whether ViperCLM fits — and what it would take to run it.
Prefer email? jamie.campbell@viper-clm.co.uk