How to check revocation status of certificate?


#1

I am developing an ACME client in Go and using Pebble for testing.

I have successfully created accounts, placed orders, downloaded signed certificates.

I am working on revoking certificates, … but this leads to my question:

How do you check the revocation status of a certificate?

Reviewing the code in the Pebble web-front-end, I don’t see any endpoints that are obviously related to checking the revocation status of a certificate.

Reviewing the ACME v2 draft standard, … there also seems to be no description for how a client is expected to check the revocation status of a certificate.

Any help would be appreciated.


#2

Hi,

The revocation status is checked via OCSP (as defined in the certificate)…

You could perform a OCSP check with OpenSSL…
https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html

However… I’m not entirely sure if there’s another way to check the certificate status at client software… (Certbot did check certificate status via OCSP.
thanks to @mnordhoff)

Thank you


#3

certbot certificates” checks if certificates are revoked by using OCSP.


#4

Thanks. Corrected.

   


#5

I’m not sure if revocation testing is even possible within Pebble:

Perhaps @jsha or @cpu can tell more about this?


#6

Parallel discussion: https://github.com/letsencrypt/pebble/issues/177


#7

That’s not completely true anymore: Pebble keeps track of revoked certificates to be able to report urn:ietf:params:acme:error:alreadyRevoked. (That was implemented in https://github.com/letsencrypt/pebble/pull/157)

There’s no CRL or OCSP responder one can use, though.


#8

Since the main purpose of Pebble is testing, and since Pebble already keeps track of revoked certificates, it would be useful if Pebble had a simple endpoint that reports the status of a certificate. It makes sense for Pebble to do this, since there is no other way (since there is no CRL or OCSP).

The certificate could be identified by its hash (SHA256) and the response would be “valid”, “revoked”, or “unknown” (for certificates not found in Pebble’s internal database).

I don’t think this would involve much extra code in Pebble, and it would be valuable for unit testing a client, since it would become possible to check whether a certificate had been properly revoked.

What do you think?


#9

Does it though? What purpose would there really be for an API endpoint that will only ever exist in Pebble? Pebble’s purpose is to be a testing endpoint for general ACME client code. So why would an ACME client add an explicit code path to check cert revocation from an endpoint that will never exist in production? It adds complexity to both client code and Pebble code.

I think it makes more sense to stick to the existing standards for checking revocation. Query the cert details for the AIA extension and follow wherever it points to. If there is no AIA extension or no CRL/OCSP endpoint in it, the cert can’t be revoked regardless of what Pebble thinks internally. So the correct response to “Is this cert revoked?” would be “No.” Right?


#10

Yes, you make a good point.


#11

Some sort of CRL/OCSP implementation in Pebble would thus be helpful, correct?


#12

You mean modifying Pebble to both add CRL/OCSP info to the generated certs and host a standard CRL/OCSP endpoint to check them against?

I dunno. I can see how it might be convenient. But I also feel like it’s kind of outside the scope of the ACME protocol and thus outside the scope of Pebble. If I were writing a client and wanted to report on revocation, I’d probably just test against the Staging server that already includes proper revocation info.


#13

I had success revoking a certificate by signing the request with the account private key.

In addition, when I try to revoke the same certificate twice, I get an error, as expected.

“urn:ietf:params:acme:error:alreadyRevoked”: Certificate has already been revoked.

This “revoke twice” seems good enough for testing. I agree that implementing OCSP in Pebble might not be worth the effort.

It is making sense to move on to testing a new ACME client with Boulder (or the staging server) to be able to revoke and then check certificate status through OCSP.


#14

This is a cool idea! I think either this or a simple OCSP service would be reasonable additions to pebble. Would you like to write a PR?


#15

I vote we consolidate this discussion on https://github.com/letsencrypt/pebble/issues/177 - I don’t think there’s any advantage to hashing this out in both the forum and Github.

I’m going to close this thread so we can reduce the duplication of effort. Thanks folks!


#16