Hi Klaus, Klaus Darilion wrote: Yes, it works. Configuration of the client part was not done yet(see my email on serdev, it was mentioned there), I fixed that already and will commit it shortly. But this is not a problem as long as you only use the default client domain, because in that case you can just put the certificate in the default path and it will work. I have tested this several times and it working for me. Could you send me your tls configuration, so that I can retry it ? Jan.

Klaus Darilion wrote: Currently 0.9.8a-6, but I was using the version from debian/stable before without problems. Jan.

Jan Janak wrote: Hi Jan! The more I reveiw the code the more I come to the conslusion that the TLS code you are using is different to the TLS code released. e.g. the default settings in config.h are wrong: #define TLS_PKEY_FILE CFG_DIR "cert.pem" #define TLS_CERT_FILE CFG_DIR "cert.pem" ^^^^^^^^ You said it should work fine as long as I use the default client domain. But in the default client domain the keys are set to 0: /* Default client domain */ d->cert_file = 0; d->pkey_file = 0; d->verify_cert = 1; d->verify_depth = 3; d->ca_file = 0; d->require_cert = 1; d->method = TLS_USE_SSLv23; tls_def_cli = d; So, are we talking about the same TLS code? regards klaus

On Feb 01, 2006 at 14:43, Jan Janak <jan(a)iptel.org> wrote: No, he is right, this is a bug. A normal TLSv1 server will accept only TLS hello messages (version = 3.1) and since sip is supposed to work only with TLS, this should be the default (tls_method=TLS_USE_TLSv1). The SSLv23 stuff will accept any type of hello. A client with the SSLv23 method will send a hello v2 message, indicating in it also tls and ssl 3.0 support (they will include tls specific ciphers a.s.o). The client sending v2 hellos is not exactly standard behaviour for TLS. It is a hack for backward compatibility, but a TLS only server will not accept it. One of the clients that used a SSLv23 equivalent was Windows Messenger (it was doing this in 2003 when I wrote my ser tls code). The tls method should be configurable to allow older/strange clients support, but it should default to TLSv1 (btw: this is how you can reject v2 clients without SSL_OP_NO_SSLv2). I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for. Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not. If you need special verify on only for some clients, either make it per ip, or use another tls port on which you have verify turned on. Andrei

On Feb 03, 2006 at 15:48, Jan Janak <jan(a)iptel.org> wrote: Yes, I think so, a normal SIP implementation should speak TLSv1. No, I think you should have a verify all option. You could use then the script to allow access to certain resources only to certain clients, but the certificate validity checks should be done at the tls level. BTW: the above example should use exit -1 instead of break (to force close the tls connection, which otherwise would remain open until it timeouts or the remote side closes). Andrei

On Feb 03, 2006 at 16:02, Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt; wrote: That's why you should set tls certificates/cas on an ip base (it would be easy to choose the correct certificate/ca). The tls "extended" certificate checks will just make sure that the certificate was issued for the ip or dns name of the peer. This should be a configuration option (e.g tl_verify= off|on|extended). What I'm trying to say is that certificate validity checks don't make sense in the script, in the "normal scenarios". You could use them (with tls_verify=on), but not to deny access in general, just for some limited resources (e.g. allow local calls, but permit relaying only if <extra certificate checks>). Andrei