edit: Running a CA is a full-time job that requires financial backing, gear, well-trained operational staff and a lot of policies to operate in a reasonable and safe way. I'm happy that Let's Encrypt take their time to get everything in place and do not rush General Availability, BTW. I could not find /any/ information on SPI's CA on the web. I have no idea who or how they currently operate their CA. Their Website has a horrible and real-world vulnerable HTTPS set-up. I imagine their CA might also have aged a bit.

> Between Let's Encrypt and StartCom ...

What do we have?

StartCom doesn't allow their free certificates to be used for commercial purposes and will hold you to ransom if you need to revoke it (eg. after a major vulnerability which exposes private keys).

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, and they use Google as the gatekeeper of who is allowed a certificate[1].

We are still short an option that issues certificates that are valid for 1+ years, which can be revoked at any time, can be used for any purpose and doesn't pass every request to a corporation for approval.

[0] https://letsencrypt.org/2015/11/09/why-90-days.html

[1] https://letsencrypt.org/2015/10/29/phishing-and-malware.html

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.

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.

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/

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.

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.

The provided script:

1. Is FOSS. You can audit it before running.

2. Is an example, not required. You can write your own script from scratch if you want, or even do it by hand (although this would be admittedly tedious to do every 90 days).

> and they use Google as the gatekeeper of who is allowed a certificate[1].

That's a drastic oversimplification. The Google Safe Browsing API lists phishing and malware sites. I can see some concern that Google might mark sites as phishing or malware for political reasons or something, but so far I know of no cases of that happening. In fact, high-profile sites that do contain a lot of malware have been left unmarked: see Pirate Bay, Kickass Torrents, MegaUploads. I definitely have concerns about censorship, but so far I see no evidence that's happening. If you have such evidence, I'd be very receptive to seeing it.

> We are still short an option that issues certificates that are valid for 1+ years

That's not something I want, or something that's good for the security of the internet.

> can be used for any purpose and doesn't pass every request to a corporation for approval.

As long as the limitation continues to be on malware, I'm fine with it, and I'm not sure why you aren't.

P.S. To be clear, I know very little about StartCom and am not defending or attacking them.

So StartCom's non-commercial restriction is fine, and Let's Encrypt's DFSG-compliant script is fine. (Frankly, they're not even relevant for the use case of replacing the SPI CA, because Debian can just pay for certificates. If there's somehow a problem with funding, which I don't think Debian has at this scale, I'm sure there are countless people who would be thrilled to donate some money.)

I do feel more negatively about their choice to use a third-party list of domains to blacklist, particularly since they can't offer any effective appeals process (they can't afford to have people in the loop AT ALL at a price of zero)

If your site appears on the malware list, then both Firefox and Chrome will produce giant warnings on your site that will cause almost everyone to refuse to browse there. So you'll have much bigger problems than not getting a certificate, and you will need to get yourself removed from that list anyway. (And, for that matter, figure out what got you on that list, such as running an ad script that serves malware, or having your server compromised and serving malware you don't know about.)

I looked into it when LetsEncrypt announced their plans to use Google's backlists. Here's what I found for myself, copied from there [https://community.letsencrypt.org/t/the-cas-role-in-fighting...]:

Google's Safe Browsing FAQ [https://developers.google.com/safe-browsing/safebrowsing_faq] lists three types of sites which receive advisories: Phishing, Malware, and Unwanted Software. Two of the three types provide an appeals/delisting process, but "Unwanted Software" does not. However, it may be that LE's proposed use of the Safe Browsing API is only looking at the first two types.

You probably don't want them to have your private key :)

From their FAQ:

"2.) The certificate is for my company, what shall I do?

In the Class 1 settings (free), the only possible relationship between StartCom and the subscriber is with individuals, i.e. natural persons. StartCom has no relationship with the organization a subscriber may represents and acknowledges only the subscriber. All responsibilities according to the StartCom CA Policy are that of the subscriber personally, even in case he/she decides to obtain certification as an employee or representative of an organization. Organizations should perform Class 2 validation and an organization name may only appear in a digital certificate at Class 2 level and higher." [0]

[0] http://www.startssl.com/?app=25#2

--override-expiry --days=365

perhaps.

http://news.netcraft.com/archives/2013/05/13/how-certificate...

https://www.imperialviolet.org/2011/03/18/revocation.html

https://www.imperialviolet.org/2012/02/05/crlsets.html

https://www.imperialviolet.org/2014/04/19/revchecking.html

https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

There hasn't been a lot of progress there but Certificate Transparency is of course a new player that might change how revocation works for different systems as well.