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
Example sip.conf
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:
[3090] 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
NOTE: If the certificate cannot be hosted on a server it can be imported via the Web instead using Interface Utilities > Import & Export Configuration > Import Configuration
Example:
<web device.set="1"
device.sec.TLS.customCaCert2.set="1"
device.sec.TLS.customCaCert2="-----BEGIN CERTIFICATE-----
MIIDmzCCAoOgAwIBAgIQb8NsaDS544FB4ejodIhkADANBgkqhkiG9w0BAQUFADBU
MRMwEQYKCZImiZPyLGQBGRYDbGFiMRowGAYKCZImiZPyLGQBGRYKc2JhaWVyaG9t
ZTEhMB8GA1UEAxMYc2JhaWVyaG9tZS1MWU5DTEFCMURDLUNBMB4XDTE1MDIyNTE2
NTIzNVoXDTIwMDIyNTE3MDIzM1owVDETMBEGCgmSJomT8ixkARkWA2xhYjEaMBgG
CgmSJomT8ixkARkWCnNiYWl1234512UxITAfBgNVBAMTGHNiYWllcmhvbWUtTFlO
Q0xBQjFEQy1DQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANnOj3I9
EZk6zEk+Kvh3oENoDkm8dmqzAWFeRAH5+lOA32oLBLpAL0KcyKqy74JvVACMB6O+
TFZsKJD2E7juypmH+/PESsiA/tT/sHwHTm9LDTLXE5M3U+tk1V2NK2Vh6/qcOobT
Rw9ahy0eNAKF6gbYJhUWtFHzD+D6W9cqKNm+8TEAq0AjrM5d6hAfemPp2ujNX2i/
MbmNzdaClaLVdEchmo73w9mbcgPdpP3pniuVtjAHsVGsn/LvaJkKHhaQyy1n1gRe
Hx5m5k9cSgVhS2ErgIM/zeeywBtO/jVRPRKM5e2ankHkVBAl5qwZUZS9KPYY1eF7
gjarZLhDsUGk4vECAwEAAaNpMGcwEwYJKwYBBAGCNxQCBAYeBABDAEEwDgYDVR0P
AQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFDSuIDNZzxycYm2D
TdvGoODxAyBMMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4IBAQA9
RBMvY+ACZtYTS5pJiQdJkXAtyCJxMwEWotbKReU/NTtL7vkLcHUxD2s0FE65RV81
QKknt5nalJnIAlYfNx6QBIBrPRsrVFNj6jdBCE7rGHKmnEcrS7xaF16zdgEoa7Gi
rrn4gqCFKQwzefra+STCuHlJGwqs+HgYvdGOQE+EPvf/w7GARlpoSF+4KiaHStPu
xOC/c995glbvGfPD2irv5La352cmpzCc7yYHRRweuW/tQ7Dgrv+qvjAKnwDz5sBh
2R0IpNqZxnPi/mm06iBYGKEyaYa72ATwGhtGy56jceAvZqw9515kxVes2Pb32hKN
WHOVLRfPFLfFu5ansXpP
-----END CERTIFICATE-----" />
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
Errors:
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, the Common name did not match the hostname.
We can get around this utilizing this Parameter:
sec.TLS.SIP.strictCertCommonNameValidation="0"
This can also be set on newer versions via the Web Interface Settings > Network > TLS:
Changing the default Cypher.
By factory we currently use:
ALL:!aNULL:!eNULL:!DSS:!SEED:!ECDSA:!IDEA:!MEDIUM:!LOW:!EXP:!ADH:!ECDH:!PSK:!MD5:!RC4:@STRENGTH
In order to change as an example the Platform Profile 1:
<web 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
If official support is required please check how to phone or open a case here
----------------