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

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.

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?

[1] https://alioth.debian.org/scm/?group_id=30428
[2[ https://spi-inc.org/

On 02/26/2014 11:43 PM, 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.
>
> 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?

I would argue that you can't trust a CA, period. That said yes, we
should have proper certificates.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
a rose in the deeps of my heart. - W.B. Yeats

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

For reference:
Using Debian which includes the SPI CA, I get

spi-inc.org uses an invalid security certificate. The certificate is not valid
for any server names. (Error code: ssl_error_bad_cert_domain)

even though there is no issue with
https://alioth.debian.org/scm/?group_id=30428

Cheers,
Bill.

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

On 27/02/14 17:37, Jimmy Kaplowitz wrote:> On Thu, Feb 27, 2014 at 07:43:32AM +0000, TJ wrote:
>> 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.

If that is the intent then the URL I accessed should *not* be served over HTTPS at all.

My initial issue - the untrusted Debian certificate - stemmed from being referred to the Debian URL in order to check the Debian Linux kernel repository. I was not using a Debian host to do that, so
when the browser warned of certificate issues I followed the chain back to the CA.

Not having heard of SPI previously I wanted to verify the organisation's authenticity. Finding what seemed like an amateurish fault on the SPI host certificate too, my willingness to trust the CA was
greatly diminished.

On Thu, Feb 27, 2014 at 08:48:35PM +0000, TJ wrote:
> If that is the intent then the URL I accessed should *not* be served over HTTPS at all.
[...]
> Not having heard of SPI previously I wanted to verify the organisation's
> authenticity. Finding what seemed like an amateurish fault on the SPI host
> certificate too, my willingness to trust the CA was greatly diminished.

It's a valid point that the user experience might be clearer if both URLs were
separated to be served from different IPs, or the certificate updated to
include spi-inc.org & www.spi-inc.org and either HTTPS serving enabled or a
redirect to HTTP installed. I'll make sure our sysadmins notice this thread.

That said, from a technical perspective, the browser certificate warning occurs
before the server even knows which URL you're trying to access. I realize that
this is not obvious, and this perception issue is why the most high-profile
sites do one of the workarounds described above.

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

On 27/02/14 23:32, Jimmy Kaplowitz wrote:
> On Thu, Feb 27, 2014 at 08:48:35PM +0000, TJ wrote:
>> If that is the intent then the URL I accessed should *not* be served over HTTPS at all.
> [...]
>> Not having heard of SPI previously I wanted to verify the organisation's
>> authenticity. Finding what seemed like an amateurish fault on the SPI host
>> certificate too, my willingness to trust the CA was greatly diminished.
>
> It's a valid point that the user experience might be clearer if both URLs were
> separated to be served from different IPs, or the certificate updated to
> include spi-inc.org & www.spi-inc.org and either HTTPS serving enabled or a
> redirect to HTTP installed. I'll make sure our sysadmins notice this thread.

Most sites and browsers support SNI in which case multiple IPs aren't required, although to
handle those user agents that don't support SNI it is usual to make the server's default site
be the primary HTTPS site for the organisation.

Instead of several additional ALT Subject Names just use the wildcard "*.spi-inc.org" in addition to a CN of "spi-inc.org".

On Thu, Feb 27, 2014 at 11:46:32PM +0000, TJ wrote:
> Most sites and browsers support SNI in which case multiple IPs aren't
> required, although to handle those user agents that don't support SNI it is
> usual to make the server's default site be the primary HTTPS site for the
> organisation.
>
> Instead of several additional ALT Subject Names just use the wildcard
> "*.spi-inc.org" in addition to a CN of "spi-inc.org".

I've brought this thread to our sysadmins' attention. Thanks for mentioning it.

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

On Thu, February 27, 2014 18:37, Jimmy Kaplowitz wrote:
> 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.

Since Debian is in the process of replacing its SSL certificates by ones
supplied by Gandi (that are recognised by all major browsers), it seems
like this could be a good option for SPI aswell.

Cheers,
Thijs

On Feb 27, 2014 6:46 PM, "TJ" <spi-inc(at)iam(dot)tj> wrote:
> Most sites and browsers support SNI in which case multiple IPs aren't
required, although to
> handle those user agents that don't support SNI it is usual to make the
server's default site
> be the primary HTTPS site for the organisation.

I thought the point of using multiple IPs was to allow one to accept HTTPS
and one to not listen to 443 at all. (Not something you can do with SNI…)

-Jeremy

On 02 Mar 2014, at 18:02, Jeremy Baron <jeremy(at)tuxmachine(dot)com> wrote:
> On Feb 27, 2014 6:46 PM, "TJ" <spi-inc(at)iam(dot)tj> wrote:
> > Most sites and browsers support SNI in which case multiple IPs aren't required, although to
> > handle those user agents that don't support SNI it is usual to make the server's default site
> > be the primary HTTPS site for the organisation.
>
> I thought the point of using multiple IPs was to allow one to accept HTTPS and one to not listen to 443 at all. (Not something you can do with SNI…)
>

The point of multiple IPs is to allow you to use multiple SSL certificates, since SNI is nice but in the real world still unusable due to the large number of people still using Windows XP which does not support SNI. SPI does not have extra IP addresses to spare as far as I know, and an ISP is not likely to give you extra IP space if your rationale is “I want to serve sites without SSL”.

Randomly trying to access a site by changing a HTTP url to HTTPS one is likely to result in problems. SPI is not unique in that aspect.

Wichert.