Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ca-certificates: removal of SPI CA

bugs.debian.org

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Ca-certificates: removal of SPI CA

#21

Post by icebraining »

newman314 wrote: post #16
neerdowell wrote: post #9

Earlier quoted context omitted.

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…

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.

Re: Ca-certificates: removal of SPI CA

#22

Post by avar »

electic wrote: post #8

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?

Are there certificates that are "generally unrecognized" and are shipped by the two biggest OSs in use? That seems like an oxymoron.

Re: Ca-certificates: removal of SPI CA

#23

Post by FireBeyond »

icebraining wrote: post #21
newman314 wrote: post #16

Earlier quoted context omitted.

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.

Until you have several devices, then it begins to add up. It should at least be a switch:

--override-expiry --days=365

perhaps.

Re: Ca-certificates: removal of SPI CA

#24

Post by neerdowell »

JoshTriplett wrote: post #12
neerdowell wrote: post #9

Earlier quoted context omitted.

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…

> 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 s…

> 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.

Re: Ca-certificates: removal of SPI CA

#25

Post by geofft »

neerdowell wrote: post #9
JoshTriplett wrote: post #5

Related to this, the Debian nss package removed the SPI CA today, in version 2:3.21-1: 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 nice…

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…

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.)

Re: Ca-certificates: removal of SPI CA

#26

Post by caf »

avar wrote: post #22
electic wrote: post #8

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?

Are there certificates that are "generally unrecognized" and are shipped by the two biggest OSs in use? That seems like an oxymoron.

"all the certificates installed on a machine" and "certificates that [...] are shipped" are not necessarily the same thing.

Re: Ca-certificates: removal of SPI CA

#27

Post by shkkmo »

avar wrote: post #22
electic wrote: post #8

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?

Are there certificates that are "generally unrecognized" and are shipped by the two biggest OSs in use? That seems like an oxymoron.

You mean like the one Dell included?

Re: Ca-certificates: removal of SPI CA

#28

Post by ldarby »

electic wrote: post #8

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?

This might be of interest to you: https://news.ycombinator.com/item?id=10139817

Re: Ca-certificates: removal of SPI CA

#29

Post by iamsohungry »

neerdowell wrote: post #9
JoshTriplett wrote: post #5

Related to this, the Debian nss package removed the SPI CA today, in version 2:3.21-1: 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 nice…

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…

> 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.

Re: Ca-certificates: removal of SPI CA

#30

Post by JoshTriplett »

neerdowell wrote: post #24
JoshTriplett wrote: post #12

Earlier quoted context omitted.

> 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 s…

> 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 certifi…

> 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.

Post reply on HN