> Let's Encrypt only issue certificates that are valid for 90 days[0] because they want you to automate renewal by having your server automatically run their script which needs root privileges
That script is FOSS; you can see exactly what it wants to do. And it uses a documented protocol ("ACME"), so you can write and run your own script if you want, using several different ways to prove you control the server. The script provided by Let's Encrypt mostly serves as a proof of concept and a simple implementation for some common cases; various alternatives already exist that integrate will with various server software.
> and they use Google as the gatekeeper of who is allowed a certificate[1].
I've never once seen a report of a site finding itself on that list without actually serving malware; I don't see any obvious basis for such a complaint.
> doesn't pass every request to a corporation for approval.
Let's Encrypt is run by "Internet Security Research Group (ISRG)"; quoting https://letsencrypt.org/isrg/ : "ISRG is a California public benefit corporation". And personally, since I don't particularly want to see any trusted CA run by only one person, just about any CA will be a corporation of some kind. "corporation" is not a dirty word.
> That script is FOSS; you can see exactly what it wants to do.
Any method of automatically renewing certificates, regardless of what script it used, is going to require the privileges needed to alter the certificate file. The only way to not run it as root would mean the certificate is editable by a non-root user. I don't want any script, no matter how open or free or vetted, to have the ability to alter the certificate on the server.
> I've never once seen a report of a site finding itself on that list without actually serving malware; I don't see any obvious basis for such a complaint.
It should not up to Google to decide if I get to secure my site or not, nor should Google be being informed every time I obtain or renew a certificate.
> "corporation" is not a dirty word.
Third-party corporation is what I meant. If I have decided to get a certificate from Let's Encrypt (or any other CA) that should be between me and them, Google, or any other third-party, shouldn't have anything to do with it.
> nor should Google be being informed every time I obtain or renew a certificate.
Let's Encrypt actually log all certificates they issue to a number of public logs, including those operated by Google. See the "Certificate Transparency" section of their site which explains this, and provides a link to a tool where you can examine all such certificates: https://letsencrypt.org/certificates/
> I don't want any script, no matter how open or free or vetted, to have the ability to alter the certificate on the server.
You don't have to run it in an automated fashion if you don't want to. You could run it unprivileged, generate a certificate manually, vet it however you wish, and install it.
Also, given that you can generate the certificate yourself, you can generate one that keeps the same private key, and keep that key unaccessible to anything but the web server (or other server software). You could have the unprivileged script only update the public side of the certificate chain.
> nor should Google be being informed every time I obtain or renew a certificate.
Unless Let's Encrypt has implemented the Safe Browsing protocol very badly, they won't ask Google about every URL. The Safe Browsing protocol involves downloading blocks of hashes to check a host against, not asking the server about every individual URL. (Otherwise, it would be completely unacceptable for use in browsers, too.)
> If I have decided to get a certificate from Let's Encrypt (or any other CA) that should be between me and them, Google, or any other third-party, shouldn't have anything to do with it.
The entire CA system works via collective trust (and a great deal of duct tape and bailing wire). Obtaining a certificate that every browser trusts shouldn't occur in a vacuum.
>Any method of automatically renewing certificates, regardless of what script it used, is going to require the privileges needed to alter the certificate file. The only way to not run it as root would mean the certificate is editable by a non-root user. I don't want any script, no matter how open or free or vetted, to have the ability to alter the certificate on the server.
The validation process can be customized or even carried out manually if you so insist. After all only requires a particular token to be available from a particular path under the domain to be signed, just drop the path to your token into your apache/nginx/god-forbid-IIS config file and you are good to go.
The automated scripts was provided to make it easier for non-admin types of deploy; that said allowing these people to manage their own server sounds like a bad idea from the get-go.
That script is FOSS; you can see exactly what it wants to do. And it uses a documented protocol ("ACME"), so you can write and run your own script if you want, using several different ways to prove you control the server. The script provided by Let's Encrypt mostly serves as a proof of concept and a simple implementation for some common cases; various alternatives already exist that integrate will with various server software.
> and they use Google as the gatekeeper of who is allowed a certificate[1].
> [1] https://letsencrypt.org/2015/10/29/phishing-and-malware.html
I've never once seen a report of a site finding itself on that list without actually serving malware; I don't see any obvious basis for such a complaint.
> doesn't pass every request to a corporation for approval.
Let's Encrypt is run by "Internet Security Research Group (ISRG)"; quoting https://letsencrypt.org/isrg/ : "ISRG is a California public benefit corporation". And personally, since I don't particularly want to see any trusted CA run by only one person, just about any CA will be a corporation of some kind. "corporation" is not a dirty word.