Mapping a cert back to owner ACME account

[metaclassing]

Hi, I have a large enterprise with hundreds of domains, the majority are centrally managed through one ACME client system that keeps everything in a database and centrally manages keys, DNS re-authorization, and certificate renewal. This central system has a couple acme accounts associated (one for dev/test, one for prod, one for some restricted-use domains) and handles monitoring for expirations etc.

There are a handful of ACME certs being issued outside our formal process of central management, monitoring, and renewal and I was wondering if either via the Boulder API, certificate attributes, or the transparency log it was possible for me to determine which ACME account (and maybe associated email address) was issuing those certs (there is no real good technical way for me to prevent people from doing their own HTTP-01 authorization once a DNS record is created for their app.) Alternatively, if there was a way to figure out all the certs a given ACME account has issued would be of value. I do realize for some users this may be a privacy concern, but I figured it was worth at least asking the experts.

Thanks!

[griffin]

Welcome to the Let's Encrypt Community

An interesting question to be sure. I don't have an answer myself, so I'll ask the source.

@lestaff

Any ideas here?

[petercooperjr]

I don't think you can get other account ids without having their keys. Even if you could, it wouldn't get you the contact email address or otherwise help you figure out which computer created the account.

You could, if you (where "you" is whatever central process you have) control DNS (or can otherwise validate ownership through the ACME protocol), monitor certificate transparency logs and send an ACME revoke request for any certificate your central process didn't issue. (You don't need to revoke from the original account, as you can revoke from any account that demonstrates control over the domain.) That doesn't really solve your problem directly, of course, but it makes it more likely that anybody trying to go around your process notices what you're doing and asks you what they should be doing instead. And I'm not aware of any software out-of-the-box that implements something like that.

What I think you actually want are the CAA extensions (which I believe have been approved by the various controlling bodies so it should be on the roadmap to get implemented at some point, but isn't implemented yet and I don't think there's a concrete timeline out there) that allow you to specify in the DNS CAA record restrictions not just limiting the issuer but also limiting the authentication methods (such as to just DNS-01) and also limit to a specific ACME account. (Here I'm assuming that your central process can control DNS to that degree and that the stagglers doing their own authentication don't.) But again, that's not implemented yet so it won't help you out for now.

[bruncsak]

@metaclassing

there is no real good technical way for me to prevent people from doing their own HTTP-01 authorization once a DNS record is created for their app

A proper CAA DNS record prevents issuing certificate for the given domain even via HTTP-01 authorization. When your central system goes for a new certificate you change the CAA record during the time-frame of authorization to permit issuance by Let'sencrypt's CA. However, that is just a workaround.

[metaclassing]

The CAA approach is very interesting and something to consider in the far off future. Rather than purely trying to prevent people from wandering around the process, I was curious if the Boulder API would consider accounts that "demonstrate control over the domain" (aka would have the ability to execute that revocation for example) the ability to see what other accounts and authorizations are in the system. Probably also something that doesn't exist based on comments so far, but just maybe a different perspective on utilization of the service. Thanks for the feedback.

[_az]

Well, Let's Encrypt (and ACME for that matter) don't exist in a vacuum. There are numerous ways to obtain certificates and every CA is trusted more or less equally. If there was to be an effective way to trace certificates back to a contact, it would have to include every CA.

For reasons of privacy, I don't see this happening. Between your ability to send a Certificate Problem Report or use CAA, what else do you need? I hope I'm not projecting too much, but the suggestion feels overly voyeuristic to me.

[petercooperjr]

It gets tricky, because just because somebody has authorization to use a name now doesn't necessarily mean that person should be able to find out account/email/ip/etc. of whomever had authorization to use that name a couple months ago.

I think that @bruncsak's suggestion of having an empty CAA record (whatever the syntax is for not allowing any certificates) except during times that your central process is doing its renewals (when you switch it to a Let's Encrypt only CAA record) is probably the best you're going to get. (Perhaps combined with monitoring CT logs to find if any other users issued a cert during the window that authorizations are allowed, to either revoke them as I said before or just to try and track.)

[rg305]

One account can be used to obtain certificates from a multitude of domains.
So giving you someone else's account number seems counterproductive to that security model.

Giving you full control of a domain you clearly control the DNS zone for is the right way to go.
But as mentioned that full control was only recently approved and will take some time to fully implement.
Until then, manipulating CAA is your best option for maximizing cert control.

Cheers from Miami
And have a Happy New Year!

[jple]

Correct, you can't use an ACME account ID without the corresponding private keys - and CAA is a great way to boost the security of your domain!

[petercooperjr]

Thanks! I don't suppose you have any updates on the timeline for implementing those CAA extensions that would let one limit issuance to a specific authentication method and account key?

[jvanasco]

Going beyond what everyone else said...

The only things I've seen in the ACME spec that deal with existing Certificates deal with revocation. There aren't any endpoints that list Certificates for an Account.

If you had all the Account Keys, you could try to revoke a Certificate with each Account Key - and that should tell you which Account Key obtained the Certificate*. However, that would revoke the Certificate - which is self-defeating and makes no sense.

• In this situation I think there is the opportunity for false-positives. I believe an AccountKey can prove they own a FQDN via a successful authorization, and then revoke a certificate previously issued to another account. This is explained in the last section of the revocation overview on letsencrypt.org

[rmbolger]

@jvanasco

There aren't any endpoints that list Certificates for an Account.

Not certificates specifically, but an endpoint to retrieve a list of orders is supposed to be returned among the details for an account object according to RFC8555 7.1.2. Boulder just hasn't implemented it yet (Issue #3335). Not sure if any of the other ACME CAs do either.

[jvanasco]

Oh yes, I forgot about that. Last I heard, this was not likely to be implemented in the foreseeable future - if ever.

[aarongable]

We don't have a hard timeline to give, but they are definitely something we hope to provide soon. There are other changes we'd like to make to our DNS resolver (which we use to retrieve CAA records) that may be higher priority.