Peter, Users using simple login/pass are connecting thru classic browsers. Advanced users using client cert will connect using a special application, developed with libcurl. So basically the client knows in advance which way to use.
Modifying /etc/hosts is not an acceptable solution since generally common users don't have rights to modify this file. Using two ports would be a solution, except that the server will be behind a firewall only allowing 443 (and in my case this would also require two server instances which is not necessarily practical). Plus, since both types of clients are using HTTPS, it doesn't seem illogic for them to connect to the same port anyway. > The SNI not used to differentiate between other security environments in this way. As I mentioned the RFC states that SNI is used for certificate selection "OR OTHER ASPECTS OF SECURITY POLICY". So I don't see anything in the RFC against this usage... > This is not advanced control IMO. Agree : this is not very advanced :-) Daniel, Sorry for top-posting. Hope this is better this time. Agree with you that it may sound strange but fact is that I have control over the server (and client...) code but not over the network stuff (basically that's the reason of the single dns entry, single port...) I'm not sure to understand your idea with the custom Host header : for me the server will only get this within the HTTP header, so after the TLS transaction took place and it is then too late to modify the handshake to request client cert. But maybe I missed something. Code is already written and working, so I saw this contribution more like an extra feature for libcurl without any real work to do on your side. But I'm not stuck with this solution if we can find a better one. Anyway, thanks to both of you for your interest in my issue. I really appreciate. Matthieu ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
