https://wiki.freebsd.org/ certificate error

[Jeremy Chadwick]

(Please keep me CC'd as I'm not subscribed to -questions)

(I'm CC'ing Simon Nielsen who maintains the FreeBSD webserver cluster, as
this obviously needs to be looked at.)

First, be aware that the following advice which was given:

> openssl s_client -showcerts -connect wiki.freebsd.org:443

...is not a sufficient/correct test for this sort of thing.  Let's talk
about why, and how to do it right:

OpenSSL since 0.9.8 has supported SNI (more on what that is in a
moment), but only if the -servername flag is it used (with s_client
specifically, I think).  Otherwise, in this case, what gets returned is
the "webserver default" SSL certificate.  Expanding:

Look very closely at the CN (CommonName) field in the below cert.  I
should note wiki.freebsd.org during both tests below resolved to
8.8.178.110:

$ echo "" | openssl s_client -showcerts -connect wiki.freebsd.org:443 | grep CN=
depth=1 /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
 0 s:/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=www.freebsd.org
   i:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
 1 s:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
subject=/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=www.freebsd.org
issuer=/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
DONE

This **is NOT** correct, and would result in a CN mismatch and throw an
error in some browsers (keep reading), because wiki.freebsd.org !=
www.freebsd.org.  What you need to do is this:

openssl s_client -showcerts -connect wiki.freebsd.org:443 -servername wiki.freebsd.org

Result:

$ echo "" | openssl s_client -showcerts -connect wiki.freebsd.org:443 -servername wiki.freebsd.org | grep CN=
depth=1 /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
 0 s:/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=wiki.freebsd.org
   i:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
 1 s:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
subject=/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=wiki.freebsd.org
issuer=/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
DONE

Much better.

The -servername flag is not documented anywhere in the FreeBSD OpenSSL
man page directory (/usr/share/openssl), and don't ask me why.

So what's SNI?

http://en.wikipedia.org/wiki/Server_Name_Indication

For deep details, look at RFC 6066, RFC 4366, and RFC 3546.  Otherwise
the simple version is: SNI allows, at the SSL client level, a way to
include a FQDN/hostname in the initial handshake.  This solves the
"chicken-and-egg" problem involving name-based virtualhosts where the
webserver can't determine what the HTTP Host: header is because it's
encrypted.  The same goes for any protocol (not just HTTP) that has
similar mechanisms.

NOW BACK TO THE ACTUAL PROBLEM REPORTED --

It appears that whoever maintains the FreeBSD webservers in the cluster
**assumes** that the connecting client supports SNI.  That assumption,
as someone who ran a hosting organisation since 1993, is rude (some
might say "bad", but I would say rude).

Web browsers/clients that don't support SNI are screwed -- they'll
receive a "certificate validation failure" error.

Internet Explorer 6.x through 8.x -- newer is not available on Windows
XP -- do not support SNI (this is even mentioned in the above Wikipedia
page).  They return the error "There is a problem with this website's
security certificate" due to lack of SNI support.

Let me be clear: THIS IS NOT THE FAULT (OR AGE) OF THE OS.  THIS HAS TO
DO WITH THE WEB BROWSER.  Why?

Because Firefox 19.0 on Windows XP works just fine, as it supports SNI.

So how do you solve this problem for "legacy" clients?  Simple:

By dedicating an IP address to the SSL-based virtualhost/webserver (i.e.
one IP address per SSL-based virtual host), and do away with name-based
vhosting for SSL.  That's the only way.

You can continue to use name-based vhosting for non-SSL, as pretty much
all browsers (including IE 6.x) support the HTTP Host: header.

To find out if SNI is used or not, do a packet capture and
look at the SSL "Client Hello" packet in Wireshark.  Go looking for the
"Extension: server_name" section of the TLSv1 portion of the packet
(Wireshark can decode this) and you'll find it.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |