I had the same thought. The account management should be handled by YAAC though, right? 
3 Likes
Account management is managed by YACC, correct.
It is not issued through 1 account for every cert.
1 Like
There should be an account URL and private key lying around somewhere. The account URL is probably in some logs somewhere, at least.
3 Likes
I'm not familiar with YACC myself, but it does seem to use some kind of persistent storage using "Flysystem".
4 Likes
I hope that it's persistent. If not, tracking down the certs might require an IP search or such for the issuing server.
3 Likes
That is the thing, the data is only used to process the cert, Once a certificate is issued, we immediately remove any info associated with the account from our end.
Also, if the account isn't persistent, I highly recommend revising your code to correct this before releasing it for first-party usage. I had to do so with CertSage.
3 Likes
Oh... that's not good. 
There's no way to update expiration notification contact info and the account-route for revocation by the account holder is lost. It's not technically a violation in itself, but it limits the options quite significantly.
3 Likes
I suppose I should have guessed the design since you're asking for the requester's email address on the interface to tie to the account. If you were appending the addresses for one account, the certificate recipients would all receive expiration notices for each other's certs, which would be very confusing.
3 Likes
That just isn't true. Four of the first five hits on my search require no login and have no limits--the fifth requires a login, though registration appears to be free (and it appears two of them, like yours, are just wrappers for YAAC).
No, it isn't. If you're generating private keys server-side, as you've already said you are, it isn't implemented securely.
Why on earth would you do that, rather than use some sort of automated system?
I understand that's your intent, but this isn't something helpful. It's rather a really bad idea, as you've now been told several times. "Fill out a web form to get a Let's Encrypt" cert is a bad idea. It's strongly discouraged by anyone who knows anything about LE. That's why LE doesn't do it themselves, and it's why they don't include any such clients on their list. They don't outright block it, but they do everything they can to discourage it. But that doesn't prevent people like you from creating yet another redundant web page that does the same thing as punchsalad or sslforfree.
5 Likes
You are correct. It was done so that no data will be stored anywhere except for processing via YACC.
I will discuss and try to improve on this.
To clarify on this point for @Aitrex (and others who may come later), there's a big difference between a first-party client (one installed on a certificate user's own server) that happens to utilize a web page interface (like CertSage does) versus a third-party client (one not installed on a certificate user's own server). The dependency is upon whose server account and private keys are generated and stored. Additionally, preventing unauthorized account usage despite lacking access to private keys is also important, which is why I went to great pains to implement a password system for CertSage to prevent unauthorized usage since the interface for each user's own copy is publicly accessible over the internet. With great accessibility comes the great responsibility of securing access.
3 Likes
Yep, I'm gonna be sick...
(That's exactly to what I was referring with the acronym YAPS).
To be fair, that client claims to locally generate private keys, which is an inspectable behavior (if one actually has the skills, time, and inclination to do so).
3 Likes
I tend to think that stating an "ACME Client" might be a better description.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.