How to Manage Machine Credentials Across Mixed Servers
Certificates and SSH access usually fail for the same reason: they are treated as separate admin chores until something breaks.
The cert lives in one spreadsheet. The private key is on a host. SSH keys are on laptops. The bastion has its own rules. Then an auditor or an incident asks a simple question: who had access, what changed, and what was production serving?
In 2026, the useful model is not another standalone script. It is a trust workflow that covers inventory, ownership, scoped access, renewal, delivery, live checks, and evidence.
A workable certificate and SSH access loop
Where incidents usually come from
Nobody knows who owns the cert or server.
Keys outlive the job they were created for.
The cert renewed, but the endpoint kept serving the old chain.
Logs exist somewhere, but the timeline is painful to rebuild.
Start with the assets, not the tool
List the certificates, private keys, hosts, users, groups, ACME clients, bastions, Windows RDP paths, and automation jobs that can touch production. If this sounds messy, that is the point. Real infrastructure is messy.
CertLocker fits this by treating certificates, secrets, scoped tokens, SSH/RDP access, probes, and audit logs as one control plane rather than five disconnected admin areas.
Reduce standing access
Permanent PEM files and shared SSH keys are easy until someone leaves, a contractor finishes, or a laptop disappears. The safer pattern is short-lived access tied to a user, group, host, reason, and expiry.
For certificate automation, the equivalent is a scoped certificate token. HAProxy, Nginx, IIS, win-acme, or a deployment job should get the narrow certificate material it needs, not broad access to the whole vault.
Verify the live endpoint
A certificate in inventory is not proof that production is serving it. The reload might have failed. HAProxy might still hold the old bundle. IIS might have the binding wrong. A Java service might be reading a stale keystore.
Endpoint probes close that gap by checking what clients actually see and linking the result back to the certificate and workflow that changed it.
Minimum operating checklist
- ✓ Every certificate has an owner, group, expiry date, serving endpoint, and renewal path.
- ✓ Every SSH/RDP path is scoped, time-limited, and logged.
- ✓ Automation uses narrow tokens instead of shared admin credentials.
- ✓ Certificate renewal includes delivery, reload, endpoint verification, and audit evidence.
- ✓ Hosted evaluation covers the workflow; onsite evaluation proves it against your real estate.
Related reading and workflows
Certificate lifecycle management
Inventory, renewal, delivery, ownership, and audit for TLS certificates.
Certificate delivery tokens
Scoped certificate access for HAProxy, IIS, Nginx, scripts, and automation.
Endpoint probes
Check what production endpoints actually serve after renewal.
SSH access management
Short-lived SSH access, browser sessions, 2FA, groups, and audit.
Zero-trust SSH use case
A practical model for replacing long-lived PEM files.
Short-lived SSH access with 2FA
How CertLocker handles scoped server access and audit trails.
Help with onboarding
Bring your existing inventory to a hosted walkthrough with the CertLocker engineers.
CertLocker for DevOps teams
The broader trust-control workflow for platform and infrastructure teams.
Compare CertLocker with scripts
Where spreadsheets, cron jobs, and shared files stop being enough.
Try the workflow against real infrastructure
Use the hosted evaluation at trust.certlocker.io for a walkthrough, or run a one-month onsite evaluation against your own certificates, hosts, secrets, and access paths.