Seems like a good idea to not place the ALPN patches into 2.4 - yet. During my tests, I discovered that the order of my vhost definitions affected the certificate chosen - when ALPN was in play. After some analysis, the following seems to occur. This is to make the mod_ssl people here aware and get their opinion on a workaround.
1. connection, setup for base server and defaults 2. client hello arrives 3. ALPN callback is invoked by openssl 4. ALPN protocol is chosen, this triggers the server answer 5. SNI callback is invoked by openssl and sets up vhost info and configs 6. Oops. Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback to the default vhost selection and that certificate is used to answer the call. The issue has been reported by me on the openssl dev list. As a workaround for now and compatibility to older openssl versions, I propose to add to the ALPN patch something that a) checks in ALPN callback if vhost has been setup by SNI callback b) if not, retrieves SNI servername via SSL_get_servername() c) if servername is returned, setup vhost just like in SNI callback d) if SNI callback is invoked and vhost has been setup already, nop Sounds reasonable? //Stefan <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
