Using manual with the own account key isn't good. But it's possible.
Using manual with an unknown account key of an unknown "third party" is always wrong. The user creates one certificate. Then that unknown "third party" is able to create additional certificates with the same domain name in the next 30 days.
Using manual with such a tool and dns validation (to create a wildcard) is fatal ^ fatal.
Conclusion: All online tools which can be used without creating an own account key (private key only saved local, never send to that service) are fatal.
These are hacker tools, not helpful tools.
That's one reason Letsencrypt has removed all of these browser based online tools from
Before submitting a pull request please make sure:
...
The client is not browser-based and supports automatic renewals.
Having designed a system that operates exactly as you've proscribed, I would be very curious as to how I can generate a new certificate for a domain I don't control without control to prove ownership. Even if the rightful controller of the domain is lazy or naive in not removing the DNT TXT records, validation files, or python proof, I would only be able to create a certificate that their current domain validations would allow if the validation tokens didn't change, which they ALWAYS do after certificate issuance. Even failing a validation challenge results in the token changing for that validation with the old token being worthless. I've tested this myself HUNDREDS of times. I'm sorry my friend, but I see NO foundation for your fear from a security standpoint.
From my analysis from a security standpoint, the account key signature only serves the purpose of preventing interference by a man-in-the-middle during the issuance process. After the certificate is issued, the challenge tokens, where ALL of the power of abuse reside, are invalidated thus rendering any information from the session completely powerless. The constant use of nonces issued by Let's Encrypt for every exchange ensure that.
Therefore, if the scenario you've described was the reason why Let's Encrypt removed recommendation for online clients, I would highly advise Let's Encrypt to get better security analysts. I suspect that the ACTUAL reason has to do with control and data gathering. By the way, the ONLY emails I get from Let's Encrypt based on an account email regarding renewal reminders are for OTHER PEOPLE'S ACCOUNTS who have incorrectly used an email address for one of my domains, thus proving that Let's Encrypt never verifies ownership of account emails.
I don't know what your tool is doing and how it works.
Is that correct?
Users can create certificates with your tool
You control the private key of the Letsencrypt account key, not the user? The private account key is saved on your machine?
If yes, no one should use your tool.
I successfully renewed a certificate but validation didn’t happen this time - how is that possible?
Once you successfully complete the challenges for a domain, the resulting authorization is cached for your account to use again later. Cached authorizations last for 30 days from the time of validation. If the certificate you requested has all of the necessary authorizations cached then validation will not happen again until the relevant cached authorizations expire.
That's
correct and wrong. These tokens aren't longer relevant. But the accout doesn't need a re-validation the next 30 days.
They can generate a certificate for your website up to 30 days after you used their tools
2.They can revoke the certificate because they control the ACME account used to generate them
3.They can decrypt your traffic by keeping the private key they have generated for you if they are able to intercept the encrypted traffic (avoidable by generating a csr offline)
Why then do I get new challenge tokens when I try to generate a new certificate for my own website with my own account 15 minutes after generating a certificate?
You should need to prove ownership for revocation then, obviously.
Correct, IF I generate the private key associated with the public key in their CSR, which I NEVER do and cannot with the process I have. They submit their CSR, which aside from containing an (unencrypted and useless) passphrase only has public information.
I'm going to issue two certificates for my own website using my own website right now. I will paste the token values and show they change. Please explain to me how I'm able to get a certificate issued by the ACME process without revalidating my ownership. Are you saying that LE issues challenge tokens then validates without them?
No, no tokens are given to the client. See for example the following output I just generated:
server ~ # certbot certonly --staging --apache -d le-test-29.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Unable to read ssl_module file; not disabling session tickets.
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Generating 2048 bits RSA key
Performing the following challenges:
http-01 challenge for le-test-29.example.com
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/le-test-29.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/le-test-29.example.com/privkey.pem
Your cert will expire on 2020-11-07. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
server ~ # certbot certonly --staging --force-renew --apache -d le-test-29.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Unable to read ssl_module file; not disabling session tickets.
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Generating 2048 bits RSA key
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/le-test-29.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/le-test-29.example.com/privkey.pem
Your cert will expire on 2020-11-07. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
server ~ #
See the part about the challenges missing in the second run? Perhaps your client is buggy?
Anyway @JuergenAuer This is very offtopic, perhaps move all these posts to a separate thread?
Fascinating. Are you using the exact same CSR (CN and SANs)? I always get issued new challenges, otherwise I'd end up with a blank webpage with only a validate button.
Hmm. You've got me very curious now. I think I'll turn on a dump of the entire transaction process.
Just one hostname. The same, yes, as you can see by the command. And no, not the same CSR, the private key wasn't re-used as per certbot default and thus the CSR would be different.
Like I said, buggy (and unsafe for that matter) client.
Generates proper certificates with a zero failure rate. Not sure how there's a bug with that. The safety is a matter of proper security analysis and not your personal opinion. I'll dump an entire transaction log later today for an issuance. I'm really curious as to what certbot could be doing differently to create such an obvious security hole.
The problem with some web clients (I haven't tried yours so don't shoot me if it's not the case) is that you control the ACME subscriber account key. This effectively gives you the ability to issue fraudulent certificates with your own CSR, after the original user has issued a certificate with their own CSR. On the back of the initial authorization(s).
Key escrow of the ACME subscriber account key has at-least as bad security consequences as CSR key escrow.
You will notice that many ACME web clients (such as the old/purple ZeroSSL, the old sslforfree and gethttpsforfree) do not proxy the creation of the ACME account or signing of the JWS requests. This is very important, just as important as not proxying the generation of the CSR.
Since the end-user does not really have a good way to see whether keys are being escrowed, web clients should be discouraged in the general case.
This was absolutely not true for sslforfree. Not once did I ever need to sign ANYTHING. The signing process is far more technical than the average user could possibly handle. Hence the popularity of the site and the lament of its demise.
Where did the private key come from? Sure didn’t come from me, the owner of the domain being certified. How are they going to register an account for me AND sign for me without me either submitting a private key or generating one for me? Did you ever actually use sslforfree.com?
