Is using my own SSL and FQDN the best way to go?

[Frank86]

When using the free 3CX FQDN, users receive a 3CX welcome email encouraging them to use one FQDN (or internal IP) when connecting to the 3CX web client from inside the office and the 3CX FQDN when connecting from outside the office.

Furthermore, when connecting to the internal FQDN or IP address (port 5001), users receive the warning about the page not being secure, which always paralyzes them. I could use http and port 5000 to "fix" this, but the overall solution of using two different ways of connecting to the same web client does not seem very elegant.

Is setting up our own SSL and FQDN with split DNS the best way to solve this problem? If so, does this negatively affect 3CX in any way (video conferencing or other issues)?

Also, does the SSL certificate need to be a standard one?
Can it be a wildcard one for the main domain?
Does the GoDaddy certificate need to be installed on the 3CX windows server?
Is it a hassle to renew?

 

[YonNomNom]

When you use 3cx domain it will use a lets encrypt certificate and you should not receive a insecure page warning.

 

[Frank86]

When you use 3cx domain it will use a lets encrypt certificate and you should not receive a insecure page warning.

For the external FQDN, yes. That's what we are using now. But when users connect to the internal FQDN (e.g. 3cx.mydomain.local), they do receive the insecure page warning.

On top of that issue, they are encouraged to log onto two different URLs depending on whether they are inside or outside the office with their laptop.

 

[YiannisH_3CX]

Hello @Frank86

You could edit the welcome email template to not send both links to users so they only see the public link and not get the https error due to the local IP. Make a backup of the default email template so you can revert back if something goes wrong.
This way you will avoid having to re-installing the system and maintaining a custom FQDN.

 

[Frank86]

Yes, I actually did that in my home lab, and it worked, so I could go that route.

Isn't it inefficient, however, to have 50 users connect to the public FQDN, only to be redirected through our firewall back to our on-prem 3CX VM, when they could connect to the local 3CX VM directly?

I don't mind reinstalling 3CX since I'm moving it to a new hypervisor and switching OS, so I guess this is a good time to ask and plan for the best long-term solution.

 

[YiannisH_3CX]

You could create a local DNS entry and point the 3CX FQDN to the local IP of the PBX. This of course is just a suggestion. You could also install the PBX with a custom FQDN and split DNS given you are running a Pro or Ent licence. Just make sure that you are using a valid certificate which will be required during the installation process. To renew the certificate you will need to follow the guide below.
https://www.3cx.com/docs/self-hosted-instances-ssh/

 

[Frank86]

Thank you. Are 3CX users who have implemented Split DNS happy campers? Have they switched to it and never looked back? Or are there any cons to Split DNS?

 

[CentrexJ]

You can put an entry on your internal dns server to redirect requests to the external 3cx fqdn to your internal IP. Then the internal devices will automatically go straight to the 3cx server and not go the firewall and back.

I suggest adding just the full fqdn only to the dns e.g. mypbx.3cx.us A 192.168.10.10 and not making a entry for 3cx.us or whatever country domain you have chosen. This way your DNS will be authoritative to just your 3cx fqdn internally.

Very easy to do with Microsoft DNS, likely others as well.

 

[choimarc]

Using own FQDN with split dns and no problems !

Marco.

 

[jmitch11]

Using your own FQDN makes failover a nightmare - that's the only reason I wish we would've not used it. Otherwise it's fine.

 

[cobaltit]

So none of this is really a 3CX issue. Split DNS is still split DNS whether you use your own FQDN or if you use the 3CX provided one and has nothing to do with 3CX. It specifically asks you during installation if you have managed DNS for this reason. Sounds like you didn't read or didn't understand the implications of that question.

 

[Frank86]

I was going by this article on 3CX split DNS with custom FQDN.
https://www.3cx.com/docs/creating-fqdn-split-dns/

If custom FQDN makes failover a nightmare, that is a serious issue for one of my sites, but no the others. Very good point.

 

[Frank86]

Is it possible to install a cert on the 3CX VM to get rid of the warning when connecting to the internal FQDN?