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.
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)
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.
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?
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.
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.