ASBCE and third-party certificates

[johnofsometrades]

Hello everyone!

I am hoping that someone in this community can help me understand how to set up third-party certificates with the ASBCE in an Aura environment. I understand x.509v3 certificates, certificate authorities, trust stores, etc. quite well. But I am new to the world of telephony (both "red" and "blue").

To summarize the main thing I'm having trouble wrapping my head around: what subject common name and subject alternative names should the security certificate contain? In other words, what DNS FQDNs do I need to include in a certificate signing request I submit to a certificate authority?

My environment has: two Session Managers, two Communication Managers, two Utility servers, a high-availability SBCE setup (2 x SBC + EMS), one System Manager, one Presence, one WebLM, and one AES. I know that split-horizon DNS is required so that clients resolving a hostname will get either the internal IP address or the SBC's floating untrusted IP address as appropriate. I'm not sure which services (and thus hostnames) have to be publicly-resolvable to the SBC, and therefore need to be included in the certificate offered up by the SBC. (If the correct answer is "all Aura FQDNs", my take-away would be "wow, I need to replace the certificate for any change such as adding a second Presence server or a third Session Manager".)

To date, our business partner has not been super-helpful in providing a definitive answer (i.e. they don't know), and Avaya is offering nothing except APS (professional services) for a huge sum of money.

I'm happy to supply more information as needed to help answer my questions. Thanks!

 

[jtc22]

I am on the same stage as you are. We purchased 3rd-party public certs for our SBCE with Subject Alt Name the DNS: sbc.domain.local however we're still getting a certificate error once the certs are installed. The certificate seems to be looking on to the SBC management IP address which is a private IP.

Struggling with Avaya support as well as it seems that they don't really have a consistent guide deploying certificates.

 

[kyle555]

I would think that you'd use the fqdn that the resolves to the outside interface of the SBC people would connect through.

Now, I've tried to do this in my lab unsuccessfully to date. What are you trying to do? Setup remote workers or TLS SIP trunks?

At the end of the day, I think this is all for client authentication and not server authentication like HTTPS for web sites. To say, the authority that issued you your cert must be the same as the thing you're trying to send SIP TLS to.

Avaya phones SIP firmware has a cert issued by the default Avaya CA on them. Session Manager can accept TLS connections from clients with a cert from the same CA.

Basically, you'd need a GoDaddy cert for phones, a cert for the SBC, for SM, for Presence, etc that all the elements would validate up to GoDaddy to realize they're part of the same security domain. Now, that's probably a bad idea because I'd be able to put my godaddy cert from my webstore into my phone and get a login prompt connecting via TLS to your environment. As far as I understand it, the whole point of it is that you'd be managing the security architecture top to bottom and be in control of who has and can't have certs signed by your CA.

I could be off, but either way, this is a good discussion for us all to have!

 

[johnofsometrades]

@jtc22, what's the subject CN for your certificate? Who is the issuer? I wonder if your client(s) are still encountering an untrusted certificate even though you purchased a third-party certificate. Was there perhaps an intermediate certificate(s) that need to be installed on the SBC in order for the client to verify the certificates up to a trusted root certificate authority?

I did find this document from Avaya:

https://downloads.avaya.com/css/P8/documents/100180626

But even after reading through it, it's still unclear to me as to which CN and SANs need to be specified in a certificate. I'm not as concerned about internal interfaces between "red" systems that talk to each other -- I just want clients to not have to deal with "untrusted certificate" issues, i.e. all client-facing interfaces should have a third-party certificate installed.

In Avaya one-X Communicator, we specify the two Session Managers in the "Server List" and also the Presence server under "IM and Presence". So it seems to me that at a minimum, these DNS FQDNs have to be configured for split-horizon DNS (internal view: internal IP address, external view: SBCE IP address) and need to be specified as subject alternative names in the SBC's certificate. But I don't know what (if any) other FQDNs need to be included. For example, I don't think the Communication Managers are explicitly specified anywhere on the clients, but as the feature servers, I am wondering if those also need to be included (here I am exhibiting my lack of knowledge of the "red" world).

@kyle555, I don't know that we would use the FQDN of the SBC's outside/untrusted interface anywhere e.g. "sbc.example.com". My understanding is that clients should be configured to use the Session Manager FQDN(s) e.g. sm.example.com, and DNS takes care of whether the client is talking directly to SM, or via the SBC. Our motivation (at this point) is to support remote/mobile users (SIP trunks are a future endeavour). For example, a user with the one-X Communicator soft client installed on a laptop, or a user with a cell phone and the one-X Mobile or Communicator app. They need to be pointed to the Session Manager and it needs to work whether they're in the office or elsewhere without having to reconfigure the software (hence the split-horizon DNS requirement).

We don't want mobile clients to have to jump through the hoops of installing/trusting the built-in certificate or a self-signed certificate we generate. The purchase of a third-party certificate signed by a CA that's in the trust store of Windows/Mac OS/iOS/Android/etc. clients is the ideal solution. When I conducted testing several months ago with my iPhone, I had to do the following in order to get iOS to trust the built-in certificate for Communicator to work: use my Windows computer to connect to SM via my web browser on TLS port 5061; export the certificate (CN=SM100); e-mail the certificate to myself as an attachment; open the e-mail on my iPhone and click on the attached certificate; install/trust the certificate to make it show up as a "Configuration Profile" under the "General" settings. Only then could I connect to the Session Manager using Communicator. I thought it to be patently absurd to expect any end-user to follow those or similar steps.

 

[kyle555]

Fair enough, yea, the SM100 FQDN should be the thing that resolves to SM100 inside and the SBC outside, but the point about the certificate and mobile device management remains - the purpose of the certificate isn't like you logging into a bank's website and the certificate lets the client know the server is trustworthy, it's the other way around where the cert is intended to let the SBC know your phone is trustworthy.

Ultimately, I don't think it matters what FQDN/CN/SAN is in the cert for the SBC - it won't be validated in the context of a secure https connection. It would work just like the default certificates with the SIP phones and Session Manager.

Either way, you're going to need to load certs on every device that connects in to your network. Those hoops you don't want people jumping through are the elements that actually secure it!

 

[johnofsometrades]

@kyle555, perhaps I'm showing how wet I still am behind the ears with Avaya "red", but I disagree -- the way the Communicator client is behaving appears to me as exactly what a web browser does when visiting a secure web site. The server offers up its certificate to the client, and the client decides whether it trusts the server's certificate or not (based on the client or web browser's trust store). In the overwhelming majority of situations dealing with SSL/TLS encryption, a client never offers a certificate to the server for mutual (two-way) authentication.

I'm not sure why the SBC would need to trust the phone in terms of requiring a client certificate. A SIP login to the Session Manager is required and that would be sufficient to authenticate a client (just as with secure web sites). If each phone needed a certificate in order to be trusted by the SBC it would be pretty easy to steal/copy the private key from any trusted phone, to make an untrusted client, a trusted one.

The Avaya document I linked to is titled, "Updating server certificates to improve end-user security and client user experience". It's all about server certificates, not client certificates, describing (at a high level) exactly what I want to achieve to make the end-user experience smoother. With a trusted, third-party certificate, clients should not need to deal with certificate warnings or importing a built-in/self-signed certificate.

 

[kyle555]

I think we're on the same page with it. My point is that you're not even going to get a login prompt unless the sbc and clients agree on a certificate. That's not to say every person or phone needs a certificate. I've seen a certificate made out to "people" that get used to setup TLS with various things in the enterprise. I still have to authenticate, but that cert makes sure only those who were provided the certificate would even get as far as a login page.

Now, with SM, you can just export the trusted cert made out to youSM.yourdomain.com when you install it and load those up on phones. The current One-X Communicator and mobile apps don't let you use the default Avaya certificate for TLS anymore as far as I know.

Because the SBC is a security device, I think it's going to want the private key to be able to decrypt the traffic phones are sending it, but as far as I've seen, you're going to need to load a certificate specific to your environment on the soft clients to get TLS working the way you'd like. If you want to see if the mobiles will use their own Godaddy trusted CA cert to try and authenticate, maybe just try internally by making a godaddy cert trusted by your session manager and see if they'll login with only that added to anything.

 

[Wanebo]

johnofsometrades is correct in saying "The server offers up its certificate to the client, and the client decides whether it trusts the server's certificate or not"

I remember trouble shooting an issue where phones were not load balancing after a ASM upgrade. The first ASM side upgraded went fine, but a couple of days later when the second side underwent the same upgrade the APS engineer missed the step of loading the Avaya default certs and brought in a self signed cert from the SMGR. No phones would register to that side. When we did a TraceSM and filtered for TLS Handshaking you could see the ASM was sending a cert it received from the SMGR and since the phones had no clue about that cert they simply rejected it and waited for the Avaya default one that they knew about from the other (their secondary) ASM registrar. That one they would send the return message that they found the certificate acceptable and started exchanging data. The phones never sent any certificate back to either ASM.

 

[kyle555]

@Wanebo - I agree except for the part where they wait for the Avaya default certificate "that they knew about from the other ASM" - the hardphones have that cert baked into the firmware. I don't believe soft clients let you do that anymore. You could have equally set the SM cert signed by SMGR in the settings file and had the hard phones take that, which I think is the approach needed to interop with the SBC

 

[johnofsometrades]

Avaya Communicator for iPhone v2.1.2.6 accepts the default cert for SM after I install the cert. That's what I described above about installing the cert with subject CN=SM100 into my iPhone's configuration profile.

The Avaya document I linked to does state that in the future, the built-in/demo certificates won't be accepted. I'm not sure if this means the current situation of "won't be accepted by default, unless you install the certificate" or "won't be accepted even if you explicitly trust the cert by installing it". But in the not-too-distant future, the certificate should be rejected outright regardless because the demo certificate uses the SHA-1/RSA signature algorithm, and this is deprecated. The CA/Browser Forum ruled that certificates using SHA-1/RSA cannot have an expiry past 2016-12-31 and all the major web browsers are increasingly rejecting weak crypto leading up to 2017-01-01.

Circling back to my original question, it's about knowing what FQDNs have to be defined as SANs in a certificate to specifically be installed on the SBC. Again, I don't want to have to import/install a certificate on any client devices (or give complicated instructions for users to do it themselves). I would like to use a third-party certificate that's implicitly trusted by clients via their built-in trust store. I work at a public university with no little-to-no endpoint or mobile device management capability because there's a lack of policy for university-owned equipment, and then the rest is BYOD. Otherwise we could just as easily distribute our own root CA certificate onto managed devices as going the third-party commercial CA route.

Surely somebody is successfully using third-party certificates on an SBC? (As a side note, Avaya themselves are not...their certificate contains subject CN=Avaya SBC Edge, i.e. not a DNS FQDN, with no subject alternative names, and is not issued by a third-party CA. You can check for yourself, as sm.avaya.com is publicly-accessible on the Internet. They have their employees install/trust the certificate on each client device e.g. cell phone. So maybe Avaya themselves are finding it too complicated to set this up )

 

[kyle555]

Page 19 of this doc:

https://downloads.avaya.com/css/P8/documents/100180524

indicates that demo certs are no longer included in SM - they can be enabled in 6.3 with initTM -d, but I don't know if that carries over to release 7. In any case, their idea is that you deploy your own certs

 

[johnofsometrades]

I had found this other thread:

http://www.tek-tips.com/viewthread.cfm?qid=1763962

Referring to this Avaya SOLN287755 document:

https://support.avaya.com/ext/index?page=content&id=SOLN287755

But unfortunately it is also not explicitly clear about the DNS FQDNs that should be specified in the third-party certificate.

At this point I think it's just the Session Manager and Presence Server FQDNs (and I guess the multimedia messaging server if used in the environment) that need to be specified as subject alternative names in the CSR to be signed by a third-party certificate authority, but it would be nice to get confirmation of this