Hi Alexander,

Verification of the cert in openser for now is limited ... it checks that the cert provided by the peer is signed by one of your trusted roots.
Thus, if one of the CAs you trust signs a certificate for sip.badguy.com ... you eat that certficate raw :)

Obviously, this is no good. The discussions we are having though are shedding a lot of light. A summary ...
- Provide flexibility in the way the connection is authenticated (what to check from the sip message against what in the tls cert)
- Support naptr look ups for flexible routing to tls and for sips uris
- easy configuration of domains (when dialing in and out), with different certs and setups. This is targeted at multi-domain providers

Quite some work, but i am for it :)

Cesc

On 10/10/05, Alexander Ph. Lintenhofer <lintenhofer@aon.at> wrote:
Hi everybody,

According to RFC3261 proxies should possess a site certificate whose
subject corresponds to their canonical hostname.
In the case of gen_usercert.sh helperscript this must be placed in the
"Common Name" field I guess.
So when mutual authentication takes place, the two proxies should check
the CN of each others certificate.

I have a proxy sip.atlanta.com and another one sip.biloxi.com. I
generated two certificates with CN=hostname. Then I added the
rootCA-certs of the other proxy to the calist.pem. It works really fine :-)
So I played around and generated certificates with other CNs like
badguy.atlanta.com or sip.badname.com or badguy.badname.com - they don't
have either the corresponding hostname or the domainname of the server
(or both). I imported one after the other in sip.atlanta.com  - and it
still works (tls_init: verify_callback: preverify is good: verify
return: 1) :-(

So, am I doing something wrong or does OpenSER not validate the
host/domainname of the server against the certificate's subject ???

Thanks for hints !

regards,
Philipp

_______________________________________________
Users mailing list
Users@openser.org
http://openser.org/cgi-bin/mailman/listinfo/users