I take it you've read the source code of Apache and Nginx then and confirmed that they aren't doing anything malicious as well? :)
In any practical security system you are always going to have to trust that certain components are doing what they say they're doing. Fortunately, Let's Encrypt is from a reputable group, and sponsored by organizations with good reputations (Mozilla, EFF, etc.), which is about as good as you can hope for.
Many people draw a line between one time trust and continuous trust. If this thing can update the certs on my server whenever it likes, that's substantially more trust than permitting it to install a cert exactly once. If, for example, it has a bug that permits a malicious upstream to overwrite arbitrary files, the window of vulnerability expands from "the CA is pwned this instant" to "the CA will at any future time ever be pwned".
Easy fix: Run the tool as its own user, give write permission to cert & key files to that user. If you're really paranoid, run it in a jail that only has access to those files. No different than proper security for any other system process.
Yes, I need to trust some things. But I can limit the amount of trust I need to have by limiting the number of things to run. I can add a reminder to my calendar to say "hey renew your certs", or better yet I can add a check to my existing monitoring service to look at expiration dates. Why run a whole new persistent service just for this?
There won't be any sort of requirement to allow our tools to run automatically. But the existing track record of expiring certs suggest that some people are having trouble remembering to do the renewals manually, so it may be useful to have a tool that does it automatically for people who want that.
The vast majority of sites fall into the category of "encryption would be nice, but not worth the time." All of my hobby sites (various forums, a site for my choir, etc.) fall into that category. Automagic TLS done right is an improvement from no TLS, IMHO, even if it comes with its own new set of potential attack vectors.
I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write everything from scratch yourself.
Bear in mind that this is all vaporware. The github repository for "AJAX" just has a spec, no code. They're selling a security "solution" no one has evaluated yet.
I'm bothered that this runs periodically. Will it auto-update code? How secure is the auto-update process? Who can run an auto-update? Does it run as root? If so, why?
If it was a one-time manual run, that wouldn't be so bad. You can snapshot a system, run it, and see what it changed. When it gets to run on its own, that's harder to test.
I think they have stated that they want to get official packages into distro repositories, so you'd get whatever security your distribution's package manager provides, and your distribution of choice would act as a kind of gatekeeper against malicious code/updates the same way it does for other packages.
That is exactly correct. And the client will be open source code written in Python.
It's not like "take this binary blob from us and run it as root on your machine", it's like "we have an open source project that would like to work with your upstream OS distributor on exactly the same terms as, and in exactly the same way as, the other tools that you're using on your server".
Edit: If you want to follow along with, audit, contribute to, help package, etc., our preview client, it is available at
We will also welcome people to create their own interoperable software, so if you don't want to run our client or any of its dependencies, or if it doesn't work well with your serving environment, you can create your own alternative. (Hosting providers or CDNs that want certs for sites they host, for example, could create their own tools to deploy them, instead of using our tools.)
It's a balance, at the end of the day. I won't be auto-updating on my server because it's not hard for me to do that myself. But if someone is just running a site where HTTPS isn't particularly important (a personal blog, say) then the convenience might outweigh the very slight security concern - better they are using HTTPS at all, if the alternative to convenience is HTTP.
You're probably already doing something similar if you use OCSP stapling.
It needs to run continously for revocation purposes but you don't notice because it's integrated in your web server. This could be done in the same way.
Or, all you have to do is let this new piece of software run periodically on your secure server. What could possibly go wrong?