Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Avaya client gets certificate from AADS
- Thread starter M3A
- Start date
jimbojimbo
Vendor
Going with a public certificate for each endpoint is going to be very expensive. Use a certificate from System Manager. You can load the System Manager CA cert chain into the SBC and use it for peer validation. Just make sure you have the correct depth set. Using Mutual Authentication (client validation) gives you another level of security.
The term "client" is very obscure. For Avaya Workplace (formerly Equionox) clients on Windows life is relatively easy. You can issue personal certificates through Microsoft using auto-enrollment (assuming they have network access). Note the Microsoft setup will need to make sure the key is exportable. Otherwise you can create the certificate and provide it to the end user in a PKCS12 (cert/key/chain) for them to use.
For hard phones, Avaya has provided Device Enrollment Services (DES). Documentation could be better however you zip up the 46xxsettings.txt file, CA certificates for the phones, any PKCS12 files, and upgrade script files (needed for the phone to then get to the 46xxsettings.txt) and load them into DES.
Alternatively for hard phones you can use SCEP on-net then send them off-net. Microsoft SCEP will need to be configured for password re-use and you may have to read up on the SCEP settings in the 46xxsettings.txt file. Starting with System Manager 8.1.3 you can use System Manager as your SCEP server (although I haven't tried it yet).
The term "client" is very obscure. For Avaya Workplace (formerly Equionox) clients on Windows life is relatively easy. You can issue personal certificates through Microsoft using auto-enrollment (assuming they have network access). Note the Microsoft setup will need to make sure the key is exportable. Otherwise you can create the certificate and provide it to the end user in a PKCS12 (cert/key/chain) for them to use.
For hard phones, Avaya has provided Device Enrollment Services (DES). Documentation could be better however you zip up the 46xxsettings.txt file, CA certificates for the phones, any PKCS12 files, and upgrade script files (needed for the phone to then get to the 46xxsettings.txt) and load them into DES.
Alternatively for hard phones you can use SCEP on-net then send them off-net. Microsoft SCEP will need to be configured for password re-use and you may have to read up on the SCEP settings in the 46xxsettings.txt file. Starting with System Manager 8.1.3 you can use System Manager as your SCEP server (although I haven't tried it yet).
- Thread starter
- #4
Thanks Kyle and Jimbo for your replies 
To be honest I'm not fully aware or understand security and TLS handshaking!
When I try SMGR certificate (I install SMGR pem cert file on client device) or public certificate (don't install any cert on client), but there is no MTLS as SBC TLS server profile (peer verification is set to none), so I can see client sending certificate () on SBC trace..
when I use SMGR cert and enable peer verification, client can't register and experience cert error.
Avaya documents show no peer verification needed for TLS server profile, and also for subscriber flow no TLS client profile administered!
So I'm confused with security concept here and the whole scenario..
To be honest I'm not fully aware or understand security and TLS handshaking!When I try SMGR certificate (I install SMGR pem cert file on client device) or public certificate (don't install any cert on client), but there is no MTLS as SBC TLS server profile (peer verification is set to none), so I can see client sending certificate () on SBC trace..
when I use SMGR cert and enable peer verification, client can't register and experience cert error.
Avaya documents show no peer verification needed for TLS server profile, and also for subscriber flow no TLS client profile administered!
So I'm confused with security concept here and the whole scenario..
Certs are first for the server to prove its identity to the client. That's the same for SBC to phone or Amazon.com to Chrome.
If you're in a highly secure environment, or inside an enterprise with all the machines - cell phones included - joined to a domain with identity certificates, you can use peer verification/mutual TLS authentication.
That way, your SIP remote worker setup won't esablish a handshake with the client unless the client in certmgr.msc has an identity certificate provided by the company for them. Then, you'd be trusting the company's CA cert in the server profile. That way you'll never get INVITE:01145411231231232132@yourPublicIP coming into your SBC - the hackers don't have a cert issued by TheCustomer.com's private internal CA.
You can use that, but as a pre-requisite you'd have to have all the endpoints with an identity cert. If the deployment use case was laptops for work from home but those laptops are joined to the domain or otherwise administered centrally, then it's as easy as you adding the company CA cert to trust for peer verification.
But we don't want to get too far into that - give them the MSI for IX Workplace, let them automate deployment of the client, use Zang to autoconfig based on email address to AADS and you're done as far as managing end user client configurations. If they already have identity certs on each machine and want to bring it to the table, sure, but they've already done the heavy lifting.
Don't forget to read and follow the security best practices for 8.0
If you're in a highly secure environment, or inside an enterprise with all the machines - cell phones included - joined to a domain with identity certificates, you can use peer verification/mutual TLS authentication.
That way, your SIP remote worker setup won't esablish a handshake with the client unless the client in certmgr.msc has an identity certificate provided by the company for them. Then, you'd be trusting the company's CA cert in the server profile. That way you'll never get INVITE:01145411231231232132@yourPublicIP coming into your SBC - the hackers don't have a cert issued by TheCustomer.com's private internal CA.
You can use that, but as a pre-requisite you'd have to have all the endpoints with an identity cert. If the deployment use case was laptops for work from home but those laptops are joined to the domain or otherwise administered centrally, then it's as easy as you adding the company CA cert to trust for peer verification.
But we don't want to get too far into that - give them the MSI for IX Workplace, let them automate deployment of the client, use Zang to autoconfig based on email address to AADS and you're done as far as managing end user client configurations. If they already have identity certs on each machine and want to bring it to the table, sure, but they've already done the heavy lifting.
Don't forget to read and follow the security best practices for 8.0
- Thread starter
- #6
Hello Kyle, thanks again .. I got ur point of view .. let's say I'm going with SMGR root cert and want to enable peer verification for server profile, what cert needed to be installed on client side? is it smgr root cert? and do we need a key or another cert installed additionally?
Another point, is it possible save cert to aads trust store where client can be prompted to choose and download it? i checked trustcerts option but not helping..
Another point, is it possible save cert to aads trust store where client can be prompted to choose and download it? i checked trustcerts option but not helping..
- Status
Similar threads
- Locked
- Question