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

31–38 of 38 posts

Re: Ca-certificates: removal of SPI CA

#31

Post by Laforet »

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…

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

Re: Ca-certificates: removal of SPI CA

#33

Post by 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

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

Also submitted to hn seperately here:

https://news.ycombinator.com/item?id=10630736

Re: Ca-certificates: removal of SPI CA

#34

Post by aeijdenberg »

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…

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

Re: Ca-certificates: removal of SPI CA

#35

Post by azet »

ams6110 wrote: post #20
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…

Does certificate revocation work better these days? http://news.netcraft.com/archives/2013/05/13/how-certificate...

Short story? No. Adam Langely has extensively written about the subject and difficulties at Google and in Chrome. In chronological order:

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.

Re: Ca-certificates: removal of SPI CA

#36

Post by sorenstoutner »

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…

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]

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

Post reply on HN