Security risk of using single account

Unless I don't understand the ACME spec well enough, the documentation doesn't mention a security risk when using a single account in a scenario where multiple untrusted users are able to request certificates with the same account.

From what I understand, authorizations are account-bound. If the challenge for a domain succeeds, the account that requested the authorization is able to manage the certificate for 30 days.

Integration Guide - Let's Encrypt says:

In ACME, it’s possible to create one account and use it for all authorizations and issuances, or create one account per customer. [...] for most larger hosting providers we recommend using a single account and guarding the corresponding account key well.

If customer A of company A (which uses a single account) requests an SSL certificate with the domain example.com, company A is able to manage the certificate for example.com. When customer A moves away example.com and deletes the certificate at company A, customer B of company A is able to create it. Even though example.com was moved away, and therefore the challenge would fail now, customer B would be able to request a certificate for example.com, as the authorization is cached for the account of company A.

1 Like

To have common grounds for understanding, we need to clarify the term subscriber, because I think that where the confusion is coming from.

Let's Encrypt defines a subscriber. The CP defines a subscriber as "a natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use". This definition implies a single subscriber, so Let's Encrypt really doesn't differentiate between a "customer of a company" and "the company".

I'm not sure if I understand this correctly. My understanding of this is as follows:

  • Initially, company A is the subscriber of a certain certificate. The domain might be owned by a different entity, but company A is still the subscriber.
  • At some point in time, the domain owner moves away from the company.
  • Company A still remains the subscriber of the current certificate, and can potentially issue new certificates due to cached valiations.

This is a generic issue of ownership transfer and applies everywhere where domain (control) is transferred. This is not really related with whether company A uses a single account, or uses multiple ones. If the company is, or was, the subscriber of a valid certificate in the past, it will always be able to issue a new certificate within validation limits.

Imagine a system where the subscriber rotates between a fixed number of accounts: Sure, it may now happen that a new certificate request is not done using the same account, but that's effectively random. Using this system does not add security in any way.

I believe the system you imagine is where a hosting company uses a distinct ACME account for each customer, and opens and closes this as customers come and go. Besides being difficult to implement, it plays horribly with rate limits and is in general just not practical. Yes, if implemented correctly this does not allow caching of authorizations across customers, but it really is no protection: The hosting company has the power to use its accounts however it likes.

What I want to say is that the risk mentioned here applies to each scenario where ownership is moved, independent of how many accounts are used - this is not a single account risk. The ownership problem is one of the reasons why Let's Encrypt uses so short certificate and validation lifetimes, because that helps mitigating this somewhat.

Domain owners who really require protection against this need to revoke certificates whenever transferring control between entities - there's no other way.

4 Likes

The risk is mitigated if company A creates and uses a single ACME account per customer. When customer B requests example.com, the challenge will be done again, and fail, as the account of customer B does not have a cached authorization.

However, this is not my point. My point is that this risk is not mentioned on the Let's Encrypt website, and I think it should be.

1 Like

I agree. I think the key thing here to read is the "Who is the Subscriber?" section of the integration guide. The subscriber is the entity with control over the private key. It's not clear to me in your examples whether the customers have the private key themselves (in which case, yes, each customer should have their own account since they're each a separate subscriber), or if the hosting company is just managing all the keys (in which case they can just use one account, and if customer A moves away then the hosting company's system still shouldn't allow customer B to request a certificate for customer A's domain names)

5 Likes

and if customer A moves away then the hosting company's system still shouldn't allow customer B to request a certificate for customer A's domain names

Exactly, so perhaps Integration Guide - Let's Encrypt should mention this risk in order to allow them to make that choice...

1 Like

There is no Customer A or B in ACME, there is only the hosting provider and their system (which references their ACME account). If a bug/deficiency in their system allows arbitrary domains to be added and certificates acquired then that's just a bug in their implementation, not an ACME risk/failure. So to mitigate that they would check the host name they are about to request a cert for is in fact hosted by them.

I could develop a system that inadvertently lets you use my AWS credentials to create VMs that cost $9000 a minute. This would be a bug in my implementation, not in AWS.

6 Likes

There is no bug in any system here. In this example, customer B has removed their SSL certificate. There is no longer an object with a unique constraint for the domain. So, it is able to be requested by any other customer of company A. The possible mitigations would be to use either 1) a separate ACME account per customer, or 2) use soft deletes to disallow customers to request an SSL certificate for the domain, even after its deletion. To allow companies to make that decision, I think this consideration should be mentioned in the integration guide. The integration guide provides a broad context that is not specific to ACME. Therefore, the fact that this risk is not inherently caused by the ACME protocol is irrelevant for my case.

2 Likes

For a shared hosting platform where users have access to their SSL certificate private keys, I chose a design where every tenant has their own ACME account. I feel too uncomfortable having a single account in that case. Even if you carefully deactivate authorizations and keep checking domain control, it just feels too hard to secure against some kind of crazy race condition where one tenant could snipe certificate authorization from another tenant and run off with a valid certificate and private key.

That's been going since late 2015. The one problem I've encountered with creating separate accounts is when users are added in bulk, like hundreds or thousands at once. Rate limit on account creation is an issue but the system just keeps trying until it's done.

On the other hand, if you do not disclose the certificate private key to your tenants - you just use the certificate without letting them download it - I think the risk is more palatable. Possibly your system can still get tricked into issuing an unauthorized certificate, but the fallout is limited: the private key to the unauthorized certificate never leaves your control. Hopefully your system has some validation to prevent domains being rebound to other accounts without a verification process, so the unauthorized certificate won't be used at all.

