Hi All
Is it possible to explicitly define the tls cert to be used per destination by
dispatcher?
I'm attempting to integrate with a service that requires domain name presented
to match that of the cert. Where the use of dispatcher is probably not as
intended anyway as it targets the same set of destinations multiple times
(primary and secondary endpoints for the service im integrating with), with
multiple distinct set id's (basically a set per customer for multi tenancy)
which expects a sip ping per account to verify that connection is alive and
healthy.
#Example Dispatcher list
#Account 1
1 sip:a.cloudservice.com:5061;transport=tls 8 1
socket=tls:10.0.0.2:5061;ping_sni=sip.account1.com;ping_from=sip:sip.account1.com:5061
1 sip:b.cloudservice.com:5061;transport=tls 8 1
socket=tls:10.0.0.2:5061;ping_sni=sip.account1.com;ping_from=sip:sip.account1.com:5061;
#Account 2
2 sip:a.cloudservice.com:5061;transport=tls 8 1
socket=tls:10.0.0.2:5061;ping_sni=sip.account2.com;ping_from=sip:sip.account2.com:5061;
2 sip:b.cloudservice.com:5061;transport=tls 8 1
socket=tls:10.0.0.2:5061;ping_sni=sip.account2.com;ping_from=sip:sip.account2.com:5061;
Currently I'm running a solution based around certs with multiple SAN (subject
alternative name) defined, but this is a pain to administrate, and not as
scalable as I would like. I want to be able to define multiple client:any tls
profiles and explicitly send via that profile. Its easy enough to do that in
config using the tls xavps to define a server name and/or id. But for the sip
options ping by dispatcher to work you need to specify the server name or id
before the tm:local-request event route fire's.
I've resorted to hacking away at dispatcher to see what would happen if I set
the tls server name or id before the OPTIONS message is sent, and it works
great for the first tls client profile matched, but any others you define
re-use the initial tcp connection so reuses the first connections tls config,
thus presenting the wrong cert (I'm probably wrong but logs show only one tls
complete_init() related to dispatcher pings and the second set's pings skips
all the tls init logging so suggests some thing is cached/reused, and logging
on the service indicates cert name mismatch with set1s cert being offered)
So I've hit a bit of a dead end, is there a way to force a new tcp connection
per server name/id
I fear outbound SNI might be a bit of a can of worms, for it to work nicely
with dispatcher as is, would be an extension of the proto:host:port format to
include a name or id, maybe something like:
tls(name=sub.domain.com):10.0.0.5:5061
But that looks like it would have a lot of wide reaching knock-on effects, so
setting it as an attribute like ping_from works fine as I'm currently doing, if
I could force a new connection from dispatch.c....
The other thing that's occurred to me is that it might be better to stop trying
to adapt a small percentage of dispatcher's functionality and trying to hammer
a round peg into a square hole and instead try and create a new module similar
to dispatcher in so much that it sends pings (that's all I really need in this
case) and use dispatcher as intended with a single set of non-repeated
destinations for routing. This would also allow much simpler integration with
MS teams (if added ability to set contact address on the background pings) as
well as the service im trying to integrate, and a more natural data set to be
used as in my example you can see the only difference is the customers domain
between each set. How I would imagine it to work would be to create a tls
connection per customer domain, then iterate through the connections per
destination in pseudo json the data would look like this:
{
Destinations:[
[1,["a.cloudservice.com","b.cloudservice.com"]],
[2,["sip.pstnhub.microsoft.com", "sip2.pstnhub.microsoft.com",
"sip3.pstnhub.microsoft.com"]
],
Sources:[
{uri:"sip.account1.com",destinationMapping:[1]},
{uri:"sip.account2.com",destinationMapping:[1,2]}
]
}
And would just run in the background sending pings with SNI support, and if
based on dispatcher should make it easy enough adapt things like the
destination up and down event routes, and would allow me to use Kamailio much
like I would use nginx for web stuff as a reverse proxy and handle TLS offload
on my edge gateway proxy.
Any thoughts?, im frustratingly close to having something that will do if I
could get a new connection to be created, but I fear my use case might be
sufficiently different from dispatchers to make a new module a sensible
approach..
Regards
Tim.
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
