The CA issues certificates to clients/servers. Whenever a request is made by the client/server, the certificate is used to verify the identity.

Now, if a certificate needs to be revoked then who does it and how? Does the client/server "mark" it as revoked? Or does the CA do it? If the CA does it then how does it know when to revoke what?

Also, is there a field on the certificate that tells that it is revoked? Or is there a blacklist of certificates maintained somewhere that contains all the revoked certificates?

  • 9
    The cert can't have an invalid bit in it because it is already signed and distributed. There's a blacklist called CRL and a webservice called OCSP. in reality, cert revocation is poorly implemented Jun 23, 2016 at 18:15

5 Answers 5


The answer by user2320464 is good, but I'd like to expand more.

Summary: The certificate holder generally does not manage their own revocation information, because the whole point of revocation is to announce that holder of this certificate is not trustworthy. The rightful owner of the cert needs to be able to declare the cert Revoked, but in a way that an attacker who also has the private key can't "undo" the revocation. If the owner of the cert themself are no longer trustworthy, you need a way to revoke the cert even against their will.

The best solution we've found is for a 3rd party to track the revocation info, usually the CA that issued the cert. They maintain blacklists, and can also respond to online requests for "is cert #28277392 revoked?".

Why revocation is ugly

Revocation really is the ugly duckling in the certificate world; we haven't yet found an elegant way to handle it. The reason it's hard is that there are seemingly conflicting requirements:

  1. When a server hands their cert to a client, the client should be able to tell if the cert is revoked.

  2. The server shouldn't be responsible for generating or passing on revocation information for its own cert. That's like asking the dog to go check if the cookies are still there, and not lie about it.

  3. So the CA needs to be dynamically generating revocation info for each cert. (or at least tracking it and publishing the black list hourly or daily).

  4. One of the beauties of certificates is that they contain all the data to validate the signature, which you can do offline and very fast.

  5. But revocation has to be real-time, you can't just put it in the initial cert and forget about it, because you never know at what point it will be revoked.

  6. If the client has to contact the CA directly for every cert validation then it's impossible to validate a cert offline, and you add network lag.

There are two main revocation mechanisms in use today: CRL and OCSP (see below), but neither are really elegant solutions.

Why certificates get revoked

Your comment

Does the client/server "mark" it as revoked?

leads me to believe that you don't fully understand why a certificate would get revoked. There are typically three broad reasons for revoking a cert:

  1. The rightful owner of the cert is abusing it. Typically this would be a sub-CA who is issuing certificates they shouldn't. Their cert gets revoked to tell the world not to trust them anymore.

  2. The server is decommissioned, or the cert is no longer needed for whatever reason.

  3. Key compromise of the private key corresponding to the certificate. We can no longer trust anything signed by, or encrypted for this cert because we no longer know if we're talking to the rightful owner or the hacker.

In case 2) the owner of the cert could flag their own cert for revocation in the way you're suggesting, but in the other two cases the attacker could just use an older version of the cert from before it was revoked. So revocation really needs to be handled by a 3rd party, out of the control of the cert holder. Usually it's done by the CA that issued the certs.

To revoke a cert, you typically contact the CA, prove you are who you say you are, and request them to revoke the cert. I think it depends from CA to CA what level of proof they need before they will revoke a cert for you - this is to prevent an attacker from requesting a cert be revoked as a denial-of-service. For end-user certs like a server cert, often revocation is automated and signing the network message with the cert's private key is good enough (ie a cert can revoke itself). For revoking high-value certs like a sub-CA, there is a lot of IT work and cleanup to be done, end-user certs to be migrated and re-issued, fines to be paid, etc, so a revocation will be a major incident involving many people from both companies.

How certificates get revoked

is there a blacklist of certificates maintained somewhere that contains all the revoked certificates?

Yes. The simplest mechanism is called a Certificate Revocation List (CRL) which is exactly what you expect: a list of the serial numbers of all revoked certs. Each CA is responsible for tracking the revocation status of all certs that it has issued and publishing a new CRL hourly or daily. The CRL is signed by the CA key, so it is tamper-proof. It's just a .crl file that you can download, pass around, wtv. This can be used semi-offline, as long as you connect and refresh it once every 24 hours, you can use it offline (but of course, you have no way to know if you're talking to a compromised cert until your next CRL refresh).