9 Likes

Sure, sorry that's my misunderstanding, your opening sentence mentioned the ACME spec but of course your talking about integration guidance which is separate.

5 Likes

This concern is better stated as "Security Considerations that may arise from Cached Validations". There is a bit of a discussion on this in Questions re: Upcoming changes to revocation reasons

From a security standpoint, this concern is not eliminated by simply using a different account for each "customer" of an infrastructure provider – as the infrastructure provider either controlled the account key by proxy, or had access to it within their infrastructure. The account would need to be terminated, which should place the account key on the blocklist and thereby prevent cached validations from being reused by the infrastructure provider.

6 Likes

How does Customer B request a cert for example.com? Is Company A just blindly forwarding all certificate requests its customers make to an ACME server? This is not how most hosting providers operate -- they make ACME requests on behalf of their customers for the domains that they're providing hosting for, not for any random domain.

And suppose that Company A does use separate Subscriber accounts. What's to prevent them from writing a bug and accidentally using a separate Subscriber account per domain instead of per customer? Then when Customer B requests a cert for example.com, they accidentally re-use the old Subscriber account which had previously been doing work for Customer A, and the cert gets issued.

The point here is that this security risk is not inherent to the "Company A uses a single Subscriber account for all of their customers" scenario. There are many ways in which it can arise. Rather, it is inherent to Validation Re-use.

The Baseline Requirements place limits on the re-use of validation data in Section 4.2.1: "any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate", and of course place limits on the lifetime of a certificate (also 398 days) in order to limit the damage that can be done. Let's Encrypt limits validation data re-use (30 days) and certificate lifetimes (90 days) even further.

And of course, Let's Encrypt allows anyone to revoke a certificate if they have proven control over all domain names in that certificate. So Customer A can simply set up their new hosting, get their own cert for example.com issued, and then revoke any other certs still held by Company A's subscriber account(s).

7 Likes

I'm shocked to hear that is happening.
Where does that happen?

2 Likes

How does Customer B request a cert for example.com? Is Company A just blindly forwarding all certificate requests its customers make to an ACME server? This is not how most hosting providers operate -- they make ACME requests on behalf of their customers for the domains that they're providing hosting for, not for any random domain.

If your point is that customer B is able to request a certificate for the literal domain example.com: example.com is an example domain.

If your point is that customer B is able to request a certificate for a 'random domain': it is not said anywhere that the domain is random.

And suppose that Company A does use separate Subscriber accounts. What's to prevent them from writing a bug and accidentally using a separate Subscriber account per domain instead of per customer? Then when Customer B requests a cert for example.com, they accidentally re-use the old Subscriber account which had previously been doing work for Customer A, and the cert gets issued.

I think the chance that the wrong account is used is small.

And of course, Let's Encrypt allows anyone to revoke a certificate if they have proven control over all domain names in that certificate. So Customer A can simply set up their new hosting, get their own cert for example.com issued, and then revoke any other certs still held by Company A's subscriber account(s).

What prevents customer A from deleting and revoking the certificate, and customer B re-creating and requesting it?

I'm shocked to hear that is happening.
Where does that happen?

As far as I can see, I did not state anywhere that this happens in the real world. I merely pointed out a hypothetical risk.

Heh, neither, sorry for the miscommunication. My question was "how is Customer B able to get the hosting provider to request a certificate for a domain that the hosting provider is not hosting for them?".

5 Likes

My question was "how is Customer B able to get the hosting provider to request a certificate for a domain that the hosting provider is not hosting for them?".

Customer A will have moved away example.com from company A's system, so it is free for creation by customer B. The validation for example.com is cached for company A's account, which is used by both customers A and B. Therefore, the account that is used for the request by customer B is still authorized, even though the domain was moved away by customer A.

Sorry, we appear to be talking past each other. If Customer A has moved example.com away from Company A's system, how can Customer B do anything with example.com? If Customer A actually took example.com with them to some other hosting provider, then Company A should refuse to do anything with regards to that domain name -- they are no longer its hosting provider. Customer B should not be able to ask Company A to get a certificate for a domain that Company A is no longer hosting.

The second half of this sentence does not follow from the first -- if Customer A has moved example.com away from Company A's system, then (again, assuming the hosting provider hasn't written a variety of bugs) it is not free for creation by anyone, including Customer B.

3 Likes

To recap what I think you're saying: Company A should not allow Customer B to create example.com after Customer A moved it away.

... Exactly. So, to make sure Company A is aware of that, I think this consideration should be mentioned in the integration guide.

Many default solutions (such as web control panels) do not. If I get a publicly available list of domains that were moved away from some hosting provider, get a hosting package there, and request a certificate for one of those domains, I'll have a certificate -and be able to get the private key- for Customer A's domain. If such hosting providers were aware of this risk, I'm sure they would safeguard against this.

In this situation, you would have a Certificate and a Private Key for the other person's domain, but:

  • It is not the same Private Key the other customer uses for their domain
  • There should-be no internet services pointing the domain to your system

I think the disconnect here is that @aarongable is recognizing the theoretical security implications of the situation you bring up, but they are underscoring the practical aspects and implementations of this situation that render concerns negligible.

It is extremely unlikely this situation could lead to an actual security compromise, and the timeframes that LetsEncrypt utilize are considerably shorter than industry requirements/standards.

3 Likes

I'm not sure I agree that the concerns are negligible. You rightly say "There should-be no internet services pointing the domain to your system", but having a trusted certificate would greatly simplify a MITM attack.