Daniel sent us this one about SSL certificates — the paid kind, specifically. He's been building websites for two decades, and he's noticed something that doesn't quite add up. We've got free automated certificates everywhere now. Cloudflare issues them automatically. Certbot will pop one out on a VPS in about thirty seconds. Shared hosting panels handle it in the background. And yet, there's still a thriving market for paid SSL certificates — standalone, purchased from commercial certificate authorities, the kind you buy and then manually bring to your server. His question is: why does this market still exist? What are the paid options actually doing that the free ones don't?
This is one of those questions where the surface-level answer is simple, but the deeper you go, the more interesting it gets. A lot of developers have this exact reaction — "why would anyone pay for this?" — and then they hit a scenario where suddenly they understand.
The slow realization that someone else's business model isn't stupid, it's just solving a problem you don't have yet.
Let's start with the thing most people don't realize: the free certificates we've all gotten used to — Let's Encrypt, Certbot, Cloudflare's edge certificates — these are Domain Validation, or DV, certificates. They verify that you control the domain. That's it. You prove you can put a file at a specific URL or create a specific DNS record, and the certificate authority says, "Fine, here's your padlock.
The paid ones are doing more than that?
That's the core of it. Paid certificates — from companies like DigiCert, Sectigo, GlobalSign — offer Organization Validation, OV, and Extended Validation, EV. These involve actual human verification. The CA checks that your organization is legally registered, that you operate at the physical address you claim, that you're a real entity. With EV, it's even more rigorous — they verify your operational existence, your legal identity, and that you've authorized the certificate request.
The paid certificate isn't just saying "this domain is encrypted." It's saying "we have checked who runs this domain, and here's who they are.
For a long time, that distinction was visible to users. EV certificates used to display the organization's name in the browser address bar — that green bar, the company name right next to the URL. Banks used it heavily. PayPal used it. E-commerce sites used it.
Browsers gradually removed that visual indicator. Safari dropped the EV name display in twenty eighteen. Chrome and Firefox followed. Today, an EV certificate and a DV certificate look identical to the user — just the padlock. So you might look at that and think, well, EV is dead, right?
That would be the logical conclusion. But the market's still there.
The market's still there. And that's what makes this question interesting. It's not dead — it's shifted. The value proposition has moved from being user-facing to being something else entirely.
What is it now?
Let's break it into layers. The first layer is warranty. Free DV certificates come with no warranty. If something goes wrong — if the certificate is mis-issued, if there's a security failure attributable to the CA — you're on your own. Paid certificates typically come with a warranty, ranging from ten thousand dollars to over a million for enterprise-grade EV certificates.
What does the warranty actually cover? What's the scenario where the certificate authority pays out?
If a CA issues a certificate to someone who shouldn't have it, and that certificate is then used to impersonate your site, and users suffer losses, the warranty is designed to cover that. It's rare. But for certain industries — finance, healthcare, legal — having that warranty is part of their risk management framework. Their compliance people want it. Their auditors want it. It's a checkbox.
It's not that the warranty is likely to be used. It's that having it signals something to the people who sign off on security budgets.
That's part of it. But there's a second layer that's more operationally meaningful: certificate lifecycle management tooling. The paid CAs aren't just selling you a certificate. They're selling you a management platform. DigiCert has CertCentral. Sectigo has their Certificate Manager. These platforms scan your entire domain infrastructure and find every certificate that's out there, including the ones you've forgotten about.
The shadow IT problem, but for certificates.
In a large organization, that's a real problem. You've got marketing spinning up microsites. Different teams deploying services on different subdomains. Certificates expiring at different times. The management platform gives you a single pane of glass — expiration alerts, automated renewal, policy enforcement. You can set rules like "every certificate for this domain must be OV or higher" and the platform enforces it.
That sounds genuinely useful at scale. But couldn't you build that yourself around free certificates?
And some organizations do. But then you're in the business of building and maintaining certificate lifecycle management infrastructure. For a lot of companies, especially in regulated industries, the calculus is: we'd rather pay for a platform that does this out of the box and comes with an SLA, with support, with someone to call when things break. The certificate itself is almost the least important part of the package.
You're buying the service layer, not the bits.
The third layer, and this one gets overlooked a lot, is support and incident response. When the free CA ecosystem has an incident — and it has, Let's Encrypt has had revocation events — you're on your own. You figure it out. When you're a paying customer of a commercial CA, you have a support contract. You have an account manager. When there's an industry-wide revocation event, they're proactively reaching out to you. For a bank or a hospital or a government agency, that difference matters.
It's the same reason people pay for Red Hat when CentOS exists, or pay for managed databases instead of running their own Postgres instance. The software is free. The confidence is not.
That's exactly the right framing. Now let me add a fourth layer, and this connects to something we talked about recently around the plumbing of the internet — certificate transparency and trust chains.
When you get a free certificate from Let's Encrypt, you're in a shared ecosystem. Let's Encrypt is backed by IdenTrust, and their root certificate is trusted by all major browsers and operating systems. That's great. But what if your organization has specific requirements about which root certificates you trust? What if you're a government agency that requires certificates chained to a specific root under your own national CA's hierarchy? What if you're a defense contractor that needs certificates issued from a CA audited to a specific standard?
The free providers don't offer that flexibility.
They don't. Commercial CAs offer a range of trust chain options. They'll issue you a certificate chained to different roots depending on your requirements. They offer different algorithms, different key types. If you need an ECDSA certificate with a specific curve, if you need RSA with a specific key length, the commercial CAs give you those options. Let's Encrypt has been expanding their offerings — they now support ECDSA — but you get what they offer, when they offer it.
It's the difference between a set menu and ordering à la carte.
Sometimes you need à la carte. Here's another thing: validity periods. Let's Encrypt certificates are valid for ninety days. That's by design — short-lived certificates limit the window of exposure if a key is compromised. But some environments can't handle ninety-day rotation. Load balancers that require manual certificate installation. Industrial control systems. These things exist. Commercial CAs will issue you a certificate valid for three hundred ninety-eight days — the industry maximum now. That longer validity window matters in environments where rotation is painful.
The mainframe in the basement that nobody wants to touch.
It's running a critical financial system, and the certificate renewal process involves a change management board and three weeks of approvals.
Of course there are.
Now, there's one more layer that I think is the most interesting, and it's the one that explains why the market hasn't collapsed even as DV certificates have become commoditized. It's about what the certificate represents in a business-to-business context.
What do you mean?
When you connect to a website, your browser validates the certificate. It checks the domain, the validity period, the trust chain. That's the user-facing function. But certificates are also used for machine-to-machine communication. Server-to-server connections. Backend services talking to each other. In those scenarios, the certificate is often used for mutual TLS — both sides present a certificate, and both sides validate.
In that world, the identity information in the certificate matters.
It matters enormously. If I'm a payment processor establishing a mutual TLS connection with a bank's API, I'm not just checking that the certificate is valid. I'm checking who it was issued to. I'm checking the organization name in the certificate. I might be pinning against a specific CA or a specific intermediate certificate. The OV and EV information — the organization identity — becomes part of the authentication logic.
The padlock that users don't look at is actually doing work in places users never see.
That's the story of a lot of internet infrastructure. The visible part is the tip of the iceberg. The real action is below the waterline. In B2B integrations, in financial services APIs, in healthcare data exchanges, the identity information embedded in the certificate is doing real authentication work. It's not just encryption — it's identity. And free DV certificates don't provide that identity layer. They just say "this domain is controlled by whoever requested this certificate.
Which brings us back to the question of why an organization would deterministically choose a specific certificate authority.
It's not just about OV versus EV. It's about the CA's reputation and audit history. Every publicly trusted CA undergoes WebTrust audits. These are rigorous. They examine the CA's issuance practices, their physical security, their personnel vetting, their revocation procedures. The audit reports are public. Organizations that care about their supply chain security — and increasingly, that's everyone — they look at these audit reports. They want to know: has this CA had incidents? How did they handle them? What does their revocation infrastructure look like?
You're vetting the vetter.
When you choose a CA deterministically, you're making a statement about your own security posture. You're saying, "We've evaluated the options, and we trust this CA's practices and audit history to meet our standards." For a lot of regulated entities, that evaluation is required. Their compliance framework doesn't let them just use whatever certificate Cloudflare hands out. They need to document the decision.
The compliance paperwork is the product.
But it's not just paperwork. There are real technical differences. DigiCert, one of the largest commercial CAs, runs their own certificate transparency logs. They operate their own OCSP responders with specific performance characteristics. Their revocation infrastructure is geographically distributed and designed for high availability. If you're running a service where certificate validation latency matters — and it does, because OCSP lookups happen during the TLS handshake — the performance of the CA's revocation infrastructure directly affects your users' experience.
OCSP being the Online Certificate Status Protocol — the thing that checks whether a certificate has been revoked.
When a browser encounters a certificate, it needs to verify that it hasn't been revoked. It does that either by checking an OCSP responder or by checking a Certificate Revocation List. If the CA's OCSP responder is slow or unreliable, your users see a delay. In the worst case, if the OCSP check times out, the browser has to decide whether to fail open or fail closed. Different browsers handle this differently. Chrome uses CRLsets — they push revocation data through their update mechanism rather than doing real-time OCSP lookups. But not everything is Chrome talking to a website. In API-to-API communication, OCSP behavior is implementation-dependent.
The quality of the CA's infrastructure directly affects the reliability of your service.
The commercial CAs invest heavily in that infrastructure because it's part of what they're selling. Let's Encrypt runs excellent infrastructure too — I want to be clear about that. They've done remarkable work. But their SLA is effectively "best effort." The commercial CAs have contractual commitments around availability and response times.
There's a theme emerging here. Everything you're describing — the warranty, the management tooling, the support, the trust chain flexibility, the infrastructure quality, the identity information — it's all about moving from a best-effort, community-provided service to a contractual, guaranteed service. It's the same pattern you see everywhere in enterprise software.
It's the open source versus enterprise support model, applied to certificates. Let's Encrypt and the ACME protocol — Automated Certificate Management Environment, the protocol that Certbot uses — commoditized the basic DV certificate. They made it free and automatic and ubiquitous. And that's a genuine public good. It's one of the most successful internet infrastructure projects of the past decade. But commoditizing the basic tier doesn't eliminate the need for the premium tier. In some ways, it clarifies it. It forces the paid CAs to differentiate on things that actually matter at scale.
The free tier ate the bottom of the market, and the paid tier responded by moving upmarket.
The market data bears this out. Let's Encrypt now issues something like four million certificates per day. The total number of active certificates has grown enormously. But the commercial CAs haven't shrunk. DigiCert's revenue has grown. The market for paid certificates has shifted toward higher-value, higher-service offerings. It's not a zero-sum game. The total addressable market for certificates has expanded because encryption is now the default, not the exception.
The premise of the question — "why does the paid market still exist when free certificates are so easy?" — assumes that the free certificates and the paid certificates are substitutes. But they're not, or at least not entirely. They're different products serving different needs.
That's the core insight. For a personal blog, a small business website, a hobby project — use the free certificates. They're fantastic. For a bank, a hospital, a government agency, a company that has security audits and compliance requirements and complex infrastructure — the paid certificates solve a different set of problems.
Let's get more specific about those problems. You mentioned certificate lifecycle management. What does that actually look like at scale?
Picture an organization with five hundred domains, a thousand subdomains, services deployed across three cloud providers and two on-premise data centers. Some of these services are customer-facing. Some are internal. Some are machine-to-machine. Some use wildcard certificates, some use specific subdomain certificates, some need multi-domain SAN certificates. The certificates are issued by different CAs because different teams made different decisions over the years. Some are expiring next week. Some expired two months ago and nobody noticed because the monitoring wasn't set up.
That sounds like a typical Tuesday at a large enterprise.
That's before you get to the fun stuff. What happens when a CA revokes an intermediate certificate? What happens when a root certificate expires? What happens when an industry-wide vulnerability like Heartbleed forces mass revocation and reissuance? These events happen. In July twenty twenty-five, there was a significant incident where a major CA had to revoke a batch of certificates due to a validation issue. Organizations that had certificate lifecycle management tooling handled it in hours. Organizations that didn't had outages.
The tooling isn't just about convenience. It's about incident response velocity.
It's about knowing what you have, where it is, when it expires, and who's responsible for it. That's the unglamorous reality of certificate management at scale. And the commercial CA platforms are built specifically for that problem. They integrate with cloud providers, with load balancers, with web servers. They can automate deployment. They can detect when a certificate deployed on a server doesn't match what's in inventory.
You're paying for the map of your own infrastructure.
The map stays current. That's the hard part. In a dynamic environment where services are spinning up and down, where domains are being registered and retired, maintaining an accurate inventory is a continuous challenge. The discovery scanners that the CA platforms run are doing constant reconciliation — what certificates are actually out there versus what certificates we think are out there.
I want to go back to something you mentioned earlier about mutual TLS and machine-to-machine communication. Because I think that's where a lot of developers first encounter the need for something beyond a free DV certificate.
It's a common awakening. You're building an API integration with a partner, and their security requirements say: "All connections must use mutual TLS with certificates issued by a CA from our approved list, and the certificates must contain organization identity information." And you think, okay, my free Cloudflare certificate isn't going to cut it here.
Suddenly you're in the market for a paid certificate, not because you want to be, but because the other party's security policy requires it.
That's not arbitrary. In a mutual TLS setup, the server is authenticating the client based on the certificate they present. If the certificate only proves domain control, that's a weak form of identity. Anyone who controls a domain can get a DV certificate for it. But if the certificate contains a verified organization name, and the server's policy is to only accept connections from certificates containing specific organization names, that's a meaningful authentication layer.
It's not just encryption. It's a form of access control.
It's identity-based access control at the transport layer. And it's used extensively in financial services. The SWIFT network uses it. Payment card networks use it. Healthcare information exchanges use it. These are high-stakes environments where the identity of the connecting party matters just as much as the confidentiality of the connection.
The paid certificate market isn't really about website visitors seeing a padlock. It's about machines authenticating to other machines, and it's about organizations managing risk at scale.
There's one more dimension worth talking about: the wildcard and multi-domain certificate landscape. Let's Encrypt issues wildcard certificates — they've supported that since twenty eighteen. But the validation requirements for wildcards are more stringent, and the management considerations are different. A wildcard certificate covers all subdomains at a given level. If that certificate is compromised, every subdomain is exposed. Some organizations have policies against wildcards for that reason. They prefer individual certificates per subdomain, or multi-domain SAN certificates that list specific domains explicitly.
Managing hundreds of individual certificates manually would be a nightmare, which loops back to the management platform argument.
It's all connected. The wildcard versus SAN versus individual certificate decision depends on your threat model, your operational capabilities, and your compliance requirements. The commercial CA platforms support all of these models and give you the tooling to manage them. The free ecosystem supports them too, technically, but you're doing the management yourself.
Let's talk about the Certificate Authority Authorization record, because I think that's where the deterministic choice of CA becomes visible in the DNS.
This is a DNS record that specifies which certificate authorities are allowed to issue certificates for your domain. You can set a CAA record that says "only DigiCert can issue certificates for my domain" or "only Let's Encrypt" or "any CA except these specific ones." It's a policy enforcement mechanism.
The existence of CAA records implies that organizations do, in fact, care about which CA issues their certificates.
They care deeply. If you're a bank and a certificate gets issued for your domain by a CA you didn't authorize, that's a security incident. It's potentially a mis-issuance, potentially an attack. CAA records let you constrain the attack surface. You're saying: "These are the only CAs we trust. If anyone else issues a certificate for our domain, reject it." And the CAs are supposed to check CAA records before issuing. It's part of the Baseline Requirements that govern all publicly trusted CAs.
Even in a world where certificates are technically interchangeable — any CA can issue any certificate — organizations are deliberately constraining which CAs they'll accept.
That constraint is itself a security control. It reduces the risk of mis-issuance. If a CA has a validation vulnerability, and you've constrained your CAA record to a different CA, you're not exposed to that vulnerability. It's defense in depth.
The more we dig into this, the more the question flips. It's not "why would anyone pay for certificates?" It's "why would a large organization with complex security requirements not pay for certificates?
You can see this in the market. The commercial CA business isn't shrinking. It's growing, but it's growing in the enterprise segment, not the small-business segment. The small-business segment has largely moved to free automated certificates, which is exactly what should happen. The enterprise segment has moved toward managed certificate services, toward platforms, toward identity-integrated PKI. The commercial CAs have followed the money upmarket.
There's a parallel here with email. You can set up your own email server. You can use a free provider. Or you can pay for Google Workspace or Microsoft 365. The free options exist and they work. But enterprises pay for the managed version because they want the SLA, the support, the compliance certifications, the integration with their identity provider, the admin console.
Nobody looks at Google Workspace and says, "Why does this exist when you can just install Postfix?" We understand that the product isn't the email server — it's the whole package around it.
The certificate market is the same story, just less visible because most people don't interact with certificates directly.
Now, there's something specific in the prompt I want to address. The prompt mentions Cloudflare specifically, and there's an interesting dynamic there. Cloudflare issues certificates for sites behind their proxy, but those certificates are Cloudflare's certificates. The connection between Cloudflare and your origin server is a separate TLS connection. You can use a free Cloudflare-issued certificate on the origin, or you can use your own certificate. Some organizations require that the entire chain — from user to origin — uses certificates from a specific CA. That's not possible if Cloudflare is terminating TLS at their edge with their own certificates.
If you need end-to-end certificate consistency, Cloudflare's automatic certificates might not satisfy the requirement.
Cloudflare offers Keyless SSL and options for uploading your own certificates, including EV certificates. But the point is that the automatic, free, default behavior isn't always sufficient. It's sufficient for most websites. It's not sufficient for all websites.
What about the certificate transparency logs? You mentioned those earlier.
Certificate Transparency is a system where every publicly trusted certificate is logged in publicly auditable append-only logs. The logs are operated by different organizations — Google runs some, DigiCert runs some, Let's Encrypt runs some. The idea is that anyone can monitor these logs to detect mis-issued certificates. If a CA issues a certificate for your domain, it shows up in the logs, and you can alert on it.
The logs are a check on the CAs themselves.
They're a transparency mechanism. And different CAs log to different logs. If you care about which logs your certificates appear in — maybe you want them in logs operated by organizations in specific jurisdictions — that's another factor in CA selection.
I'm starting to think that choosing a CA is a bit like choosing a law firm. You're not just buying a service. You're buying a reputation, a track record, a relationship, and someone to call when things go wrong.
That's not a bad analogy. And like law firms, the premium providers differentiate on expertise and responsiveness. When there's a vulnerability in the TLS ecosystem — and these happen, we had the ROCA vulnerability affecting RSA key generation, we've had various padding oracle attacks — the commercial CAs provide guidance, they provide tools to check whether your certificates are affected, they handle the reissuance. If you're using free certificates, you're monitoring those vulnerabilities yourself and figuring out the remediation yourself.
Which, again, is fine for a small operation. It's not fine for a hospital.
Or a payment processor. Or a government agency. Or anyone with a security operations center that has a compliance checklist.
Let's talk about the actual cost. The prompt mentions fifty to a hundred dollars for a certificate. What's the real pricing landscape?
DV certificates from commercial CAs can be as cheap as ten dollars a year. OV certificates typically range from fifty to two hundred dollars annually. EV certificates can run from a hundred to over a thousand dollars per year, depending on the CA and the level of support. But the certificate cost is dwarfed by the platform cost. DigiCert's CertCentral, Sectigo's Certificate Manager — these are enterprise subscriptions. You're paying for the platform, and the certificates are included or heavily discounted. The pricing model has shifted from per-certificate to per-organization, per-year.
The fifty-dollar certificate is almost a retail artifact. The real business is in the enterprise platform subscriptions.
The retail certificate market exists — you can go to a website, buy a certificate, download it, install it. Small businesses do this. But the growth is in the managed enterprise space. And the price point for an enterprise certificate management platform can be tens or hundreds of thousands of dollars annually for a large deployment.
Which sounds like a lot until you compare it to the cost of an outage caused by an expired certificate.
Those outages happen. Spotify went down because of a certificate expiration. Microsoft Teams had an outage due to an expired certificate. These are organizations with enormous engineering resources. Certificate management is hard even when you're good at it.
The expired certificate is the "did you turn it off and on again" of internet infrastructure. Simple in theory, catastrophic in practice.
It's always at the worst possible time. It's always three in the morning. It's always during a product launch. It's always when the one person who knows how to renew it is on vacation.
The enterprise value proposition is basically: we will make sure it's never three in the morning and nobody's on vacation.
That's the promise. Automated renewal, proactive alerting, policy enforcement, and if something still goes wrong, a support engineer who can fix it.
I want to circle back to something. The prompt mentions using Certbot as a "less elegant solution" compared to Cloudflare's automatic issuance. And I think that's worth unpacking, because it gets at why the free ecosystem, for all its virtues, hasn't completely replaced the paid one.
Certbot is the reference implementation of the ACME protocol. You install it on your server, it communicates with Let's Encrypt, it proves domain control, it gets a certificate, it installs it. It can handle automatic renewal. For a single server, it works fine. For ten servers, it's manageable. For a hundred servers across multiple providers, it becomes a distributed systems problem. You need to make sure Certbot is installed and configured correctly on every server. You need to make sure the renewal cron jobs are running. You need to make sure the certificates are being distributed to the right services. You need to handle load balancer termination, CDN configuration, internal service communication.
Certbot solved the issuance problem but not the management problem.
It solved the individual issuance problem beautifully. It did not solve the fleet management problem. And that's where the commercial platforms come in. They're not just issuing certificates — they're managing the entire lifecycle across a distributed infrastructure. They're pushing certificates to cloud load balancers via API. They're updating Kubernetes ingress configurations. They're sending notifications to Slack when something's about to expire.
So the automation piece has been adopted everywhere. The differentiation is everything around it.
ACME has become the standard. DigiCert supports ACME. Sectigo supports ACME. You can use the same automation protocol with a commercial CA that you'd use with Let's Encrypt. The difference isn't the protocol. The difference is what comes with it — the platform, the support, the warranty, the identity information in the certificate, the trust chain options.
If you're a developer who's been using Let's Encrypt and Certbot for years, and you join a large enterprise, you might be surprised to find that the same ACME automation you're used to is being used, but with a different CA, a management platform, and a whole layer of process around it.
You might initially think it's unnecessary bureaucracy. But then you discover that the organization has two thousand certificates across four hundred domains, and half of them were issued by teams that no longer exist, and there's no inventory, and certificates are expiring silently, and nobody knows who's responsible for what. And suddenly the management platform makes sense.
The bureaucracy is a response to genuine complexity, not just bureaucracy for its own sake.
But in certificate management, the complexity is real. The stakes are real. An expired certificate on a customer-facing service is a visible outage. An expired certificate on a backend API can break internal services in ways that are hard to diagnose. A mis-issued certificate can be a security incident that requires disclosure.
Let's address one more angle. The prompt asks specifically about the advantages of deterministically choosing a specific certificate authority. We've covered the management platform, the warranty, the support, the identity information, the trust chain flexibility. Is there anything about the certificate itself — the cryptographic properties — that differs?
The certificate format is standardized. 509 certificate from Let's Encrypt and an X.509 certificate from DigiCert have the same structure. They both contain a public key, a subject, an issuer, a validity period, extensions. The cryptographic primitives are the same. But there are differences in the details. The certificate policy extension — that's an OID that indicates the CA's issuance practices. The authority information access extension — that points to the CA's OCSP responder. The CRL distribution points. The embedded SCTs for certificate transparency. These extensions differ between CAs and can affect how the certificate is validated and what information is available to relying parties.
Even though the certificate looks the same to a browser, the metadata inside it tells a different story depending on who issued it.
In some cases, that metadata is used for policy decisions. A server might be configured to only accept certificates that contain a specific certificate policy OID. A monitoring system might check the OCSP responder URL to ensure it's pointing to a CA with acceptable performance characteristics. These are edge cases, but they exist, and they matter in high-assurance environments.
What about the physical security of the CA operations? You mentioned WebTrust audits earlier.
The WebTrust for Certification Authorities audit is the standard. It covers physical security, logical security, personnel controls, issuance procedures, revocation procedures. The audit reports are detailed. They describe the CA's facilities, their access controls, their key management practices. For the root CA keys — the keys that anchor the entire trust chain — the security requirements are extreme. We're talking about hardware security modules in physically secured facilities with multi-person access controls, video surveillance, background-checked personnel. The root key signing ceremonies are sometimes conducted in public or with witnesses to provide transparency.
When you choose a CA, you're also choosing their physical security posture.
You're choosing their entire operational security framework. And different CAs have different audit histories. Some have had incidents. Some have had near-misses. Some have spotless records. Organizations that care deeply about supply chain security evaluate this.
It occurs to me that we've been talking about this as if the choice is between free and paid, but there's another dimension: some organizations run their own internal certificate authorities. They're not buying from a public CA at all.
Yes, this is common in large enterprises. You run your own CA, you issue your own certificates for internal services, you distribute your own root certificate to all your managed devices. For internal-only services, this makes a lot of sense. You have full control. You're not dependent on an external CA. You can issue certificates with whatever validity period and properties you want.
For public-facing services, you still need a publicly trusted certificate.
The private CA's root certificate isn't trusted by public browsers. So the pattern is often: private CA for internal services, public CA for customer-facing services. And the certificate management platforms handle both. They manage your private CA hierarchy alongside your public certificates. That's another thing the free tools generally don't do — they don't give you a unified view of your internal and external certificate landscape.
We've got a picture now. The paid certificate market exists because enterprises need: one, verified organizational identity in certificates; two, certificate lifecycle management at scale; three, contractual support and warranties; four, trust chain and algorithm flexibility; five, platform integration across diverse infrastructure; six, compliance documentation and audit readiness; seven, incident response velocity; and eight, unified management of public and private PKI.
That's a good summary. And I'd add a ninth: risk transfer. When you pay a commercial CA, you're transferring some of the risk. If something goes wrong, you have a contract, you have recourse, you have someone to blame. That sounds cynical, but in enterprise risk management, having a vendor to hold accountable is valuable. It changes the conversation from "our team screwed up" to "our vendor had an incident, and here's how they're remediating it.
The vendor is also a heat shield.
In the best and worst sense of that phrase, yes.
The question "why do paid SSL certificates still exist" turns out to have a very clear answer. They exist because the free certificates solved one problem — basic domain-validated encryption — and in doing so, revealed a whole set of other problems that only become visible at scale. The paid market didn't die.
It's worth saying that the free certificate ecosystem, led by Let's Encrypt, has been an enormous net positive for the internet. Before Let's Encrypt launched in twenty sixteen, only about forty percent of web pages were loaded over HTTPS. Today it's over ninety percent. That's a direct result of making certificates free and automatic. The internet is more encrypted, more private, more secure because of that work.
The rising tide lifted all padlocks.
And it also created a larger market for the premium tier, because now encryption is the baseline, and organizations are asking, "What do we need beyond the baseline?" The answer, for a lot of them, is the commercial CA ecosystem.
I think there's a broader lesson here about commoditization. When something becomes free and automatic, it doesn't eliminate the market above it. It clarifies what the market above it is actually selling. The free tier isn't competing with the premium tier. It's doing something different for different people.
The people who need the premium tier know who they are. They're the ones with compliance requirements, with complex infrastructure, with security teams, with auditors, with incident response plans. They're not confused about why they're paying. They're paying because the alternative is more expensive in ways that don't show up on the certificate price tag.
The hidden cost of free is the cost of managing it yourself.
At scale, yes. At small scale, free is free and fantastic. At large scale, free means you're the CA management platform. You're the support desk. You're the incident response team. You're the compliance documentation writer. And the cost of being all those things exceeds the cost of paying for the commercial service.
Which is the same calculus that applies to every build-versus-buy decision in technology.
SSL certificates aren't special. They're just a particularly clear example of a pattern that repeats everywhere.
And now: Hilbert's daily fun fact.
Hilbert: In the nineteen thirties, a geologist exploring an ice cave in Greenland discovered a single frozen leaf perfectly preserved in a layer of ice that had not melted in over four thousand years. The leaf, from a species of dwarf willow that no longer grows in the region, was the only surviving organic artifact in a cave system otherwise devoid of any biological material.
A leaf in a cave. Alone for four thousand years.
