Results 1 to 2 of 2

Thread: QX SIP - TLS CA Root Certificate

  1. #1

    Default QX SIP - TLS CA Root Certificate


    When using Epygi's CA Root Certificate for SIP TLS connections, it validates only when connecting locally, but when using remote extension (through Internet), it doesn't validates with error logs saying...

    Certificate: Names mismatch
    Certificate expected name: (My public IP or Domain if used)
    Certificate actual name list: (QX-WAN IP).

    I'm using WAN port for IP-Phones, (NOT LAN) and 5061 TCP port forwarding. Softclient used for testing: Zoiper

    The thing is that no matter what is used at the CN= field to generate the certificate within the QX, it always applies only the current Epygi's IP as the Certificate Subject CN. The .crt certificate generated doesn't add the others SIP domain aliases configured to the certificate, like SAN (Subject Alternative Names). Because of this if I'm using any domain or ddns to connect to my public IP to established the SIP connection from the Internet, can't make it work, because will never match the Subject CN applied at the certificate. That's why somehow it makes sense that TLS works when connecting locally because Epygi's IP is used to establish the connection and that's what is applied always to the Subject CN in the certificate.

    Maybe it could work if I used the WAN interface exclusively for remote connections and assign to it my public IP. Still, that limits the possibilities of connections to any desired domain or DDNS. Also is common that environments already had a firewall using the only available public IP.

    I could be doing something wrong, and I'm no expert in OpenSSL, nor Certificates, but will appreciate to know if there's a simple way to make it work and have a secure TLS way to connect devices from the Internet using any desired Domain or at least the public IP that is not assigned to the QX.

  2. #2


    Hi. Think I found the answer with ABP support and want to share it.
    As confirmed by support, QX still cannot manage the certificate behind a NAT. IP Phones interface need to be placed directly to public network as the self-signed certificate generated will apply the current IP assigned to that interface as it showed in my test.
    If there's a NAT (outside the QX), and certificate is verified within the connection, the mismatch will occur because of the CN parameter. Epygi is working to provide the self-signed alternative for scenarios behind a NAT.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. asterisk with tls and srtp
    By grietjeadmin in forum Hardware Interoperability
    Replies: 1
    Last Post: 01-14-2013, 04:08 AM
  2. CA Root Certificate TLS/SSIP
    By cherepa in forum Troubleshooting and Problems
    Replies: 13
    Last Post: 01-05-2013, 11:14 PM
  3. 2X can not call phone TLS
    By in forum Troubleshooting and Problems
    Replies: 1
    Last Post: 05-21-2012, 07:44 AM
  4. TLS Problem
    By walid in forum Tips and Tricks
    Replies: 5
    Last Post: 09-29-2011, 02:45 PM
  5. SRTP & TLS
    By threebit in forum General Discussions
    Replies: 1
    Last Post: 12-20-2006, 08:45 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts