3CX V20 Windows Server – WebRTC with Internal Self-Signed Certificate

[surawoot]

Hi 3CX Staff Team,


We are planning a 3CX V20 deployment on Windows Server for a banking customer.
Due to the bank's security policies, the environment is highly restricted and the PBX is intended to operate primarily within the internal corporate network.
The current environment/requirements are:

• 3CX V20 on Windows Server.
• The customer uses their own custom FQDN.
• The FQDN is resolved internally to the private IP address of the 3CX server.
• Internet access from the server is restricted due to banking security policies.
• The customer has an internal PKI/CA infrastructure.
• They currently use an internal/self-signed certificate solution based on their corporate Web Server certificate template.
• The certificate is not issued by a publicly trusted CA.
• Corporate/domain-joined clients can trust the internal certificate/CA through the bank's managed environment.
• Using a publicly issued SSL certificate may be restricted by the bank's security policy.

Our main concern is 3CX Web Client/WebRTC functionality.

Could you please help me clarify the following:

1. Can 3CX V20 WebRTC work with an internal/self-signed certificate, assuming the certificate and CA chain are fully trusted by the client OS and browser?
2. If the certificate contains the correct custom FQDN in the Subject Alternative Name (SAN) and the browser shows the HTTPS connection as trusted without any certificate warning, would this be sufficient for WebRTC to work?
3. Does 3CX specifically require a certificate issued by a publicly trusted CA for WebRTC, regardless of whether the customer's internal certificate is trusted by all corporate endpoints?
4. If a publicly trusted certificate is mandatory, what is the 3CX-supported solution for a banking/internal environment where Internet access is highly restricted and the PBX should not be publicly exposed?
5. Would the following architecture be supported?
   Publicly trusted SSL certificate + Custom FQDN + Internal/Split DNS → Private PBX IP
   
   In this scenario, the FQDN would resolve to the private 3CX IP for internal users, and the PBX/Web Client would not need to be directly accessible from the public Internet.​

Best regards,

 

[Charles_3CX]

Hi, Please note that a supported 3CX deployment requires a publicly trusted SSL certificate, valid for the PBX’s custom FQDN, with the complete intermediate certificate chain installed.

Self-signed certificates and certificates issued by a private/internal CA are not supported, even if corporate endpoints trust them and the browser displays no certificate warnings. A matching SAN and a trusted HTTPS connection alone do not establish a supported 3CX configuration.

Please refer to the 3CX custom FQDN and SSL certificate guide, as well as the certificate chain requirements.