The more complex "cloud-friendly" mechanism is called Online Certificate Status Protocol (OCSP). The client opens a connection directly to the CA and asks

Client: "Hey, I've got cert #9388038829188 that you issued, is it still good?"

CA: "Yup, it's still good".

This solves the delay problem with CRLs, but requires the client to be online, and adds network lag to the crypto process.

In 2011 a system called OCSP Stapling was introduced that allows the sever to pre-fetch the OCSP response from the CA, say once every 5 minutes, and bundle it with the cert when handing it to the client. This, among other things, speeds up the client's crypto to validate the certificate because it has a local copy of everything it needs, no new network connections needed. This is considered an elegant solution for TLS (ie https, ftps, ssh, vpn, etc) where you are opening a connection to a server that has internet access, but it does not solve revocation for non-TLS uses of certificates, like logging into Windows with a PKI smartcard, launching code-signed software (like any mobile app), opening a signed PDF document, etc which I would like to still work even if I'm not connected to the internet.

How it gets passed to the end user

is there a field on the certificate that tells that it is revoked?

Yes, in an X.509 certificate (like SSL) the address where you can find the CRL goes in the CRL Distribution Point field, and the OCSP address goes in the Authority Information Access field. For example, the cert for *.stackexchange.com that is protecting this page contains:

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
[2]CRL Distribution Point
     Distribution Point Name:
          Full Name:

[1]Authority Info Access
     Access Method=On-line Certificate Status Protocol (
     Alternative Name:
  • Requirement 2 could be relaxed if we had mandatory OCSP stapling (no staple -> hard fail), but there would be backwards compatibility issues.
    – Kevin
    Jun 23, 2016 at 20:21
  • 1
    @Kevin Great point about OCSP stapling. I was trying to figure out how to work that into this answer, but couldn't figure out how to make it fit. Servers can also bundle a cached version of the CRL with their cert for the same effect. Jun 23, 2016 at 20:27
  • 1
    @Kevin There are also interesting denial-of-service attacks that crop up once you start requiring (no revocation info -> hard fail). You can do it, but it has to be well thought-out. Jun 23, 2016 at 20:29
  • A bloom filter would make the networking requirement rare, but you'd still need the ability. Jun 23, 2016 at 22:33
  • 2
    @Zaibis A certificate basically says "trust me, this website is supposed to be on the server that hosts this certificate". Revoking a certificate says "this server is no longer qualified to hold this website". So if a server were to maintain their own certificate revocation, they could just ignore that. The metaphor is not about making the dog guard the cookies to make sure nobody eats them, but about asking the dog whether somebody ate the cookies (revoked the certificate) and trusting the dog to not lie about eating the cookies.
    – Nzall
    Jun 24, 2016 at 13:49

Typically certificates are revoked by the person being issued the certificate. So if you were to purchase an SSL certificate and later found the private key was compromised, then you would revoke the certificate. This action would be recorded on the "Issuing CA" where the serial number of the newly revoked certificate would appear in the Certificate Revocation List (CRL) or served via Online Certificate Status Protocol (OCSP). Both of which are managed by the issuing CA though both don't have to be used. The CRL and OCSP locations are published within the certificate. In theory this is great, the problem is that not all clients check revocation lists as diligently as they should.


Since there is no way to cryptographically invalidate a certificate, a system must be used to publicly announce the revocation of a certificate. The Online Certificate Status Protocol (OCSP) is the current way of doing this. Browsers can check an OCSP provider to confirm that a certificate is not revoked before connecting to a website.


It is the responsibility of the person who bought the certificates to ensure the security of the cert.

It is the responsibility of the CA to revoke any certificates that were sighted breaching the terms of service.

A certificate is a lot like a driver's license. If someone steals it, you have to report it.


The website operator is responsible for notifying the CA to revoke the certificate, and would usually reissue a new Certificate at the same time.

The CA is then responsible for publishing this information through CRL and/or OCSP.

The client application is responsible in fetching the CRL/OCSP status of a Certificate from the CA.

In some rare cases, the CA may unilaterally revoke a certificate. This might happen, for example, if the CA believes the certificate holder is breaching the certificate's term of use or if the CA detects internal breaches or the CA believes the certificate has been issued and/or used fraudulently. The circumstances that a CA may revoke certificates are disclosed in the CA's Certificate Practice Statement, which the CA must publish publicly as part of their inclusion requirement in browsers' default authority list.

You must log in to answer this question.

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