This is a fresh install of a hosted system. I’m using authentication on an S505. ZTP works perfectly via HTTP but I cannot get it to work with HTTPS. To switch from HTTP to HTTPS I updated the template in EPM and then updated the Sangoma portal.
According to the phone log it does get the correct address from the Sangoma portal (https://:@pbx.xxxxxxxx.com:1443). The phone does apply some configuration as evidenced by the password changing from the default to what is configured in the server. But it finishes without applying pretty much anything else from EPM. The phone is has a login prompt on the screen.
I have verified that my certificate is good (Let’s Encrypt). But I should note that I had to pull an edge version of certificate manager to do so; 14.06.
they are either blank or something else is going on; if there are any special characters used try removing those and if that makes a difference please let us know
also the half working nature might suggest disparity between what’s configured in the portal versus whats configured in your template - check that too
PitzKey, for a number of reasons I believe you’re incorrect about setting the provisioning string in the template, but I tried it anyway. It still behaves exactly the same. (But thank you for the suggestion).
And yes, I am rebuilding the template and resetting the phone to factory defaults each time I change from HTTP to HTTPs or vice versa.
Open a browser on the same network the phone is on and go to https://your.domain.com:1443 does it ask you for credentials, and are you able to login with the same provisioning credentials?
Apologies if I’ve missed it, what firmware version are you using on the phone? In my testing I’m seeing oddities in .74 that are not present in .72, if you are using .74 rollback and retest. Did you open a ticket?
I always found that the Sangoma phones were picky about certificates, probably do to lack of storage on the phone for all the root certs. For instance a Comodo certificate wouldn’t work to provision the phones, but a RapidSSL worked fine. If you’re not seeing any phone to PBX traffic in the httpd access log then it might be the phone doesn’t like Let’sEncrypt certs?
@lgaetz that was a great idea; one I hadn’t thought of. I was on.74 so I rolled it back to .72. Unfortunately, it didn’t help.
I did open a ticket in which I attached the phone logs where it was working with HTTP and was not working with HTTPS.
They closed the ticket with this reply:
On further looking into your logs, we can see that sangoma portal responding properly and asking phone to go to your server and then phone trying with your server and failing.
I think you should look connectivity of HTTPS between your phone and your server.
So that got me thinking it was something to do with my firewall configuration, which is pretty basic (this is my home office). I reviewed the firewall config but came up with nothing.
I have other hosted systems where provisioning over HTTPS is working just fine, so I provisioned the S505 on my desk on one of those systems and it didn’t work either. That really made me think it could be something to do with my network. I think the next step is to take this phone to one of the sites where other S505’s are working fine and try to provision it to both systems. And then if I still don’t have it figured out I can try different firmware and even different phones. Surely, something will shake loose soon.
@waldrondigital I’m not sure how to use your suggestion. I’m using Let’s Encrypt on the server, and they’re working fine on other hosted systems I have with S505’s provisioning over HTTPS.
All I had time to try today was HTTPS provisioning at my home office of a Yealink T58 on one of the systems that was working. It’s not zero-touch of course but it does work.
I finally figured this out. It was just me being an idiot (no big surprise). I had configured the phone in FreePBX as an S505 when in reality, it was an S500. Everything worked as it should have except HTTPS provisioning, including HTTP provisioning with a username and password. Turns out, it matters!
This one’s on me, at least most of it. But I’ll reserve just a little responsibility for FreePBX. If I choose the wrong model, it seems to me that it shouldn’t work at all so that I quickly know that I screwed up. They say the best lie is one that contains mostly truth. Same here; the best way to miss the problem is for it to mostly work even though it shouldn’t.
It’s certainly possible that if I understood the inner workings of FreePBX better I might see how this is expected behavior. But I believe it can be better than that.
