WebCrypto and the LE Subscriber Agreement

Speaking of highly questionable...


This site:

most likely violates the subscriber agreement as it is a remote website ACME client that:

  • appears to control the ACME account private key for the certificates it generates
  • does not accept CSRs and thus is generating the private keys for the certificates it generates

It appears that this site conducts all of ACME interactions using client-side JS, in the subscriber's browser, using the WebCrypto standard. The subscriber gets their own subscriber keypair generated locally on their own machine, creates their own account, creates their own certificate keypair locally on their own machine, gets a certificate issued, and then exports all of those objects from their local JS to their disk. As such, it is very similar to running this same client code in node, or even to running certbot: everything happens locally, and you just have to trust (or audit!) that the client isn't exfiltrating your data elsewhere.

As such, I do not believe that this site is in violation of the subscriber agreement. All subscribers who use this client are in control of their key materials at all times.

That said, we do like to discourage clients that cannot be automated, as that defeats a large part of the purpose of Let's Encrypt: making SSL set-and-forget-easy.


It looks like everything is being done in the browser via javascript to me.

1 Like

Thanks for auditing here! I probably should not have made the assumption I did, but at 3AM I wasn't about to go digging.

Does it reimport the ACME account private key for subsequent runs or create a new one every time?

It sticks it into Window.localStorage. All the normal caveats about browser storage then apply.

1 Like

Thanks for that. :slightly_smiling_face:

Only this remains then:

Unless someone is browsing from the machine where they intend to use the certificate, aside from the manual challenge satisfaction, there still remains the need to securely transfer the certificate (and more importantly its private key) to the machine where the certificate will be used. While not insurmountable by any means, these challenges make this solution less than desirable.

From the UX itself and the implementation detail of needing to manually do this for renewals, this solution is far from desirable.

The people using these types of tools haves typically been shared hosting users, who need to copy/paste a certificate into a control panel. Hopefully that is secured by SSL. If it's not, this is still better than plain old HTTP, which is the likely alternative.

1 Like

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