Then answer these questions:
Well … browsers can generate ECDSA/RSA keys … and sign JWS requests … and talk directly to acme-v02 via CORS XHR requests. Put those pieces together.
Those websites did not keep ACME registration client-side just for the fun of it. Obviously their websites would be way simpler if they avoided doing that, and it would have been a grave security flaw.
Edit: now that my memory has started to come back to me, it’s possible that sslforfree, while it did client-side generation of the account key, it may still have been doing unsafe things. I don’t think there’s a way to check anymore.
Can’t we just all agree letting the website generate the account private key serverside is a bad idea security wise?
1 Like
Day 1: I generate a certificate for a domain I control using my own LE account.
Day 5: I sell and transfer the domain.
Day 10: I generate a new certificate for a domain I no longer control due to caching.
How is that not a GLARING security hole?
Not really because there's ZERO authentication process involved in creating the account in the first place.
But the authorizations we’re mentioning here are coupled to the account which was used. So yes, indirectly there are authentication processes involved after the authorization has succeeded.
And what stops them from transferring those keys to their server? Nothing. Hence, no greater security. If you control the client-side coding handling keys, the user controls nothing. Only if those keys are explicitly kept from the coder by architecture do you have security.
For example, I write a random bash/php/whatever client (virus) and have you install it on your server to automate renewals including (laugh here) generating private keys for "automated" renewals. Now your "client" can do whatever it wishes with said private keys (including account keys). Hence the reason why many people don't trust these homebrew clients even if they're open source. I know I don't have the time or inclination to read through the client code to ensure its benevolence nor am I going to police its activity. There's no way the untechnical would even get that far.
The same goes for private keys for the CSR/certificate. Therefore, all webbased certificate generators are a potential security flaw, unless you check all the client side code every time you use the site. And therefore (among others) Let’s Encrypt doesn’t recommend them.
1 Like
Yes, which is precisely why web clients are banned, because there is no way to verify that a website won't start secretly exfiltrating ACME account private keys.
I'm not sure what you mean by authentication, but as @Osiris mentioned, the ability to use the cached authorizations is cryptographically bound to your ACME account private key. Which is why it must be kept private.
You are right, but the problem can be generalized to: you own a certificate, you sell and transfer the domain, but the certificate is still valid for the original owner. No re-issuance required for this to be a problem.
There are controls in place (such as revocation requests and certificate transparency monitoring) for that. Possibly others, I don't know much about that scenario.
I think you're misunderstanding the situation. The private key associated with the CSR never leaves the server on which it was generated when all that is needed to get the certificate is the CSR containing only the PUBLIC key. A web client (or any client for that matter) should NEVER have access to the private keys for certificates. For the (unsecured) "account" that's debatable.
Well, there are clients out there which are generating private keys for the CSR clientside.
Keep in mind that it is my account to which the domain is bound after the sale. I still have the cached authorization.
Yes, that's a known issue.
My reading skills lack today. Serverside is bad. Clientside is fine. So long as the Serverside code (or JS) can't access the keys.
And the same goes for account keys…
Account keys are harmless after transactions are completed for issuance because you can no longer interfere with the issuance process. The caching of authorization is a problem. The lack of authenticating anything to create an account is also a problem.
Is it not a bit presumptuous to show up to an ecosystem, create an integration, discover a problem with the way you use the protocol, and then exclaim, “Oh my god, the ecosystem has a security flaw that only affects my integration!”?
FWIW shortly after apilayer killed ZeroSSL I also created a web-based ACME client for tools.letsdebug.net, but decided not to publish it, because I see that it only encourages people to use manual workflows and not to move on mentally. But the reason I bring it up is that the ACME account registration bit does not have to be inconvenient to the user. All you have to do is generate the account key in the background and store it in localStorage or whatever.
2 Likes
But in the eye of cached authorizations, this would require the user to check all lines of client side code. Just like a in-browser client side generated private key would be frowned upon, as the private key might be sneakily transfered to Heidi.
2 Likes
Yeah, you may not like it, but https://gethttpsforfree.com is what peak performance looks like. 
.
Two more things that may help you:
- You can optionally deactivate authorizations after you have completed certificate issuance, so they cannot be reused. https://tools.ietf.org/html/rfc8555#section-7.5.2. But of course, there’s no reason to trust a server-side ACME client will actually do this.
- If your client ever gets popular, you are stuck with 300 orders/3 hours due to rate limits per account. I think that is the main reason sslforfree did client-side ACME account registration.
2 Likes
Agreed! 
I modeled my own client after it.
Back later. Running now...