Joe Orton wrote:
> Access control is certainly the most important issue, but e.g. if
> SSLCertificateChainFile is not supported properly for the named vhost
> that's also a bug. Many configs depend on supplying the intermediate
> certs.
True. I'm using such a configuration on my test host since it's initial
setup (all hosts have at least one intermediate CA), and had verified
earlier that it's indeed working properly for SNI clients - just compare
the chains you get with
openssl s_client -connect sni.velox.ch:443 -servername sni.velox.ch
vs.
openssl s_client -connect sni.velox.ch:443 -servername appendix.velox.ch
>> (SSLCertificateChain is not relevant when verifying peer certs, and
>> apart from this, I didn't see any additional parameters in
>> modssl_ctx_t/modssl_auth_ctx_t which are relevant for access control.)
>
> I'm think it is relevant. AFAICT the SSL handshake which takes place in
> the SNI case is going to be done using the settings from the SSL_CTX
> from the original vhost not the named vhost, plus those explicitly
> copied over after the SSL_set_SSL_CTX() call.
Not from what I remember from my work on the patch in January/February,
but I need to look into it again before coming up with a thorough
analysis. Generally speaking, the question is what setting in an SSL
structure (as obtained by SSL_new) is taken from the SSL_CTX at what
time (and whether SSL has its own copy or just takes it from its
underlying SSL_CTX referenced through the ctx pointer member). Depending
on this, some additional tuning after SSL_set_SSL_CTX is necessary - as
it turned out to be the case for verify_mode, e.g.
> SSLCertificateChainFile
> SSLCADNRequest{File,Path}
> SSLHonorCipherOrder
> SSLProtocol
>
> which I think is an exhaustive list. SSLProtocol and
> SSLHonorCipherOrder may be "interesting" because the handshake has
> already begun at the point it needs to be applied.
Ok, I'll examine these as well - but this of course will take me a few
days, so thanks for staying tuned (and for your replies so far).
Kaspar
