Using ACME to get a list of certificates for a CN / FQDN?

Another question for y'all...

Is it possible to use the ACME protocol to obtain a list of certificates in various states (ie: Issued, Revoked, Expired, etc..), or a specific state (ie: Issued)? When obtaining the list can it return a certificate ID or such that can be used for revocation?

I am trying to add to my script the ability for a user to request a list of certificates for a specified CN / FQDN and have it return the certificate ID. They would then review the list (could be just one certificate) and if they wish at that point issue the revocation request against that certificate ID.

Thoughts? Is this possible?

Not really. The ACME RFC specifies a way to get a list of orders for an ACME account, but there's no guarantee that the orders last the full lifetime of the certificate, it wouldn't indicate whether the certificate that the order created ended up being revoked, and Let's Encrypt specifically doesn't implement the feature at all.

In order to revoke a certificate, you really need to have the certificate itself. Maybe a client that really wants to include full certificate management could monitor CT logs or the like to help with that, but it'd really still be data that the client needs to be tracking itself.

Revoking should be really rare, and the case that it's most important for, of key compromise, you need to have the private key of the cert itself anyway (for Let's Encrypt's implementation at least). So I'm not sure that this feature you're envisioning would be all that helpful for most use cases.

3 Likes

Sounds like revocation is the ultimate goal if this feature. To be able to revoke a certificate, you'd need access to either the private key of the certificate or an ACME account that has a valid authorization for the hostname (or even all hostnames in the cert?) or the ACME account that originally issued the certificate.

So that means that in practice, this feature would simply be a feature of the ACME client, otherwise it's rather hard to revoke to begin with. (Though not impossible..) And the ACME client would have all the information you're requesting to begin with.

2 Likes

In addition to the excellent advice already given you should review the Let's Encrypt Revocation page.

Keep in mind the comments on that page about OCSP will soon be obsolete for LE

2 Likes

@petercooperjr

I forgot to mention, I am using a third-party CA w/ EAB. I did ask this inside this forum, the folks here being the most experienced with ACME.

I am familiar with REST API calls, but I was experimenting to see if this can be done with the ACME protocol, so I did not have to have the users of the script use two different set of credentials (ACME and API).

It does not seem like there is a obvious way, unless implemented by whatever ACME implementation is being used. I will go ask my CA if they support this.

THANK YOU for your help and explanation.

In addition to the above, a few things:

  • The standard way to implement this is for the ACME Client to track it's own ACME Orders. Your client should be logging the order details, which includes an "Order URL". The Order URL can be interrogated at later points for state. The Order URL is bound to the account - and if an ACME server were to provide for listing orders, that listing would be bound to the account as well.

  • It is increasingly standard for Domain Operators to monitor Certificate Transparency Logs. If you use Cloudflare, they have an option to automatically do this for you - whenever a new certificate is encountered for one of your domains, they will notify you of the certificate and it's details. (They are particularly bad about disclaiming when they had ordered that Certificate for you, which can lead to freakouts). There are other third party services that do this too.

  • I just want to stress again the advice above: revocation should be very rare.

With all that being said, it sounds like you may be trying to combine two very different and incompatibly use-cases above.

An ACME client should not be listing certificates for a security review, it should only be listing certificates that it manages. Basing any type of security review on this would be problematic, because it will only show a subset of issued certificates -- those issued against that particular account. It won't pull in orders from other accounts your organization has set up, which is common.

A tool for a security review should work off CT Logs and global datasets.

5 Likes

The ACME protocol does not provide any way to list all certificates for a given domain.

If you want a list of all certificates for a given domain, you need to instead look at Certificate Transparency Logs. That will make it possible for you to see all certificates for a given domain, even those issued by different CAs.

But as others have said, certificates should generally only be revoked when there is a true reason for that certificate to no longer be trusted.

6 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.