Re: www.spi-inc.org uses an invalid security certificate

Hi TJ,

On Thu, Feb 27, 2014 at 07:43:32AM +0000, TJ wrote:
> Early I accessed a secure Debian server [1] that presented a X509 certificate issued by an untrusted CA that turned out to be spi-inc.

SPI's CA is trusted by Debian and derivatives by default, and is available for
others to install from SPI's website. Since we realize the chicken-and-egg
problem, we also serve a copy of its fingerprint which is GPG-signed by SPI
board members / sysadmins using keys with many signatures in the
strongly-connected web of trust set.

http://www.spi-inc.org/ca/

The CA is not in Mozilla-based browsers or on non-Debian-based systems by
default because SPI has neither been able to afford nor justify fundraising for
the high financial cost of a WebTrust audit. (The issue of support in Debian's
Mozilla-based browser, if it hasn't been solved yet, is purely a client-side
technical issue. It may have been solved, I'm not sure.)

> Visiting spi-inc.org [2] I hit another issue with an invalid certificate being presented causing Firefox to warn "The certificate is not valid for any server names" (as well as certificate not
> trusted). The certificate's Common Name is "members.spi-inc.org" and there are no Subject Alt Name hosts.
>
> How can we have trust in the CA when the CA itself cannot correctly manage its own certificates?

While your empirical data is correct, your conclusion is not. There's no place
in which we link to the main SPI website using that URL; it's intended to be
viewed over unencrypted HTTP. The only SPI website which is meant for HTTPS
access is members.spi-inc.org, which is correctly reflected in the SSL
certificate.

You may ask why SPI hasn't signed up for one of the commercial options. Turns
out there really isn't a good one. Some examples: purchasing an official
intermediate CA would be expensive and we're smaller than the vendors typically
intend; Debian needs to run its own sub-CA for its system administrative needs;
the free SSL certificate options like StartSSL are not compatible with teams
like Debian which justifiably need a sysadmin team associated with the account
instead of an individual; etc. All of this is in addition to the very small
nature of the trust benefit of commercial CAs over what we have now.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org