ancillary comment on RE: SNI Support

Someone decided to implement a rule that the cert store used for discovering chains for SSL virtual hosting (possibly using SNI hint) should be used also to populate the client cert CA list. There are no conformance rules on this topic. SSL itself make no statements.

In the windows world, you have to use command line admin tools to bind a cert to multiple SSL virtual hosts, where each one is then tied to one or more ports/IP transport endpoints. By default, the "IT admin" tools force restrictions on the general model (you have to know what you are doing with SSL to avoid these constraints - which are there to protect the general IT admin, and thereby maximize interoperability out of the box with browsers that never underwent any formal QA in the windows world).

SNI just allows the hint to tell the SSL listener which server cert (and any chain) to present, assuming several are bound to the transport endpoint.

In some implementations, the endpoint listener for SSL chooses a distinct server chain, per client (or client socket... or XYZ). If the listener decides for some reasons that it WOULD send a client cert CA list of x and y (omitting z, also sent to others), then it might decide to send the server chain that also terminates at either x or y. Or, the implementation might not, being less sophisticated. The client is not required to use that suggested chain in any case, being entirely responsible for find a path between the public key in the server to a client-side trust anchor. Typically, folks relyon the provided EE cert, and choose their own path from said cert to a local trust anchor. In conforming cases, they will conform with the extensions, which can constrain discovery.

In the windows world, when using browser-based https the programmed "behavior" attempts to do what Mozilla does. This behavior is only specific to IE in browser mode (aping Mozilla), and may not be present when https from a https library or an IE wrapped in a Windows form - where the https is not attempting to be a browser (or ape Mozilla, and its sometimes rather strange ideas on how SSL should apply to the world of web "browsing"). Perhaps, the https is tuned up for webservices, or SAML over https, etc - which are tighter security concepts than "Mozilla-browsering"

With Webid we HAVE to get used to the idea that the use of SSL by the resource server collecting foaf cards is NOT acting as a browser in handling HTTP not in performing https/SSL.

Folks may wish the world of communication security was as simple as Wikipedia article. But, it isn’t. one tunes the mechanism for the threats one sees as relevant to different acts of web communication, "browsing" being just one class.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
Sent: Friday, April 29, 2011 12:01 PM
To: WebID XG
Subject: Re: SNI Support

Hello,

I've come to the conclusion that using "SSLVerifyClient optional_no_ca"
is mutually exclusive to having a valid CA bundle file. Some issuers (AlphaSSL in my case) require that websites must also provide the CA bundle file (the certification chain). 

If a CA bundle file is provided and the option "SSLVerifyClient optional_no_ca" is used (in order to authenticate WebID users by requiring their browser certificate), then the authentication does not happen anymore (the server no longer asks for a certificate).

If the CA bundle file is not used, the authentication takes place just fine. However, some browsers will not be able to verify the server certificate's issuer -> the same behavior as using self-signed server certificates; which makes one wonder why pay for a signed certificate in the first place.

I'm open to suggestions at this point...

Andrei

On Fri, 2011-04-29 at 09:39 +0200, Andrei Sambra wrote:
> Being a wildcard certificate, it has to use the same CN: *.fcns.eu. I 
> cannot add other subdomains, since it would require issuing new 
> certificates -> me paying for them. :-)
> 
> Another possibility would be to switch to a different hosting provider 
> / CA.
> 
> What's weird is that after a clean install of Ubuntu (w/ FF 4.0) on a 
> lab machine, I had the same warning regarding the validity of the 
> server certificate. Weird...
> 
> I'll try to document all these issues on the wiki somewhere, so we 
> have a starting base.
> 
> Andrei
> 
> On Fri, 2011-04-29 at 00:56 +0200, bergi wrote:
> > Andrei, I would expect that your server doesn't use SNI, because 
> > your certificate uses the common name *.fcns.eu. I think the IE 
> > had/has problems with wildcard common names. Perhaps also safari 
> > doesn't like these certificates. You are already using the 
> > alternative name for fcns.eu. You could try to add your other subdomains to avoid problems.
> > 
> 
> 
>

Received on Friday, 29 April 2011 19:39:53 UTC