On Monday 10 October 2005 10:03, Klaus Darilion wrote:
Juha Heinanen wrote:
i'm not a TLS expert either, but i have been wondering if a proxy serving multiple domains would need to have a client/server certificate for each. i hope not.
in klaus' example, srv query on
_sips._tcp.example.com.
could return a server name in a domain foo.com. in proxy-to-proxy scenario, it should suffice that both proxies have certificates for the proxy hosts themselves and they don't need to have anything to do with the domains in the uris of sip requests.
But then, the whole authorization thing would be nonsens.
Just imagine a host named "sip.badguy.com". This host has a valid certificate for its hostname. Then, this SIP proxy sends a SIP request with the header: From: "Klaus Darilion" sip:klaus@darilion.com
Now, what is the receiving proxy interested in? Does it want to validate the host or the sender (From header)?
IMO, I want to authenticate the sender in the From header. Thus, the certificate would have to match the SIP domain, and not the host name.
Please read RFC3263 section 4.1. It gives much insight.
I think you are right for the scenarios where you are the client and you are serving the domain in the From header. In that case you should present a certificate which matches the From. But on the other site: what happens if you just forwarded the request and neither the From, To or (the new) request-uri belongs to you. In that case you can only present a generic certificate which matches one of your domains. But for me it is anyhow a question what a server is going to verify on a client certificate.
But for the server scenario I think Juha is right. Because when the TLS connections is being establish you do not know for what is the target domain of the request. Thus you can only present one generic certificate and that should be valid for all of your domains.
Nils