The example below is based on Digium Asterisk 1.8. Polycom cannot provide support on Asterisk
Below was tested with a VVX500 running UCS 4.1.3
Source for certificate creation => here <=
NOTE: Please contact your SIP Platform provider or your Polycom reseller for any support queries! Knowledge in Linux and Asterisk is required.
Step 1 Creating a Server Key on the Asterisk server:
We now sign our own certificate by running the following command:
Step 2 changing the Asterisk configuration
tlsenable=yes tlsbindaddr=192.168.0.1 (put your actual ip address of your box here) tlscertfile=/etc/asterisk/certificates/asterisk.something.com.pem tlsdontverifyserver=no tlscipher=DES-CBC3-SHA tlsclientmethod=tlsv1
and in addition within the context of an individual phone add the tls option:
 host=dynamic type=friend username=3090 secret=3090 callerid="Steffen 11" <3090> progressinband=no callgroup=2 pickupgroup=2 call-limit=10 mailbox=3090 transport=tls
After above steps reload Asterisk
Step 3 Importing the certificate to the phone:
The Platform CA certificate 1 has a size restriction of 1536 bytes but platform the CA certificate 2 is higher at 4096 bytes.
The size restriction is for legacy software backwards compatibility so customers downgrading from 4.x.x will be able to retain the platform 1 certificate due to the fact that older software only allowed 1 custom CA certificate of size 1536 bytes.
0209142147|tls |*|00|Saving new Custom platform CA certificate 1 0209142147|tls |*|00|New Certificate Common Name '10.252.75.203' Fingerprint 'E3:E4:08:88:23:05:DE:D1:6A:3D:21:5C:9E:03:D3:60:86:7F:24:0C' 0209142147|tls |*|00|No previous certificate stored
Step 4 Troubleshooting using Wireshark:
Step 5 Using Polycom logs to troubleshoot TLS issues
1206175452|sip |2|00|MakeTlsConnection: SSL_connect OK : TLS Handshake completed successfully 1206175452|sip |3|00|[TLS] Validating Subject Alternative Name(s) (SAN) and Common Name (CN) against the following: 1206175452|sip |3|00|[TLS] Hostname: 10.252.122.122 1206175452|sip |3|00|[TLS] Outbound Proxy: 10.252.122.122 1206175452|sip |3|00|[TLS] Hostname connection: NONE 1206175452|sip |3|00|[TLS] Attempting to validate certificate Common Name (CN) 1206175452|sip |3|00|[TLS] Certificate Common Name matches server host: '10.252.122.122' 1206175452|sip |3|00|[TLS] Server Certificate SAN or CN validation success. SSL verify result 0 1206175452|sip |1|00|MakeTlsConnection: post_connection_checks passed 1206175452|sip |3|00|MakeTlsConnection: connection succeeded
1724612.165|sip |4|00|[TLS] Server Certificate Common Name 'name' doesn't match any of the following: 1724612.165|sip |4|00|[TLS] Hostname: 10.20.30.40 1724612.165|sip |4|00|[TLS] Outbound Proxy: 10.20.30.40 1724612.165|sip |4|00|[TLS] Hostname connection: NONE 1724612.165|sip |4|00|[TLS] Server Certificate SAN or CN validation failed 1724612.165|sip |4|00|MakeTlsConnection: connection failed error 1
In the above name the Common name did not match the hostname.
We can get around this utilizing this Parameter:
This can also be set on newer versions via the Web Interface Settings > Network > TLS:
Changing the default Cypher.
By factory we currently use:
In order to change as an example the Platform Profile 1:
<test device.set="1" device.sec.TLS.profile.cipherSuiteDefault1.set="1" device.sec.TLS.profile.cipherSuiteDefault1="0" device.sec.TLS.profile.cipherSuite1.set="1" device.sec.TLS.profile.cipherSuite1="ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384"/>
The above forces as an example TLS 1.2
Decrypting a Wireshark Trace if the Certificate cannot be shared:
Usually if a Customer can provide a trace but cannot share the certificate used to decrypt the trace they can share the session key instead.
Following above Step 4 simply ask the Customer to go to Wireshark, select File > Export SSL Session Keys, and save the file
Then open the Customer trace and then in Wireshark Edit > Preferences > Protocols > SSL > (Pre)-Master-Secret log filename, and select the exported Session Keys