If you want just one setup, then you are forced to use the "less

Hi Alexander, That is a very good question. An option you have is to use tls_verify=1 tls_require_cert=0 This will make ser to request a certificate from the other peer, but if the peer does not send one the TLS handshake will still succeed. This is from the readme file: ===================================================================== * How does verification work? Verification is the process by which the authentication data provided by the peers is checked. This data consists usually of a peer certificate, plus a chain of trusted certification authorities. If for whatever reason, either of the peers thinks that the handshake is not valid, the ssl connection is not established. The reasons could be many: untrusted server certficate, too-weak algorithm, invalid client cert, no client authentication, ... The "tls_verify" and "tls_require_certificate" are SER-names for the OpenSSL defined flags SSL_VERIFY_PEER (tls_verify) and SSL_VERIFY_FAIL_IF_NO_PEER_CERT (tls_require_certificate). tls_require_certificate is only used if tls_verify=1. If we are acting as a server, we always send our server-side certificate to the client. - If tls_verify=0, we do not request the client a client-certificate. This means that the client is not authenticated. - If tls_verify=1, we (the server) send a client-certificate request to the client. But the client is free to not provide any. In this case, tls_require_certificate comes into play: _ if tls_require_cert=0, the verification process will succedd if the client does not provide a certificate, or if it provides one, it verifies correctly against the server's list of trusted certification authorities. _ if tls_require_cert=1, the verification process will only succeed if the client provides a certificate and this verifies correctly against the server's list of trusted CAs. ===================================================================== Now, another option: Create two different domains, one for UAs, the other for inter-proxy connection. This way, on the UA domain you can be more lax in the settings (tls_verify=1, tls_require_cert=0), whereas in the inter-proxy domain you can force certs (tls_verify=1, tls_require_cert=1). I guess this you probably don't want to do. If you want just one setup, then you are forced to use the "less secure" setup so that your UAs can support it. Hope it helps, Cesc On 10/8/05, *Alexander Ph. Lintenhofer* &lt;lintenhofer(a)aon.at <mailto:lintenhofer@aon.at>> wrote: Hi there, I have a question concerning TLS in openser: By switching tls_require_certificate to "on", the peer is forced to send his certificate for means of mutual authentication. My problem is, that the peer may be another proxy server whom I want to authenticate with its cert - but the peer might also be an user agent. In my situation I use a Snom 360 which has not the possibility to import an own user-certificate (only a CA-cert for verifying server-certs). ----------- ---------- --------- | snom 360 | <------ TLS -------> | outbound | <----- TLS -----> | inbound | ----------- server sends cert ---------- mutual AUTH --------- But when I activate tls_require_certificate=on in the openser.cfg of the outbound proxy, the snom360 can't register, because it has no user-cert. On the other hand, when I disable tls_require_certificate, the snom can register, but the security between the proxies is weak. Is there an appropriate solution for this problem ?? Maybe I didn't understand the sample configuration at all.... Thanks in advance and regards, Philipp _______________________________________________ Users mailing list Users(a)openser.org <mailto:Users@openser.org> http://openser.org/cgi-bin/mailman/listinfo/users

See inline ... On 10/9/05, *Alexander Ph. Lintenhofer* &lt;lintenhofer(a)aon.at <mailto:lintenhofer@aon.at>> wrote: Hello Cesc, Thanks for your answer! secure" setup so that your UAs can support it. I think this is not a sufficient solution. Maybe it's possible to make black- or whitelists for authentication rules in future developments (just an quick'n'dirty idea). Do you mean something like: if connecting ip:port is in white list, apply a less restrictive tls authentication (do not require peer cert) if connectin ip:port is not in white list or in black list, demand a stronger auth Is that it? Note that you can only do this lists based on ip:port, as TLS setup is previous to any sip exchange. What i really think it could work is to create a function (probably in a tls_utils module), which may allow to perform the extra verification that you could not when tls setup. I mean, you setup all tls asking for a certificate from the other peer, but do not require that it sends it. Then, from within the config file, you could use a special function and force ser to perform the extra verification on the tls (equivalent to tls_require_cert=1)

Just a thought ... With NAPTR-lookup support, the t_relay_to_tls("specific domain","specific port") function could also be serviced by t_relay(), or am I wrong? Indeed, it should work. I don't know if ser uses the lookups correctly ... t_relay should already work if your endpoint registered the contact over tls (transport=tls). For inter-proxy, either you rely on naptr or use the t_relay_to_tls.