SSL renewal fails: "The DNS zone that contains your FQDN is full" - FQDN no longer resolves

[ZakariaeRH]

Hi everyone,Self-hosted 3CX V20 Update 8 (Build 1121) on Debian 12, Enterprise Annual licence (16 simultaneous calls), valid until 25/04/2027,
BACKGROUND
We received the standard warning email stating that our subscription had been offline for an extended period, and that the FQDN would be released if the system remained offline for another 10 days. The system stayed offline past that window, the licence was renewed late, and the certificate was never renewed in time. That is how we ended up in the current state.

ERROR REPORTED BY THE SYSTEM
"SSL certificate renewal for xxxxxxx.ma failed - The DNS zone that contains your FQDN is full. Certificates cannot be generated using this DNS zone. If the DNS was available when you installed 3CX, then your FQDN should have been reserved in this zone. Check that the maintenance or key is not expired and make sure you have not activated your license on another server."

QUESTIONS1. Is the "DNS zone is full" condition something that can only be resolved on the 3CX side, and what is the correct channel to request it?2. Can our existing FQDN be re-reserved for this subscription, or do we need a new FQDN in a different zone?3. If we move to our own domain instead, what is the supported procedure to change the FQDN on an existing self-hosted V20 installation, and can we then manage the certificate ourselves?

Since the desktop app never reaches the PBX, I assume no locally generated certificate can help in this situation, but I would welcome confirmation before considering any workaround.

 

[Charles_3CX]

When a system is not communicating with our activation server, the FQDN will be released as unused. Your system was on v18 and wasn't updated to v20, so it couldn't communicate with us because v18 is EOL.

Can you try restarting only the 3CX system server service on this system, now on v20, and let us know?

 

[ZakariaeRH]

Hi,

Thank you for the explanation regarding the v18 EOL status - it matches our timeline and explains why the FQDN was originally released.

Following your instructions, we have:

1. Restarted only the "3CX PhoneSystem 01 System Server" service from the Admin Console. All services returned to a running state.
2. Updated the system to the current release build to rule out any version issue. We are now on Version 20.0 Update 9 (Build 995 Release - AI 1.4.48), previously Update 8 Build 1121 (Beta).

The FQDN still does not resolve publicly:

nslookup pharmai.3cx.ma 8.8.8.8
*** dns.google can't find pharmai.3cx.ma: Non-existent domain

Same result against 1.1.1.1

Relevant event log entries (28/09/2026):

16:24 - 10033 - "Your license has been successfully activated."
16:29 - 50011 - "SSL Certificate renewal has been failed. Error: Certificates cannot be generated using this DNS zone. If the DNS was available when you installed 3CX, then your FQDN should have been reserved in this zone..."
16:33 - 10033 - "Your license has been successfully activated."
16:35 - 30035 - Service 3CXSystemService01 restarted


Current state:
- Licence Valid until 25/04/2027, key refresh from the console completes successfully
- Certificate expired since 09/07/2026 (issued 10/04/2026)

Could you please advise on the following options:

1. Can pharmai.3cx.ma be re-reserved for this subscription from your side?

2. If the zone is genuinely full, can we be assigned a new FQDN in a different zone? We accept that this would require reprovisioning our phones and users.

3. Our users only place calls from inside the LAN - there is no remote or mobile usage. Is it possible to reconfigure this installation with an internal FQDN of our own, resolved only by our internal DNS (for example pbx.phi.ma or an Active Directory zone pointing to the PBX LAN address), with a certificate we manage ourselves? If so, what is the supported procedure, and would the desktop application work in that configuration - our tests suggest it performs an FQDN lookup against your cloud service before contacting the PBX, so we would like to confirm this before going down that route.

Any indication of a timeline would be much appreciated - our client applications have been down since the certificate expired.

Thank you.

 

[Charles_3CX]

The domain suffix you had is now exhausted and therefore cannot be rebound.

You can suggest contacting your 3cx partner, linking to your account, and asking them to open a ticket with 3cx technical support to advise further.