28

As far as I can tell, a CA is in a position to unilaterally revoke a certificate via the standard mechanisms (CRL, OCSP).

In an increasingly TLS world, what current technology stops a CA shutting down a service they don't like?

Improve this question
2
  • 1
    The thing is elimination of CA as a role. There's alot of cases of "leaks", "accidents", cloning main CA certificates for traffic inspectors, etc - we must trust each other, but no central point. Perspectives Projects is a good start at this point
    – Alexey Vesnin
    Mar 17, 2016 at 0:32
  • Can whoever voted to close for "unclear what your asking" add a comment asking for clarification? It seems pretty clear to me.
    – Phil Lello
    Mar 18, 2016 at 15:30

3 Answers 3

Reset to default
41

Peer pressure, effectively.

There is a multi-layer structure of trust - the CAs trust the browser makers to include their root certificates, and not remove them without reason. The browser manufacturers trust the CAs to only sign certificates for legitimate requests, and implicitly agree to believe this, with the threat of removing the root certificates of CAs that don't actually do this. Website owners trust the CAs to work to keep their root certificates in all popular browser bundles (since manually adding certificates is a massive hurdle to user experience), and the browser manufacturers to keep root certificates in their bundles, unless there is some good reason not to (e.g. the CA asked for them to be removed).

Therefore, if a CA unilaterally revoked a certificate, the browser manufacturers could demand a reason, and, if they found that the reason was insufficient, remove the root certs belonging to that CA. They're unlikely to do so, unless it's a pattern (for example, revoking certificates belonging to sites in favour of a given political party).

Improve this answer
7
  • Also add that all big search engines also have deals with browser makers and CAs.
    – blankip
    Mar 16, 2016 at 19:31
  • 3
    @blankip Quite seriously, is that a safeguard or a risk?
    – Phil Lello
    Mar 16, 2016 at 19:57
  • @matthew Interesting that you give the political party example; given the time needed for dialogue between browser vendors and CA, plus time for updates to propogate, there's a risk of abuse in a critical pre-election period.
    – Phil Lello
    Mar 16, 2016 at 20:09
  • 1
    @PhilLello Yes, although as mentioned by MikeOunsworth in a comment to one of the other answers, "critical" systems like that should use multiple CAs, to be able to deal with issues involving root revocation - imagine a party that secretly generates a bunch of fraudulent CSRs, a CA signs them innocently, the party points out the dodgy signings, and the root cert is revoked - conveniently taking out the opposition party website for no fault of its own...
    – Matthew
    Mar 16, 2016 at 20:17
  • 12
    Also, who wants to get their cert from a CA that's known to randomly revoke certs?
    – user253751
    Mar 17, 2016 at 2:22
25

By definition, the CA is managing the revocation. In fact, it is a conceptually better way to express thing as: the CA reissues all certificates on a daily basis. The CRL is a kind of data compression: from the point of view of the verifier (say, the Web browser that validates the SSL server's certificate), the certificate is valid as long as the CA says it is OK. To make things lighter, instead of the CA signing a new certificate for each customer every day, the CA signs long-lived certificates and includes only revoked certificates in the CRL. This is an optimization that works under the assumption that most certificates won't be revoked.

Since keeping the certificate afloat is the CA daily job, there is no technology that may prevent the CA from ceasing to do so. What "forces" CA not to revoke certificates on a whim is contract law (you paid the CA for the service, so it is bound by law to maintain that service) and market pressure (if the CA revokes certificates without justification, customers will simply move their business to a competitor).

Improve this answer
6
  • 3
    It's amazing how much of our trust in CAs rests on audits and market pressure. As far as we know, the system works though...
    – Mike Ounsworth
    Mar 16, 2016 at 19:11
  • 8
    "the system works though" - just like the democracies that bring us NSA and GCHQ :)
    – Phil Lello
    Mar 16, 2016 at 19:41
  • Also worth noting that one argument in favour of 'SSL Everywhere' is the availability of free certs. IANAL, but probably in some jurisdictions, payment is required for to create a contract.
    – Phil Lello
    Mar 16, 2016 at 20:03
  • 2
    @pabouk: I use "daily" as a summary. Each CA sets its CRL renewal policy. However, an hourly CRL validity incurs problems in practice, because the verifying machine may have a slightly incorrect clock (especially around changes to and from daylight saving time). Conversely, if CRL are renewed on a monthly basis, then revocation is rather useless. Most deployed CA thus use CRL renewed daily or weekly, or some in-between rhythm.
    – Thomas Pornin
    Mar 17, 2016 at 14:10
  • 1
    Also, revocation is usually asynchronous -- a certificate is revoked because of an unexpected condition that has been just detected (say, a key compromise). It does not make a lot of sense to insist on "immediate" revocation for key compromises, since key compromises often take hours or even days to be detected.
    – Thomas Pornin
    Mar 17, 2016 at 14:11
7

The owner of the site could simply get another certificate from a different CA, and be back up and running.

Improve this answer
11
  • 11
    Further to your point: anybody running a critical service over TLS relying on an external CA should have multiple certs from multiple CAs as a backup plan in case that CA has a breach and has its root cert pulled. The couple hundred dollars to have a cert that you never use is well worth it against the cost of a massive service outage if a CA goes under.
    – Mike Ounsworth
    Mar 16, 2016 at 19:14
  • 2
    Generally yes, but it might be more problematic if technologies like DANE, HSTS and HPKP are used.
    – Ctx
    Mar 16, 2016 at 19:44
  • 1
    @kasperd Really? Getting an EV certificate requires TONS of paperwork, phone calls, sometimes physical meetings. It takes days at best. You're willing to let your servers be offline for that long?
    – Mike Ounsworth
    Mar 17, 2016 at 11:51
  • 1
    @kasperd uuuuhhhhhh, then how do you explain your comment "it doesn't make a major difference whether the procedure to switch certificate involves a step of acquiring a certificate or not." ... because in the case of an EV cert, it makes a big difference.
    – Mike Ounsworth
    Mar 17, 2016 at 12:38
  • 2
    @MikeOunsworth Frankly, most people don't know what an EV certificate is, and don't check for the green box. I agree that having an EV certificate is a good thing, for the small percentage of users that will, but I think most sites could afford to get a cheap non-EV cert while waiting for all of that paperwork to go through. Especially since the chances of your certificate being revoked without warning and being unable to get a replacement is very small.
    – Patrick M
    Mar 18, 2016 at 6:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .