
Ca-certificates: removal of SPI CA - hsivonen
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796208
======
JoshTriplett
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...](https://lists.debian.org/debian-devel-
changes/2015/11/msg02509.html)

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.

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

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

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

~~~
JoshTriplett
> 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].

> [1] [https://letsencrypt.org/2015/10/29/phishing-and-
> malware.html](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/](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.

~~~
neerdowell
_> 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.

~~~
aeijdenberg
> 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/](https://letsencrypt.org/certificates/)

------
electic
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?

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

~~~
shkkmo
You mean like the one Dell included?

~~~
yrro
Two actually! :)

------
e12e
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:

[http://seclists.org/oss-sec/2015/q4/374](http://seclists.org/oss-
sec/2015/q4/374)

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:

[https://github.com/RedHatProductSecurity/Certificates-
Shippe...](https://github.com/RedHatProductSecurity/Certificates-Shipped/)

Also submitted to hn seperately here:

[https://news.ycombinator.com/item?id=10630736](https://news.ycombinator.com/item?id=10630736)

------
hsivonen
Recently issued SHA-1 cert from this root:
[https://www.ssllabs.com/ssltest/analyze.html?d=members.spi-i...](https://www.ssllabs.com/ssltest/analyze.html?d=members.spi-
inc.org)

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

------
hsivonen
FWIW, Ubuntu appears to inherit this cert from upstream.

~~~
mdeslaur
I will remove it in our next updates.

~~~
hsivonen
Thank you.

------
jjuhl
A sensible move.

