From owner-freebsd-questions@FreeBSD.ORG Sat Mar 2 07:48:17 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E70D09FD for ; Sat, 2 Mar 2013 07:48:17 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id CE505F24 for ; Sat, 2 Mar 2013 07:48:17 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 6Xky1l0050x6nqcA1XoHvj; Sat, 02 Mar 2013 07:48:17 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id 6XoG1l0051t3BNj8YXoGka; Sat, 02 Mar 2013 07:48:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4A93C73A31; Fri, 1 Mar 2013 23:48:16 -0800 (PST) Date: Fri, 1 Mar 2013 23:48:16 -0800 From: Jeremy Chadwick To: freebsd-questions@freebsd.org Subject: Re: https://wiki.freebsd.org/ certificate error Message-ID: <20130302074816.GA61133@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362210497; bh=sakUGA2tq0U7R0XRpy5APSaJ1Q+IABkcrVUZsQj6lT0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=EyTesvPWR9HdPsbwyT8vnTrPqqzAYXicGLz8NbYWfL7INWC1ka7maxn5jNIDrrMlM Btb3pSrMoPQdOFyPp49ALBeiPjrzdw8m4eDqlfVnrGetymU0CizXeZ/2aY0T1oDwUC WbjMOL3aP3c/46s47XXTc0liCT9CcM7L1RUv6sej6nP/pcRJKo83eLkMKIXEXEXqlk rTAcaL5iCp8Lg29peHNGt2t0fWc4KJbKoIGyFzn2Ffmre0WT5fGS1rPtbp6kaUd2Qq QrZSmM8+1X1dj9aYcSlgituLjKQxKRTEX1K++QEr8XRlNvK5woRr4WFsWMJN05zsWQ MDV/gRBeDtywA== Cc: "Simon L. B. Nielsen" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 07:48:18 -0000 (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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |