11 ms·

Ca-certificates: removal of SPI CA

70 points by hsivonen 11y ago

jjuhl 11y ago
A sensible move.
hsivonen 11y ago
FWIW, Ubuntu appears to inherit this cert from upstream.
- mdeslaur 11y ago
  I will remove it in our next updates.
  - hsivonen 11y ago
    Thank you.
hsivonen 11y ago
Recently issued SHA-1 cert from this root: https://www.ssllabs.com/ssltest/analyze.html?d=members.spi-inc.org https://www.ssllabs.com/ssltest/analyze.html?d=members.spi-i...
JoshTriplett 11y ago
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/msg02509.html 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.
- azet 11y ago
  Thanks for working on this! Post is also spot on. 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.
- neerdowell 11y ago
  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
  - hannob 11y ago
    I haven't yet had the need to try revocation, but Wosign is a more accessible option than startssl. No noncommercial restriction, 1 year free.
    - thesimon 11y ago
      One thing to look out for though is the fact that they offer you to generate a private key for you. You probably don't want them to have your private key :)
electic 11y ago
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 11y ago
  Are there certificates that are "generally unrecognized" and are shipped by the two biggest OSs in use? That seems like an oxymoron.
  - caf 11y ago
    "all the certificates installed on a machine" and "certificates that [...] are shipped" are not necessarily the same thing.
  - shkkmo 11y ago
    You mean like the one Dell included?
    - yrro 11y ago
      Two actually! :)
- ldarby 11y ago
  This might be of interest to you: https://news.ycombinator.com/item?id=10139817 https://news.ycombinator.com/item?id=10139817
e12e 11y ago
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-Shipped/ https://github.com/RedHatProductSecurity/Certificates-Shippe... Also submitted to hn seperately here: https://news.ycombinator.com/item?id=10630736 https://news.ycombinator.com/item?id=10630736
edward 11y ago
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.

70 points by hsivonen 11y ago

jjuhl 11y ago

A sensible move.

hsivonen 11y ago

FWIW, Ubuntu appears to inherit this cert from upstream.

mdeslaur 11y ago
I will remove it in our next updates.
- hsivonen 11y ago
  Thank you.

hsivonen 11y ago

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

JoshTriplett 11y ago

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/msg02509.html 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.

azet 11y ago
Thanks for working on this! Post is also spot on. 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.
neerdowell 11y ago
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
- hannob 11y ago
  I haven't yet had the need to try revocation, but Wosign is a more accessible option than startssl. No noncommercial restriction, 1 year free.
  - thesimon 11y ago
    One thing to look out for though is the fact that they offer you to generate a private key for you. You probably don't want them to have your private key :)

electic 11y ago

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 11y ago
Are there certificates that are "generally unrecognized" and are shipped by the two biggest OSs in use? That seems like an oxymoron.
- caf 11y ago
  "all the certificates installed on a machine" and "certificates that [...] are shipped" are not necessarily the same thing.
- shkkmo 11y ago
  You mean like the one Dell included?
  - yrro 11y ago
    Two actually! :)
ldarby 11y ago
This might be of interest to you: https://news.ycombinator.com/item?id=10139817 https://news.ycombinator.com/item?id=10139817

e12e 11y ago

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-Shipped/ https://github.com/RedHatProductSecurity/Certificates-Shippe... Also submitted to hn seperately here: https://news.ycombinator.com/item?id=10630736 https://news.ycombinator.com/item?id=10630736

edward 11y ago

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.