This has been planned for a while now. Between Let's Encrypt and StartCom, Debian and SPI don't need to run a CA anymore, especially not a CA that only Debian systems trust. Several Debian sites used to use SPI certificates, back when HTTPS seemed like an optional nicety. These days, every connection should use HTTPS, so Debian sites need to use certificates that all browsers trust, which they can easily do now.
SPI actually got an offer to cross-sign their root so that all browsers would trust it, but the consensus was that SPI didn't want to take on that risk given the availability of multiple other free CAs.
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.
With the practicality of something that only worked on Debian systems aside...
> 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.
> 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.
> 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
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.
The SPI certificate authority was never a public one. It was only used to sign Debian sites (and the majority of those have certs issued by Gandi these days; I think it's just debconf.org left).
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.)
You can run the letsencrypt client as non-root, but it takes a greater degree of system configuration first. letsencrypt-auto in its current incarnation sure does run as root, however. The current state of affairs is to prioritize ease over running with the lowest degree of privilege that is feasible. (and there are other ACME-protocol implementations you can choose if you prefer not to run the letsencrypt client; ISTR reading about one implemented in Ruby)
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)
> 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
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 agree, if Google decides to blacklist your domain you basically own a pile of bitter bitter ashes. Is there an effective appeals process if this happens?
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.
Yeah, a lot of CAs do this.
I don't like it, I'd prefer a policy that forbids that. But as long as they don't force me to use that option I'm kinda okay with it.
StartCom does allow their free (Class 1) certificates to be used for commercial purposes. They just reserve certain features that many businesses would appreciate (like having your business name on the certificate) for paid certificates (Class 2 or higher).
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]
Agreed. Not all uses of certs allow for easy automation. For example, ddwrt or a NAS. I would like to use proper certs but don't want to screw around in the firmware which might potentially break updates.
Then run the script somewhere else and copy it over? I frankly don't see the point of using a CA-signed cert for a personal device, but it should be doable without spending more than a few minutes every three months.
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.
Does anyone know of a tool for Windows and OSX that will audit all the certificates installed on a machine and tell you which ones are removed, compromised, or generally unrecognized?
Somewhat related, RedHat is working on sorting out the mess we're in regarding what certificates are shipped in various open/free software distributions and programs:
Whole text (but this is just the start of the thread, click through to read a handful of replies on the OSS-SEC list):
Announcing https://github.com/RedHatProductSecurity
/Certificates-Shipped/ From: Kurt Seifried
<kseifried () redhat com>
Date: Tue, 24 Nov 2015 21:38:35 -0700
[1] https://github.com/RedHatProductSecurity/
Certificates-Shipped/
The idea is to create a comprehensive list of
shipped certs/keys/etc by open source
vendors/distributions/projects so that:
1) we have a list of secrets maintained by
external parties that we rely upon
2) we can audit them and make sure we
should be trusting them
3) also spot changes more easily (since the
existing corpus is available)
I'm guessing there are some surprises
waiting for us.
--
Kurt Seifried -- Red Hat -- Product Security
(...)
[1] Split to avoid long unbreakable line in pre-text-box on hn:
When I was at Debconf 15 I tried looking at the schedule on my phone. It was confusing to have my Android phone complain about the debconf.org certificate, while my Debian laptop was fine with it.
https://lists.debian.org/debian-devel-changes/2015/11/msg025...
This has been planned for a while now. Between Let's Encrypt and StartCom, Debian and SPI don't need to run a CA anymore, especially not a CA that only Debian systems trust. Several Debian sites used to use SPI certificates, back when HTTPS seemed like an optional nicety. These days, every connection should use HTTPS, so Debian sites need to use certificates that all browsers trust, which they can easily do now.
SPI actually got an offer to cross-sign their root so that all browsers would trust it, but the consensus was that SPI didn't want to take on that risk given the availability of multiple other free CAs.