I understand SSL certificates cost money because of reputation: most/all web browsers have a limited list of companies that demonstrated they are trusted sources of SSL certificates and therefore don't present users with a Back To Safety! screen for those companies' products.

My question is why is this not a one-time expense? I am considering moving from a self-signed cert, but my web host just told me it would be starting at $35 per year, and they can easily go up to hundreds per year. Why isn't this a one-time fee?

  • 63
    Trusted SSL certificates can be free, see Let's encrypt. – Steffen Ullrich Apr 11 '17 at 15:02
  • 16
    Because there is a recurring cost to the ones providing the cert. There's a bunch of maintenance involved. – schroeder Apr 11 '17 at 15:02
  • 2
    It is a one-time fee of $35, for a certificate that is valid for one year. Want a new one after this certificate expires? $35 again please. And so it becomes yearly. – marcelm Apr 12 '17 at 15:17

It's easy to think that the certificate has a limited lifetime just in order to charge a recurring fee, but it is actually the other way around: a certificate has a limited lifetime, and therefore you will have to pay for a new one when the lifetime is up.

To understand why this is the case, read the FAQ of Let's Encrypt, who issue free certificates, but limit their lifetime to 90 days. Their primary justification is this:

They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.

For as long as the certificate is valid, anyone obtaining a copy of that certificate and its corresponding private key can impersonate the owner of that domain. If your system is compromised, or you sell on the domain, or anything else about the certificate's status changes in that time, clients may continue to trust the certificate.

It is possible to revoke a certificate within its lifetime, but this relies on the client checking with a revocation list maintained by the Certificate Authority, so it is not as reliable as the expiry date which is part of the tamper-proof certificate.

This is actually one of the strengths claimed by Let's Encrypt: they are offering the same level of validation as basic certificates from paid services, but by using an automated system, they remove the temptation to buy long-lasting certificates.

If you do not need "Extended Validation" (certification of your corporate identity, rather than just your ownership of the domain), then using Let's Encrypt and renewing more frequently, but for free, and automatically, may be your best course of action. On some web hosts, this is now as simple as ticking a box in the control panel to enable the automated configuration.

  • 5
    You barely touch on it, but you should explain why "certification of your corporate identity" is a good thing. Anyone can get an SSL certificate for facebooc.com, which allows HTTPS to work and certifies that you own the domain. However, it doesn't certify that this page, which sure does look an awful lot like Facebook, is owned by the company that seems to be hosting it. On the other hand, extended validation promise not only that this is actually the server you're connecting to, but also the organization. – Nic Hartley Apr 12 '17 at 2:22
  • 3
    @QPaysTaxes I didn't "sell" EV certificates much, because I'm not all that impressed by them as a user. It's a discussion for another time, but "the organization you expect" isn't always obvious, e.g. britishgas.co.uk/identity And as long as not everybody uses EV, I have to remember which sites should show it in order for the lack of it to mean anything. – IMSoP Apr 12 '17 at 8:25
  • 2
    @QPaysTaxes It's funny how you use Facebook as an example, because they certainly are not serving an EV certificate to me at least. – a CVn Apr 12 '17 at 15:00
  • 5
    @QPaysTaxes The fact that you didn't happen to remember whether Facebook use an EV cert or not is basically my point about having to remember for it to be useful. If you go to Facebook right now, and don't see an EV cert is that because a) you've been tricked into going to the wrong domain / a mis-issued certificate, or b) because Facebook never bought an EV cert in the first place? The presence of an EV cert may feel reassuring, but it doesn't actually help much unless the absence of an EV cert becomes an automatic cause for alarm. – IMSoP Apr 12 '17 at 16:25
  • 1
    @QPaysTaxes OK, point taken, but I think that education should be realistic about what value EV gives in practice, right now, so stand by my position of not advertising it at every opportunity. The theory of proving identity is sound, but there remain challenges with how end-users can actually make use of that proof. – IMSoP Apr 13 '17 at 11:31

Let's start with the cynical view:

