Is using own FQDN with 3CX Standard possible? (instead of having XYZ.3cx.tld defaulting for provisioning?)

[systemofapwne]

Hello,

I keep on struggling setting up 3CX with my own FQDN for my home/family.
The wizard simply does not show me any option to set my own FQDN but rather insists to create a XYZ.3cx.tld including the TLS certificates.
When using an auto-configuration file with own certificates, the wizard seems to ignore NeedFqdn=no too and errors out, that I did not have set a hostname (which is required only for NeedFqdn=yes)
But I rather would like 3CX to mainly use pbx.mydomain.tld for external access (that FQDN is under my control and has auto-renewed TLS certificates already)

To be honest, I don't really mind, if this XYZ.3cx.tld exists (or even expires). The issue I have is, that when provisioning phones, the QR code or the configuration file always points to XYZ.3cx.tld. And this seems to be not changeable via the UI.
Before I start digging deeper, I would like to know, if there is any possibility to get my own FQDN used without upgrading to Professional.

My system setup:
Running 3CX 16.0.6.655 in a docker container
License: 3CX Standard (Free)

 

[Evolute IT]

No you can't. It's built into the 3CX. You will need to upgrade to Pro or stick to the 3CX Provided FQDN.

 

[Saqqara]

As above,

But to save a lot of hassle in terms of installing a ssl certificate for you own fqdn I would still use a 3cx fqdn and let the 3cx system handle the fqdn for you

 

[cobaltit]

3CX FQDN's are fully managed and supported, so why are you trying to use your own? What exactly do you hope accomplish here?

 

[systemofapwne]

Thank you for all your replies.

It is sad to hear, that this is not possible in the Standard edition, since it looks like a minor feature.
But as said, I don't mind to have the 3CX.tld, since I can anyway use my own separately.
However, when you play around a lot and you basically reinstall 3CX a few times (like I did the past days), then you run into troubles: The wizard will always request new TLS certificates for the 3CX.tld, which can only be done 5 times per FQDN within a timespan of 7 days. But that is a minor issue (just switch TLDs)

My intention was actually to reverse-proxy 3CX via nginx, so I can add my own HTTP authentification ontop. I simply do not like a service exposed to the internet without additional authentification. And for my reverse proxy, I can definitely control the authentification strength (while for 3CX, I can't be sure about).
The issue is, that when I do this, the 3CX.TLD then points to my nginx-reverse proxy (and not 3CX itself), so nginx delivers the wrong TLS certificate for the wrong TLD and provisioning then fails.

But in the end, I was successful with an nginx subfilter rule, to replace the 3cx.tld with my.tld in the provisioning configuration. But this only works for the QR-Code, since I do not intercept the invitation mail. That might also be possible, but I don't really care. QR-Provisioning is all I wanted to work smoothly at my home.

Here is the filter rule I use:

    # Provisioning
    location ~* ^/(p|provisioning|myphone)/ {
      
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://pbx;
      
        proxy_ssl_verify off;                                   # Must be off, so this nginx acceppts the TLS stream of 3CX no matter of the hostname
  
        #Subfilter
        proxy_set_header Accept-Encoding "";                    # Tells the proxied server, that we do not support gzip -> gzip must be off for subfilters to work
        sub_filter 'pbx.3cx.TLD' 'pbx.MY.TLD';                  # External FQDN rewrite
        sub_filter_once off;
        sub_filter_types text/html text/xml application/octet-stream;
    }

 

[JohnS_3CX]

Since you are running the system in a non-supported method, there is no point in asking about using your own FQDN in the standard edition or the enterprise edition. Our implementation is effectively bypassed regardless of the license type.