All was well and good, until I presented the options of using TCP or TLS with the AudioCodes gateways we were deploying. The customer wanted to ensure that encryption was maintained through to the gateways. In virtually all deployments I have previously worked on, Microsoft PKI has been deployed internally. This just means taking the Certificate Signing Request (CSR) from the gateway and uploading it to the Certificate Services web page, then downloading the cert. I assumed the process for a public cert would be similar - that I could just log into the AudioCodes web interface, generate the CSR, and upload it to the cert provider's request page. This was definitely not the case.
Generating a CSR for a public cert provider requires that all of the organizational information be included in the request. When generating the CSR using the Lync cert wizard, you are prompted for all of this information. By default, AudioCodes does not.
The following steps are necessary to generate a CSR from an AudioCodes Mediant 1000 MSBG. I assume that the steps would be similar on other models, but cannot guarantee it.
Prerequisites:
- This has only been confirmed to work on gateways running firmware v. 6.20A.046.005 and up
Change the TLS Key Size:
Change the default key size for the CSR. By default, the gateway will generate a 1024-bit CSR. A 2048-bit key is now the default in Exchange and Lync, so we will update the CSR generated by the AudioCodes to match.
Connect to the gateway's advanced administrative page, typically http://<gwip or fqdn>/AdminPage (Note: the /AdminPage is case-sensitive)
Click ini Parameters on the left side
In the Parameter Name field, enter TLSPKEYSIZE
In the Enter Value field, enter 2048
Click Apply New Value
We then need to Generate a Self-Signed request for the change to take effect.
From the main Administrative page, http://<gwip or fqdn>, navigate to Configuration -> System -> Certificates on the left side
Enter the FQDN of the gateway into the Subject Name field
Click the Generate self-signed request button
Burn the configuration to memory
Generating the CSR with Organizational Info
Now that we've set the TLS key size, we can move forward with generating the CSR with the organizational info. This is buried in the engineering command shell.
Connect to the gateway engineering administrative page, http://<gwip or fqdn/FAE (Note: /FAE is case-sensitive)
Click Cmd Shell on the left side
In the Command Line box below, type cm to enter certificate management mode
Click Enter (or press Enter on your keyboard)
Once in certificate management mode, type cm csrint into the Command Line box to generate a CSR in interactive mode
Click Enter (or press Enter on your keyboard)
You will then be prompted for the relevant organizational information (Country, State, City, Company, OU, etc.) within the Command Shell.
Once all of the information has been entered, the CSR will be output within the Command Shell window.
Copy this information and paste it into a text file or directly into your provider's request form.
Upload the Newly Generated Certificate
Once you have received the certificate package from your cert provide, simply upload the file just as you would if you had requested it from an internal CA.
From the main Administrative page, http://<gwip or fqdn>, navigate to Configuration -> System -> Certificates on the left side (just as we did above).
Under Certificate Files, click Choose File under the "Server Certificate" section
Select the certificate you downloaded from your Public CA (you may have to change the File Type drop-down to All Files).
Click Send File (Note: It will state whether or not the file was uploaded properly only the first time. From what I can tell, there isn't an easy way to validate the cert at a glance from here.)
Perform these same steps for the Root CA certificate under the "Trusted Root Certificate Store" section
Note: Nothing is uploaded to the "Private Key" section since the gateway already has the private key associated with the certificate. I have also not found a good way to backup/export the certificate with the private key for recovery purposes later.
Conclusion
I know when I was trying to figure this out, there was no information publicly posted on the web. This was somewhat of a unique situation where we were deploying Enterprise Voice functionality when a customer did not already have PKI deployed internally. Hopefully this helps if you happen to be in the same situation.
Please feel free to leave comments or questions below.
-Phil
The details above are for v6.2, all of these issues have been addressed at v6.4 (which has been available since June 2011).
ReplyDeleteThe 6.4 GUI is significantly easier to use, and there's no need to jump around all those pages.
Thanks for the info Freezer. I'll check it out. Odd that the AudioCodes engineer I worked with on this issue didn't mention this. The Mediant 1k was only deployed earlier this year (2012), so if this was publicly available I assume we would have upgraded to that rev. I'll follow up with him or my SE and verify this. Thanks.
ReplyDelete-Phil
I'm configuring a very similar setup with AudioCodes and TLS between Lync. Did you just add the DNS name of the gateway as a subject alternative name on the Lync certificate? I'm just not sure how to get the certificate right on the Lync server and make sure TLS is configured correctly.
ReplyDeleteCheers.
Hi Kieran,
DeleteI do not believe the AudioCodes gateways support a SAN certificate. If you follow the instructions above, you'll see that we actually generated the CSR from the gateway directly.
The certificate on the Lync server only contains names relevant to the Lync server itself. See this article for the certificate SN/SAN best practices for both Standard and Enterprise Edition deployments.
http://technet.microsoft.com/en-us/library/gg398094.aspx
Let me know if you need further clarification.
-Phil