Solved 3cx and own FQDN certificate

[Evgeny M.]

There is a 3cx server with its own FQDN (3cx.mydomain.com) and 3cx with FQDN from 3cx in the format (mydomain. 3cx.us)
In the first case - the phones do not work on STUN, in the second everything works. I understand that the problem is with the own certificate. But installing it in the phone does not solve the problem. By trial and error, I realized that only the certificate from Let's Encrypt works with phones over STUN. Are there any other ways to make the phones work, or maybe someone was able to set up Let's Encrypt on their server with auto-renewal.

P.S. both servers have a support

 

[JohnS_3CX]

Hi,

When it comes to custom certificates there is not much we can do to help, you will have to check with your phone manufacturer to see which certificates they support.

Sometimes there may also be intermediate certificates that if missing can break the chain of trust, but again this is something you will have to look into.

We would recommend if possible to replace the FQDN with a 3CX one which takes care of the following for you, and is already included as part of your license:

- automatic renewal of certificates without interaction from the Admin
- compatibility with all 3CX-supported phone models
- removes the need for any

 

[Evgeny M.]

I understand that. But the phones vendor we use have not been able to solve the problem. So the only way I can see is to install Let's Encrypt certificates and set up auto-renewal. I checked on the test server with my Let's Encrypt and it works. The problem is only one, I do not know how to make an auto-renewal of my own FQDN.
P.S. switching to a name from 3cx FQDN is not even considered...and I don't quite understand why the manufacturer of 3cx ignores this situation, forcing us to use your own FQDN?

..or, maybe you have a solution, which certification center should be for Yealink, Snom and Grandstream phones?

 

[JohnS_3CX]

P.S. switching to a name from 3cx FQDN is not even considered...and I don't quite understand why the manufacturer of 3cx ignores this situation, forcing us to use your own FQDN?

No I think there is a misconception here. There is nothing forcing you to use a 3CX FQDN.

You are only forced to use LE certificates by the phone manufacturer because this is what the manufacturer supports. This is regardless of what the FQDN is. If they support other certificates they also can be used. You have to ask the manufacturer.

As for auto-renewal of certificates on custom FQDN, this is out of the question from a 3CX-perspective. It may be doable manually, you will have to create your own tool or scripts to automate this.

But remember, even if LE was not in the picture, and you were using 3rd party certificates (ie. GoDaddy), you would still not have auto-renewal. You would again have to do everything manually so nothing changes in this respect.

 

[Evgeny M.]

Well.....maybe you have a solution, which certification center should be for Yealink, Snom and Grandstream phones?
how do I connect them using STUN technology correctly in this case?

 

[JohnS_3CX]

We already have a fully automated and supported solution - use a 3CX FQDN

This method means:

- we automatically generate LE certificates for you
- the Yealink, Snom and Grandstream phones already support those LE certs.
- we automatically renew them for you before they expire
- you do not have to pay any extra money to buy SSL
- you as the admin has zero maintenance to do
- it's already included with your 3CX license


At this point you as an admin will have to decide if you want the above benefits, or if you want to keep a custom FQDN (but also have to do the extra work of testing and maintaining it)

 

[Evgeny M.]

I understand. It is better to specify in documentation that Stun 3сх only works correctly in FQDN mode from 3cx. Otherwise, it causes an additional headache when trying to solve the problem.

 

[JohnS_3CX]

The simple answer here would be no. I think you have entirely misunderstood the issue, and this has caused you to try and solve a self-inflicted problem:


- STUN works both with Custom FQDN and 3CX FQDN

- Phone manufacturers support LE and but also some other SSL certs too, you have to ask them yourself

- You are not forced to use LE only, you can use other certs but you have to figure out everything with the phones manufacturers

 

[Evgeny M.]

Good. Do you know which certificate authority I should use for Yealink? Of course, I will also request a vendor, but maybe you know? (Sectigo, Comodo and Thawte not work)

 

[JohnS_3CX]

Unfortunately no, I would simply visit the Yealink site and find out directly though.

 

[Evgeny M.]

Problem solved. We need named personal certificates, not wildcard certificates