Per-certificate pricing isn't certificate management. It's accounting pressure cosplaying as architecture.

A certificate is not a luxury item. It is not a seat. It is not a consumable to ration. It is a trust boundary. And if your platform charges you every time you draw one, it is quietly nudging you to draw fewer of them – and to draw them wider than they should be.

That is crazy.

The choice in front of you isn't "public CA or private CA." It is Borrowed Trust or Owned Trust – and the right answer is almost always a deliberate mix of both, chosen by your architecture rather than your invoice, and on your timeline rather than someone else's.

The Behaviour the Pricing Creates
For years, teams have been told certificates are scarce objects you buy by the unit. So operators do the rational thing under bad pricing: they consolidate.

One wildcard for *.int.example.com. One cert copied across ten servers. One renewal path that touches everything. One private key that now impersonates an entire internal namespace.

It looks tidy on a dashboard and cheap on a quote, but it is also a single shared secret for your whole network, sitting in a Java keystore on a box nobody owns anymore. Per-cert pricing didn't cause every bad cert decision in your estate – it just made every bad decision cheaper than the right one.

What per-cert pricing actually asks you to do

• Reuse keys to avoid paying for separate ones
• Stretch wildcards to avoid paying per name
• Skip mTLS to avoid paying per client
• Skip rekeys to avoid paying to rotate
• Delay renewals to avoid paying for the cycle
• Treat short-lived certs as a luxury because they multiply your bill
• Every one of those is the opposite of what you'd do if you were designing for containment, rotation, and identity hygiene.

Certificate Count Isn't the Problem
The problem isn't that you have "too many certificates." The problem is that you don't know where they are, who issued them, which private keys are reused, which renewals are manual, which certs are pretending to be identity proofs when they're really just name proofs – and what actually breaks when you have to rekey a wildcard distributed across a dozen appliances and keystores at 2am.

Charging per cert doesn't fix any of that. It compounds it.

Good certificate hygiene usually means more certificates, not fewer: one identity per service, one key per workload, one cert per trust boundary, with server TLS kept separate from client identity and "make Chrome happy" kept well away from "prove this device belongs here."

That is what mature trust operations looks like. So why would your certificate platform punish you for doing it?

Wildcards Are Not Free
Wildcards are useful. Sometimes they're exactly right – for browser-trusted TLS on low-risk internal web UIs, a public DNS-01 wildcard is often a clean answer. But a wildcard isn't magic. It's a shared impersonation token for a namespace.

If the key for *.int.example.com leaks, an attacker can impersonate anything under that name:

• your firewall UI
• your admin console
• your Git server
• your dashboards
• your RDP endpoints
• your internal APIs
• your VPN portal

The pitch you'll hear is that wildcards keep individual hostnames out of Certificate Transparency logs, so attackers can't enumerate your internal services from public sources. That is true. It is also the wrong threat model. CT-log privacy is privacy from drive-by external scanning – not privacy from an attacker who already has footing inside the network and is reading DNS, walking service registries, and inspecting load balancers.

Wildcards buy privacy from CT logs by spending key containment – and they buy it against the threat that matters least. That tradeoff may sometimes be acceptable. It should always be a decision, not a default driven by an invoice or a marketing pitch.

Borrowed Trust Comes with a Clause
What public-CA automation also doesn't do is remove dependencies. It moves them. Your DNS credentials may stay with you, but your trust path now depends on a vendor control plane, a delegated validation zone, public DNS resolution, an ACME issuer, and a root program policy that can shift without consulting you.

Call this what it is: Borrowed Trust. Often useful, frequently the right answer for a specific job – but borrowed all the same. It is dependency that somebody else owns and operates on their schedule, not yours.

What the lender can change, without asking you

• Rate limits you can't burst through during an emergency rekey or fleet expansion
• Certificate lifetimes that break your renewal cadence
• Validation methods that invalidate your client implementation
• ACME profiles that take your tooling with them on retirement

The certificate lifetime trajectory across the public CA ecosystem has moved from one year to ninety days to six days inside a decade – and operators who built around the old cadence didn't choose to migrate. They migrated, or they stopped working.

Owned Trust – a private CA on a platform that takes day-2 ops seriously – is more responsibility, but it answers to your policy, your timeline, and your operational reality, not somebody else's roadmap.

Flat Pricing Changes What's Possible
[cyphrs]™ is flat priced. £999 a year covers the hubs you need, with unlimited certificates, unlimited renewals, and unlimited rekeys. No per-cert tax. No per-renewal penalty. No pricing pressure toward wildcard sprawl. No financial reason to skip a rekey after a key-handling mistake. No invoice asking you to keep a 90-day cert because the 7-day one would cost twelve times as much.

Per-cert model incentivises

• Wildcard sprawl
• Key reuse
• Skipped rekeys
• Delayed renewals
• Fewer, wider certs

Flat pricing enables

• Narrow, purpose-specific certs
• Per-workload key isolation
• Frequent rekeys
• Short-lived certs
• mTLS everywhere it fits

Use narrow certs where narrow is safer, a public wildcard where a public wildcard fits, and private PKI where identity, policy, and control are the actual requirement. The point is not "private CA everywhere" – the point is the right trust path in the right place, chosen by your architecture and not by your invoice.

Discovery First. Always.
Most teams don't need another certificate spreadsheet – they need to know what they already have. [cyphrs]™ starts with Discovery: public versus private PKI usage, wildcard blast radius, CT exposure, forgotten certs, key reuse, renewal fragility, clientAuth and mTLS gaps, and the deployment pain that lives across Windows, Java, appliances, Kubernetes, and the long tail of internal services nobody wants to touch.

Sometimes the answer is public DNS-01 automation. Sometimes it's private PKI. Often it's both, in different places, for different reasons. What matters is that the decision gets made from the architecture, not from the pricing model.

Deployment Is Not Architecture
Some of the pain that pushes teams toward public-CA automation is real. Distributing roots to every contractor laptop and vendor console is annoying. Network appliances with creaky web UIs are annoying. Java keystores are annoying.

None of these are architectural arguments – they're deployment arguments, and they get solved by good agents, good APIs, and a platform that takes deployment seriously across the surfaces where it actually hurts.

When a vendor tells you private PKI is too hard, what they're selling you is the easier deployment story. They are not answering the architecture question. They are hoping you forget you had two different questions to answer.

Stop Paying Per Cert. Start Operating Trust.
Read what per-cert pricing is actually asking you to do, written plainly: reuse keys to avoid paying for separate ones; stretch wildcards to avoid paying per name; skip mTLS to avoid paying per client; skip rekeys to avoid paying to rotate; delay renewals to avoid paying for the cycle; treat short-lived certs as a luxury because they multiply your bill.

Every one of those is the opposite of what you'd do if you were designing for containment, rotation, and identity hygiene.

The platform is supposed to help you do trust well. Instead it taxes you for trying.