By Yair Knijn · January 22, 2026
You acquired a company and inherited its certificates. Nobody knows where they all are.
The integration lead gets a mandate that reads like a network diagram: merge the directories, route the traffic, fold the apps under one domain, kill the duplicate VPN. The trap is the word "merge." You can merge a network in a quarter. You cannot merge a certificate estate you have never seen, and the acquired company shipped its entire PKI to you the day the deal closed: every internal CA, every wildcard, every self-signed cert on a host older than anyone still on payroll.
Nobody handed you that inventory because the acquired company never built one. Now the parent owns expiry risk, issuance pipelines, and trust roots it can neither see nor control. The first sign is usually an outage on a service nobody knew was load-bearing.
What you actually inherit: certs, CAs, and forgotten hosts
You inherit three distinct problems that get treated as one. Leaf certificates with expiry dates already counting down, some public, many on internal services with no monitoring attached. Certificate authorities, often a homegrown openssl CA or an old Active Directory Certificate Services root, whose private key sits on a box in a closet and whose root is trusted by every domain-joined machine you absorbed. And the hosts themselves: appliances, build agents, a forgotten staging cluster, each terminating TLS with a cert nobody tracks.
Two PKIs often cannot be unified at all, because their policies and assurance levels were never written to be compatible. Don't assume the acquired CA issued under rules you would accept. Read its policy, or find out there isn't one.
Discovery first: CT logs, network scans, and vault audits
Discovery is three parallel methods, each catching what the others miss. Run all three against the inherited estate.
- CT logs are the cheapest and most honest source: every publicly trusted cert for their domains is logged. Query by registered domain and pull the full SAN set, and the marketing site nobody mentioned plus the
api.legacy-brand.comendpoint in production both surface. CT never sees internal or self-signed certs. - Network scanning catches what CT can't: internal TLS on ports beyond 443, mutual-TLS services, expired certs still serving.
- Vault and CA audits catch the issuance side: query their Vault, ADCS database, and ACME account to learn what renews automatically versus what dies silently.
Reconciling two trust models and two issuance pipelines
You are now running two issuance pipelines at once. You renew through a managed CA over ACME; they used a manual ticket-and-CSR flow off an internal root. Collapsing their root into yours means re-issuing every leaf it signed, then removing the old root from trust stores only after the last dependent cert migrates. Pull it early and you break mutual-TLS across every service still chained to it.
The lifetime clock matters more than it did a few years ago. The CA/Browser Forum has put public TLS maximum validity on a stepped path down to 47 days by 2029, so any inherited public cert renewed on a human-paced annual cadence is already out of step with where the ecosystem is going. An estate you can't renew automatically expires nonstop.
Consolidating onto one governed lifecycle before the first expiry
The target is one inventory and one issuance path before the acquired estate's first inherited expiry lands. Import every discovered cert with its CA, expiry, and owning host. Route renewals through a single pipeline. Flag the certs chaining to a CA you intend to retire, so migration gets sequenced instead of discovered during an incident. A shadow CA stays dangerous exactly as long as you can't enumerate what depends on it.
Automate Certificates is built for the post-acquisition case where two inventories have to become one. Bring the acquired company in as its own Environment, run discovery against its domains, and see expiry, issuing CA, and trust dependencies for both estates in one view before anything goes dark. Start on the features page.