SMGR issues certificates to SM
So, asm.yourcompany.com gets a cert from the authority of smgr.yourcompany.com and asm would accept certificates signed by smgr.yourcompany.com to set up TLS connections.
So, if you make a cert for phones.yourcompany.com and push that in a settings file, or if you set up SCEP where each phone enrolls for a cert per serial number, then SM would accept those certs to set up TLS.
Peek in "inventory" and tick off "sm" and "more actions" check your trusted and identity certs to see what I mean.
While the implementation is about the same, different devices have different standards or levels that can be tweaked about how secure they really end up being. So, as SHA1 became deprecated, IE, Firefox and Chrome would show a HTTPS connection with a red line thru it saying it wasn't secure anymore, and it was up to Google or Mozilla or MS to decide exactly when they would decide to make their browser show you that. On that note, an Avaya phone just needs its certificate to present to the SM.
The certificate can also be used for lots of different things. Go to facebook or amazon, view the certificate, and look at the 2nd tab in details and under "key usage" and "extended key usage" to see what the cert can be used for. Usually it's client and server authentication, but it can also be for data encipherment. To say, the cert could just be to prove your identity, or it could also be a factor in how the data is encrypted. The Audiocodes in fact does do that. Avaya phones can be set up to also further validate the certificate. See this link, and "TLSSRVRID" in the settings file.
So, the Audiocodes has it's own generated private key that can be used to create a request - or you can make another one.
So, at the most basic level. Go into any Linux box with openssl and...
openssl gendsa -des3 -out private.key
This will have openssl make a key. It makes you specify a password.
You can either do it this way, or grab the private key already in the Audiocodes box and put it on the Linux one and call it "audiocodes.key"
openssl req -new -key private.key -out audiocodes.csr
This will make a certificate signing request from the key you specified. Enter the password from the previous step, and fill out the fields, or use a period as a blank. The CN/common name will be who the certificate is issued to - so, maybe "myanaloggateways" or "thisuniqueaudiocodesdevice.yourcompany.com"
The output of that will be a signing request called "audiocodes.csr". If you "cat audiocodes.csr" or "more audiocodes.csr", you'll get the request in text form, and you can copy the whole thing (even the begin here and end here parts) into a certification authority - like the EJBCA in System Manager.
That's where you'd go through my other post, setup a TLS profile and user/pass in the EJBCA when you "add end entity" and try to match up all the info in there that you put in the CLI for your signing request. Then go to the public web and enter your user/pass and contents of the request in the text box and SMGR will sign the certificate for you.
You'd need to download SMGRs CA cert (the cert that signs your audiocodes cert), the audiocodes cert you had SMGR issue and the private key. Pop those in the audiocodes and you should be fine. Look at your debug logs for TLS handshake failures
great thanks a lot,I'm going to make another appointment with the customer