Hi everybody, I create a separate thread for the whole "tls improvement, let's create a module, lets see what to do with it" because for me it was getting a bit messier. Too many threads all talking about the same :) The TLS bussiness, we agree, is ugly and there is no one-fits-all solution, so we must try to be flexible, even if it means more development. Breaking it down, one more summary: 1) TLS transport layer authentication Allow for various levels of verification and peer certificate requirement. That is, request a cert from the peer or not, what to do if the certificate provided by the peer is not signed by one of our CAs (or if there is no peer cert at all), how the verification should be done (just check against our trusted CAs or do some DNS resolution for the provided Subject/CN on the ip we receive the connection from), etc. 2) Lifting the TLS authentication to the SIP layer for SIP authentication and authorization, according to "whatever" local policy I think here a tls_tools module is what we need. Let's think on what functions are needed to cover most needs. Proposals up to now include functions such as: tls_check_from/to( "SubjectName"/"CN"), tls_is_peer_cert_present(), tls_is_peer_cert_valid(), tls_is_peer_domain_trusted() as in white/black list, etc. 3) Incoming requests 3.1) Single domain This does not present much of a problem. Just present whatever certificate the proxy is serving. Use the tls_tools module to further authenticate and authorize the requeset. 3.2) Multi-domain This present a lot of problems, but there are solutions: 3.2.a) Use a different ip:port per domain ... good enough if the domains served are not changing often. 3.2.b) Present the host certificate, not one per domain ... usable as a fall-back scenario if everything else fails. 3.2.c) Use TLS Extensions, so the requesting proxy notifies the receiving proxy of the domain it is requesting. I just found some guys (i think an initial project from stanford, i don't know now) that implemented the TLS Servername Extension (http://www.edelweb.fr/EdelKey/). I am still waiting for more answers on the ssl-users mailing list, hopefully it is already included in the core, otherwise this solution would mean having to compile openssl locally :( 4) Outgoing requests 4.1) Single domain Again, not much of a problem. 4.2) Multiple domain Solution here is simpler. Provided that the domains are internally setup, select the desired one when forwarding the request (either automatically or via some function in tls_tools module). TLS domains can currently only be set up statically in the config file, thus some dynamic mechanism to create new ones has to be found (database, serctl? ). 5) Out-of-the-box setup That is, ser should allow to work using some very simplistic TLS form just by compiling it with TLS=1 and turning the tls_disabled=0 parameter. In this scenario, TLS could work using anonymous ciphers (no need for certificates) and would accept any incoming request (no verification of certs against CAs, or come with a generic root CA, but that would be more complex). In this mode, a huuge warning should be issued. Let's try to focus on specifics, so we can get this working as soon as possible. Regards, Cesc