Toestel wil niet provisionen op self-hosted

[p.munnichs]

Ik ben al de gehele dag bezig met het onderzoeken van een probleem met provisioning van Yealink toestellen op een self-hosted omgeving.
Dit betreft een V20 installatie op een eigen VM (in de cloud, niet lokaal) met FQDN.
Registratie via de 3CX app op hetzelfde netwerk als de toestellen werkt prima.

Ik voorzie een extensie van een IP-phone, verschillende yealink modellen geprobeerd (T58W, T48U, T46U, T33).
De provisioning URL komt ook netjes in het toestel terecht via RPS, dit gecheckt via de admin interface van het toestel en zie dit ook netjes terug in de event logging binnen 3CX.
Daarna lijkt er helemaal niets meer te gebeuren en wil registratie niet lukken.

Doe ik precies hetzelfde uitvoeren op een hosted omgeving van 3CX zelf ervaar ik geen problemen.
Eerste verdachte zou natuurlijk firewall zijn (NSX op VMware), echter is dit ook al uitgesloten door deze volledig uit te zetten.
Firewall check van 3CX komt ook met OK terug.

Verschil welke ik gevonden hebben tussen eigen hosted omgeving en 3CX hosted omgeving is dat de provisioning in de logging 2 regels moet leveren.
Ik krijg wel onderstaande regel op beide omgevingen:
"RPS request for Yealink (MAC:249Axxxxxxxx) IP Phone of <achternaam>, <voornaam> delivered successfully".

Echter krijg ik de volgende regel die daarna moet volgen enkel op de 3CX hosted omgeving, maar niet op mijn eigen:
"Provisioning file for MAC 249Axxxxxxxx of user <achternaam>, <voornaam> requested by <ip-adres>) was successfully generated".

Op de een of andere manier komt het verzoek vanuit het toestel dus niet op de hosted omgeving uit, of wordt deze om een of andere reden niet gegenereerd door de self-hosted 3CX omgeving.
Is iemand hier toevallig ook tegenaan gelopen of heeft iemand een idee wat ik verder nog kan proberen.
Op dit moment ben ik volledig blind gestaard op dit probleem.

 

[RJansen]

Phones --> opties--> Allow 3CX to provision securely all IP Phones using 3CX Remote Provisioning server staat aan?

 

[p.munnichs]

We hebben het probleem gevonden waardoor dit niet lukte nadat we e.e.a. door middel van PCAP tracing hebben bekeken.
Onze FQDN hebben we voorzien van een wildcard SSL certificaat.
Echter blijkt nu dat Yealink de CA certificaten vanuit Sectigo niet in de trust list heeft staan.

Voor nu dus opgelost door untrusted CA's even toe te staan in de settings van de Yealink toestellen.
We gaan hiervoor even andere certificaten regelen zodat we provisioning kunnen regelen zonder dat de toestellen eerst aangepast moeten worden.