Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


SAN on Session Manager

SAN on Session Manager

SAN on Session Manager


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:


My thoughts below:

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

RE: SAN on Session Manager

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.

RE: SAN on Session Manager

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.

RE: SAN on Session Manager

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 and I only ever SET SIP_CONTROLLER_LIST;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 it just clicks OK and carries on.

CODE -->

## 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 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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close