MSP certificate management without the renewal ticket queue

MSP certificate management means keeping each client's TLS certificates discoverable, owned, renewable, and correctly installed. The certificate authority is one part of that process. The harder part is coordinating DNS access, device access, change windows, and technicians across a fleet of unrelated customer networks.

The useful outcome is simple: the next certificate reaches the right service before the old one expires, and your team can prove it. This playbook is an operating model for that outcome, whether you use individual ACME clients, a lifecycle platform, or a combination.

Start with the service, then find the certificate

A customer does not report that a serial number expired. They report that remote access stopped working. Organize the inventory around services: the VPN hostname, the remote desktop gateway, the public application, and the administrative interface.

For each service, record the customer, hostname and port, certificate issuer, expiry, deployment target, technical owner, and escalation contact. Also record who controls DNS. If that access belongs to a former web agency, discovering it during an outage makes a certificate problem much harder.

One certificate can serve several endpoints, and one hostname can resolve to several TLS terminators. Keep both relationships. A row called “wildcard certificate” does not explain which of twelve appliances still needs an update. Use the certificate inventory checklist to build a starting record.

Separate client boundaries from technician convenience

A shared view helps technicians find work. Shared credentials across customers create a different problem. Keep customer-specific access scoped to the customer, and document which automation identity changes each device.

For every connector, ask three practical questions:

• Can the identity access only the intended customer environment?
• Can another technician understand what the last renewal changed?
• Can you revoke access when a client leaves without interrupting other clients?

Record where private keys are generated and stored. Do not treat a certificate file and its private key as interchangeable attachments. The certificate is public; the key requires controlled access. A renewal runbook should identify key custody without copying the key into the ticket.

Choose an automation path per deployment target

Do not require every service to use the same installer. A web server with a working ACME client may need better monitoring, while a firewall still needs a deployment connector. Start by documenting the path already in place.

Classify each service as:

1. Automated and verified. Renewal, installation, and a live check are working.
2. Renewed but manually installed. A new certificate exists, but a technician performs the binding or upload.
3. Manually renewed. A person handles both the CA order and deployment.
4. Unowned or unknown. Nobody can describe the renewal path confidently.

The fourth group deserves investigation first. Within the second and third groups, prioritize business impact and the effort to recover, rather than certificate count alone. A single remote access gateway can matter more than dozens of low-impact sites.

Define completion before automating it

A successful CA order is an intermediate event. Your completion rule should include the live hostname, expected certificate fingerprint or serial number, hostname coverage, valid chain, and an application check.

Test from the path users take. A check inside the customer network can miss a public proxy that still serves an older certificate. If there are multiple nodes, verify each one. The deployment guide explains why this step needs its own success criteria.

Agree on recovery before the first unattended change. Retain the previous configuration and a still-valid certificate during the transition. If a check fails, stop the rollout and restore the known working configuration when that is safe. Restoring an already expired certificate is not a successful recovery.

Put failures into an owned workflow

Create an alert when renewal or installation fails, while there is still time to repair it. Expiry thresholds are a second line of defense. An alert should name the client, service, stage, last error, remaining validity, and responsible team.

Agree who watches the queue outside business hours. Suppress duplicate notifications for the same failure while preserving escalation when the deadline gets closer. For successful routine renewals, a recorded result is usually more useful than another ticket someone must close.

Review these measures during service operations:

• Services with no known owner or renewal method.
• Failed attempts that have not been acknowledged.
• Renewals completed with a verified deployment.
• Manual touches required per renewal.
• Time between the first failure and recovery.

These show whether the process is becoming reliable. A large number of issued certificates alone does not.

Prepare the service model for shorter lifetimes

The CA/Browser Forum's public TLS validity schedule reduces the maximum to 100 days from March 15, 2027, and 47 days from March 15, 2029. The maximum for certificates issued from March 15, 2026 is 200 days; individual CAs can issue shorter certificates.

Treat those dates as a reason to remove manual dependencies, not as a reason to schedule larger batches of manual uploads. Run a small pilot, observe an actual renewal, then expand by platform. Include customer offboarding and access revocation in that pilot.

Where Certonomy fits

Certonomy is preparing founding access for MSPs and IT teams that manage certificates across firewalls, Windows hosts, and web servers. Its published workflow uses CNAME validation and an on-site agent, with private keys kept on the customer site, followed by deployment, verification, and rollback.

Check the launch platform list against your fleet before choosing a pilot. You can review the founding pricing and join the waitlist with the platforms that still create renewal tickets for your team.