TLS configuration and budget-friendly phones (Denwa/XUE)

Asterisk Asterisk Endpoints
1

Hi everyone,

I am setting up Asterisk v22. I have already configured my trunk and the endpoints which include Grandstream GXP1628 phones, but mostly Denwa DW210P and XUE S3 models. Currently, they are operating via UDP, and I want to switch them to secure TLS communication. I have already enabled TLS in Asterisk and run a few small tests, but I have some questions about the process.

  1. Can I configure the phones with the main server using TLS port 5061 and the same server as the secondary option using port 5060? This way, during the migration, the phones could use either TLS or UDP, and once configuration is complete, I could simply force TLS communication via the dialplan.

  2. I am having trouble configuring TLS on the Denwa DW210P phones. Even after enabling the TLS option and setting the server port to 5061, I consistently see this error message:

[Sep 22 15:41:35] WARNING[2665685]: pjproject: <?>: SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <167772418> <error:0A000102:SSL routines::unsupported protocol> len: 0 peer: 192.168.xx.xx:1537

  • Is it possible that these “budget” phones do not good support TLS?
  • When I try to upload the ca.crt certificate, it ends up in the VPN section rather than the SIP TLS section; does anyone know if the certificate requires a specific filename or extension?

imagen
imagen745×400 6.38 KB

The configuration I have is this:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
ca_list_file=/etc/asterisk/keys/ca.crt
method=unspecified
cipher=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384
verify_client=no
verify_server=no

Endpoint template:

tpl-oficina
type=endpoint
host=dynamic
context=estandar
disallow=all
allow=alaw,ulaw
dtmf_mode=rfc4733
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
trust_id_outbound=yes
language=es
media_encryption=sdes
media_encryption_optimistic=yes
media_use_received_transport=yes
send_pai=yes
send_rpid=yes
rpid_immediate=yes
send_diversion=yes
transport=

I have successfully established communication over TLS using a Grandstream phone and the Blink softphone.

I updated the firmware to version 2.3.1747.471, but it still isn’t working; it is worth noting that these phones appear to be manufactured by Fanvil and customized by Denwa.

Thank you in advance for your help.

2

Isn’t the right place for get answer, better contact phones manufacturer support team.

3

error:0A000102 ... unsupported protocol is logged on the server side. It means the phone offered a TLS version that Asterisk’s OpenSSL will not accept, so the handshake fails before any certificate is checked. Many older Fanvil-based firmwares still offer only TLS 1.0 or 1.1, and OpenSSL 3 disables both by default (Debian and Ubuntu also raise the security level). That would explain why the Grandstream and Blink work and the Denwa does not.

Things to try:

  1. Set method=tlsv1_2 on the transport instead of unspecified. On our system, unspecified led to failed handshakes with “unsupported protocol” for some clients, and an explicit tlsv1_2 fixed it. Transports are not reloadable, so restart Asterisk after changing it.
  2. Check what the phone actually sends: tcpdump -i any -w tls.pcap port 5061, then look at the ClientHello version in Wireshark. If it is TLS 1.0 or 1.1, the real fix is phone firmware that supports TLS 1.2. Lowering OpenSSL’s minimum version on the server is possible but weakens TLS for everyone.
  3. Your cipher list only has ECDHE-RSA suites. That is fine for an RSA certificate, but an older phone may not offer either of them, so try it once with cipher removed.

About the certificate: with verify_server off on the phone side it usually does not need your CA at all just to register. Its certificate page normally has a separate “trusted certificates” upload, and that upload is not the VPN section.

On your first question: yes, one endpoint accepts registrations on any transport unless you pin transport=, so UDP on 5060 and TLS on 5061 can both work during the migration. To enforce TLS in the dialplan, ${CHANNEL(pjsip,secure)} tells you whether the signalling came in on a secure transport. When the migration is done, removing the UDP transport (or firewalling 5060) is simpler and safer.

Side note: host=dynamic is a chan_sip option. PJSIP ignores it, so you can drop it from the template.