Who is responsible for revoking a certificate?
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:
When a server hands their cert to a client, the client should be able to tell if the cert is revoked.
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.
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).
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.
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.
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:
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.
The server is decommissioned, or the cert is no longer needed for whatever reason.
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:
URL=http://crl3.digicert.com/sha2-ha-server-g5.crl
[2]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl4.digicert.com/sha2-ha-server-g5.crl
[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.digicert.com
URL=http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
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.