SAN on Session Manager

[bankingguy]

Hi,

I want to put an identify CA on my Session Manager but i have some doubts what am i going to define on the following:

Common Name (eg, your name or your server's hostname) []

and the below:

SAN:
DNS.1
DNS.2

My thoughts below:

Common Name (eg, your name or your server's hostname) []serverAname.myofficedomain.com
SAN:
DNS.1 = serverAname-sm100.myofficedomain.com
DNS.2 = serveArname.myofficedomain.com

 

[kyle555]

Yeah, but SAN2 would be wrong - that'd be the FQDN of the MGMT interface of the SM. You'd put something like "sipserver.domain.com" if you wanted to point people to a friendlier name in DNS.

Or, say you do split DNS on the public side for SBC remote workers - you could call sipproxy1.domain.com to public IP XXXX and inside resolve to the SM100 IP. As long as your endpoints point at sipproxy1.domain.com, they'll get a cert with a SAN of sipproxy1.domain.com from SM and pass extended hostname validation.

 

[bankingguy]

one of my concern is the DNS.1, does it have to be written this way? DNS.1 = serverAname-sm100.myofficedomain.com - yes or no? I want to understand if the common name input and SAN DNS.1 input should be the same? is it really mandatory to put "-sm100" in these field?

For DNS.2 = I believe it can be the mgmt interface.

 

[kyle555]

You know better than to ask yes or no questions It depends!

In my opinion, Avaya didn't clearly explain how TLS works and how to do it in Aura. Something straightforward of a reference for us phone guys who don't know how certs work.

So, here's the deal. When you set up a SM - like mylabsm.lab.com, I give a FQDN to the management IP. Note that when you build your SM in SMGR you add an IP for the SIP entity, but nowhere do you ever need to configure an FQDN to point to the security module. SM decides to make mylabsm-sm100.lab.com the FQDN for it's SM100 certificate.

Now, if my SM100 had IP 1.1.1.1 and I only ever SET SIP_CONTROLLER_LIST 1.1.1.1:5061;transport=tls, my phone would get the cert, and it's the same thing as when you get to a webpage that says "can't validate server identity bla bla bla" like when you punch in the IP of your CM in your web browser. That's cause the cert is issued to a FQDN and you went to reach it via the IP address.

That's what the TLSSRVRID parameter is for - if not performing identity matching, then it's like when the phone sees that warning that it can't validate the certificate for mylabsm-sm100.lab.com because the phone pointed directly to 1.1.1.1 it just clicks OK and carries on.

## TLSSRVRID specifies whether a certificate will be trusted only if the
##  identity of the device from which it is received matches the certificate,
##  per Section 3.1 of RFC 2818.
##  Value  Operation
##    0    Identity matching is not performed
##    1    Identity matching is performed (default)

If that TLSSRVRID were enabled, then when the phone sees SET SIP_CONTROLLER_LIST realfqdn.lab.com, the phone expects to connect to realfqdn.lab.com and get a cert that has a SAN for realfqdn.com. As FQDN, you're welcome to just add mylabsm-sm100.lab.com into your DNS and SET SIP_CONTROLLER_LIST mylabsm-sm100.lab.com, or you can have a different name or multiple names and multiple SANs. To say, you could leave the sm100 name in there and add another like sipproxy1.lab.com. As long as sipproxy1.lab.com points to 1.1.1.1 in DNS too, then the SM having the 2 SANs would satisfy identity matching for endpoints reaching it via either FQDN.

For Avaya phones, it doesn't matter so much, it's all a moot point if you disable identity matching. But you don't have that luxury on iPhones or other soft clients.

As far as common name, it's good practice to make it the real fqdn, but it's been deprecated for years. Lots of things will still accept a cert with CN only and no SAN - even though it should be looking at SAN only. So for everything I just said, you'll only pass identity validation if there is a SAN matching the FQDN, most every client should consider CN irrelevant.