Troubleshooting SSL/TLS (HTTPS) Connection

Issue Description

I've followed the setup article for the SSL/TLS connection but it still isn't working. What steps can I take to troubleshoot?

Steps

Verify the creation of nginx

1. After configuring the SSL proxy and restarting services you will need to wait approx. 5 minutes for the server to create an nginx task in the task manager.
   • You can also monitor the Chronicall/ACR folder for a new nginx folder to be created which should contain an nginx.pid file once complete
     • The Chronicall folder is typically found:
       • Windows
         • C:\Program Files (x86)\Xima Software\Chronicall
         • C:\Program Files\Chronicall
       • Linux
         • /var/lib/Chronicall
     • The Avaya Call Reporting folder is typically found:
       • Windows
         
         • C:\Program Files\Avaya Call Reporting
       • Linux
         • /var/lib/Avaya Call Reporting
2. If those files are present then move onto the next step

NOTE: If the nginx folder is missing files, simply name it to nginx.old and then restart all services to recreate.

Check if nginx has bound to the correct ports

1. Open a command line and use the following commands
   • Windows
     

     • netstat -an | Find "80"

     • netstat -an | Find "443"

     • netstat -an | Find "9443"

   • Linux

     • netstat -an | grep "80"

     • netstat -an | grep "443"

     • netstat -an | grep "9443"

2. Verify that you are seeing those ports as "Listening", usually will look like 0.0.0.0:80 
3. If you do not, then there may be another webserver on their system bound to 80, 443 or 9443
   • NOTE: It is a hard requirement before someone can use our proxy that they have no other webserver on their system bound to 80 or 443. They will need to change that other webserver.
   • NOTE: On version 4.4.0 and above, the port 9443 has changed to port 8443

Alternate method for checking bound ports (Windows only)

1. Open Windows PowerShell on the Chronicall server
2. Copy and paste the following command into the Windows PowerShell window:

   • Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess,@{label="Name";expression={(Get-Process -Id $_.OwningProcess).Name}}

     • This command should display all currently listening ports on the system, which should allow you to identify if any of the ports that nginx is failing to bind to are currently being listened to by a different process.
   • In this example, the end user's nginx logs were throwing the following error, specifying that nginx could not bind to port 80:

     • 2021/10/28 20:52:16 [emerg] 10148#2308: bind() to 0.0.0.0:80 failed (10013: An attempt was made to access a socket in a way forbidden by its access permissions)

   • Running this command, we found that port 80 was listening for a different process called 'System' under Process ID (PID) 4:
     
     
     
     
     • NOTE: If a port that nginx requires to bind to in order to function properly is showing up in PowerShell as being used by a different process that is not nginx, it is the end user's responsibility to address the issue and ensure that the port(s) are freed up and are not listening for non-nginx processes. Nginx requires the use of ports 80, 443 and 9443.

Verify the DNS record has propagated

1. You can use a third-party website (https://dnschecker.org/#A/dnschecker.org) to see if the DNS record has propagated worldwide
2. Go to the website and input the DNS Record from Chronicall/ACR
3. If the DNS record shows as propagated on the website then you can check if their server also has that information by opening a command prompt on the server and running

   • nslookup <InsertDNSrecordhere.ximasoftware.com>

     • For example

       • nslookup kjnbkjasdvjhv8938yfuhsvd.acr.ximasoftware.com

4. If that command fails with a non-existent domain then they will need to wait until the server pulls down the DNS information. There is nothing we can do to speed up that process as it will be governed by their network pulling the information down.

Verify the ACR/Chronicall server can reach itself via its public IP address

If accessing ACR/Chronicall publicly, the ACR/Chronicall server must be able to establish a connection to itself over the aforementioned ports via its public IP address.

Agents:  Please reference our WebRTC Not Logging In internal article for further troubleshooting as well.