Certificate Authorities are for-profit companies, so they will charge as much as they are able to get away with!

More seriously, running a certificate authority is an expensive, low profit margin business, but the answer really comes down to the type of certificate you want.

Domain-Validated (DV) Certificates

For a basic DV cert which, makes your browser address bar look like this: DV cert in browser address bar

the costs are very low - basically the CA just needs to confirm that the person requesting the cert had control of the server at the time of request. This can be fully automated. As @SteffenUllrich points out, in 2014 the Electronic Frontier Foundation, Mozilla, and the University of Michigan teamed up to set up a 100% free CA Let's Encrypt for issueing DV certs. Based on the use-case you described in the question, it sounds like that would suit your needs.

Extended Validation (EV) Certificates

If you want the high-end certs that include your verified company name and country in which it is registered to appear in the browser like this:

EV cert browser address bar

then there is significantly more cost to the CA. Before issuing an EV cert, the CA is required to have a human verify a whole pile of things about the legal status of your company. Things like: is your company legally registered under the name listed in the cert request? Is the person requesting the cert listed as a legal officer of the company in the company's registration documents? Is the DNS record for the requested website registered to the same company? etc.

Why a recurring fee?

The reason that CAs charge a recurring fee is the same reason that you can't get a 10 year SSL cert: the CA/Browser forum requires certs to expire and be completely re-validated every year or two. The security reasons for this are to force key rollover, to prevent the company from going bankrupt or changing name and a rogue sysadmin from continuing to use the cert nefariously, etc.

The CA is required to do all this background checking not only on first time issuance, but also every time the cert is renewed. The added value for you is that your customers get a higher level of assurance in the trust-worthiness of your website (sure, 99% of consumers won't notice, but auditors and hackers certainly will!), and also, Google is moving towards giving higher search preference to sites with higher quality certs.

This is why certs can cost hundreds of dollars per year; you are not just paying for a couple bits of data, you are paying for the time of the human who has to do the verification.

OCSP servers

There are also server costs for maintaining a cert, mainly the costs of OCSP, which requires the CA to maintain high-bandwidth, low-latency, zero-downtime servers for responding to revocation checks on each cert they issued. While this might not sound expensive, every web browser must ping a CA's OCSP server during every HTTPS page load. Every extra millisecond that the CA takes to respond adds to the page load time of every page on the internet. Running a low-latency server at this level of traffic is a tricky network engineering problem.

[disclosure: I work for a CA]

  • 27
    This explains why CAs charge money, but not really why that money is a recurring fee. It's a recurring fee because it's a recurring process, and it's a recurring process for security reasons, not financial ones. Everything you say in this answer would apply to a certificate with an expiry date 50 years in the future, or with no expiry date at all, if clients would honour such a thing. – IMSoP Apr 11 '17 at 17:19
  • 7
    "sure, 99% of consumers won't notice" On the flip side, if your users are adversely affected on any kind of scale, people would certainly notice. Sometimes you pay to avoid becoming headline news. ;) – jpmc26 Apr 11 '17 at 20:15
  • 6
    @davek: That's not what IMSoP is saying. The reason why it's a recurring process is not due to recurring cost of running the servers (indeed, letsencrypt charge you $0 for a certificate yet they must still maintain their servers). The reason why it is a recurring process is because validating trust (which is the model certificates are based on) must be done periodically therefore by design certificates must expire and be re-issued. It's a security decision based on the security model the whole system was designed around – slebetman Apr 12 '17 at 1:39
  • 3
    "Disclosure..." That's not a disclosure, that's a source. – Nic Hartley Apr 12 '17 at 2:19
  • 7
    @PlasmaHH If there was no other reason for short certificates than making money, free CAs like Let's Encrypt would issue 10-year certificates, because it would be cheaper for them to operate the service. They don't, because the certificate expiry is there for security reasons not just as a money-making exercise. – IMSoP Apr 12 '17 at 8:18

During the lifetime of the certificate, the CA must be able to revoke it, that means:

  • maintaining the list of revoked certificates (CRL)
  • responding to clients asking for the revocation status (OCSP).

So as long as the certificate is valid, the certificate "cost" something to the CA.

Furthermore, the CA must maintain a high level of security and trust, to avoid been untrusted by browsers.

To explains more about OCSP:

Each visitor of a website may ask the CA for a proof of non-revocation. That proof must be recent, than mean the CA must sign that proof regularly (around each 10 days) for each active certificate.

To have a real overview of what it cost to run a (non-comercial) CA:


Staffing $2.06M USD

Hardware/Software $0.20M USD

Hosting/Auditing $0.30M USD

Legal/Administrative $0.35M USD

Total $2.91M USD

Of course, for a commercial CA you have to add the cost of Billing, Ads, Investor remuneration...

And, for OV/EV certificates, you have to add the cost of the manual verification of the documents submitted to demonstrate the ownership of the company.

  • Thinking about it, I don't think this adds up. The cost to respond to OCSP queries is proportional only to the number of currently non-expired certificates. If you are the issuer for a domain for 10 years, you will hold 1 record at a time for that domain, whether that's a single 10-year record, or 10 consecutive 1-year records, or 120 consecutive 1-month records. The only marginal costs I can see are a slightly longer revocation list (containing revocations from longer ago), and maintaining records for customers who would have let renewal lapse; neither seems likely to be that high. – IMSoP Apr 12 '17 at 14:32
  • @IMSoP CAs only need to supply revocation information for currently-valid certificates; expired certificates are expected to be untrusted by default. However, they do need to supply revocation information for currently-valid certs. So if a CA issues a single certificate for one year or ten years they need to supply revocation data for that period of time. If a CA issues certificates valid for ten years, then by consequence it needs to serve ten times as much revocation data, and handle ten times as many requests for revocation data, than if it issued certificates valid only for one year. – a CVn Apr 12 '17 at 15:03
  • @MichaelKjörling Why would there be 10 times as many requests for revocation data? If you have 100 customers with 10-year certificates, that's 100*n requests; if you have 100 customers with 1-year certificates that they renew every year for 10 years, that's still 100*n requests. At any given moment, the volume of revocation requests is proportional to the number of currently valid certificates, regardless of how long those certificates are valid for. The only extra certificates would be customers who are "locked in" by the longer expiry, who would otherwise not have renewed. – IMSoP Apr 12 '17 at 15:35
  • @IMSoP I've add information about OCSP and Let's Encrypt costs – Tom Apr 13 '17 at 10:30
  • OK, I think I get what you're saying now: the CA has to set some lifetime, because they have to account for running costs over that lifetime. They could issue a 10-year certificate for 10 times the price of a 1-year certificate (if there were no security reasons not to do so), but they wouldn't know what to charge for an open-ended certificate, because they would have no idea how many years they'd have to maintain it for. (Although note that some of the costs in your edit would be lower for longer or unlimited lifetimes, e.g. validation happens more often the shorter the lifetime.) – IMSoP Apr 13 '17 at 10:42

One purpose is because after a year, your computing power might be able to break the certificate, so they renew it.

If I were to give you a one-life-time certificate, then after a year or two, I could break your certificate, thus it's not a good idea to have one certificate for a lifetime.

  • this is covered by other answers - and the way you have phrased it, it doesn't answer the question - you've answered why you would want a new cert, not why the issuer automatically charges a yearly fee – schroeder Apr 12 '17 at 9:04
  • 1
    Thank you for your comment, although I still think it's good to have a short on-the-mark answer. @schroeder – Jeremy Shiklov Apr 12 '17 at 9:19
  • 1
    We try to encourage answers here to be unique and standalone. It might be short, but it is also wrong. – schroeder Apr 12 '17 at 9:39
  • 1
    This is certainly a consideration, but it's not the main purpose. Signing algorithms are not upgraded all that often, and somebody brute forcing your key is not a particularly likely attack. It's the right general idea, though - in short, expiry dates are much easier to implement than a solid revocation system. – IMSoP Apr 12 '17 at 10:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.