Zero Touch Provisioning not working over HTTPS

freepbx
Tags: #<Tag:0x00007f701f4edae0>

(United States) #1

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.

Any help is appreciated!


(Chris Dolese) #2

if you’re seeing https://:@pbx.xxxxxx.com:1443 you need to check out the redirect settings in the portal

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


(United States) #3

There are only alphanumeric characters in the username and password (pretty sure I tried some special characters and it wouldn’t let me use them).

Here’s what’s in the portal, the template, and the provisioning settings:




(Itzik) #4

IIRC you need to set the provisioning string in the template to

https://user:pass@pbx.domain.com:1443

Also, did you rebuild the template and phone after changing to https?


(United States) #5

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.


(Itzik) #6

When clicking on the ‘custom’ button
image


(United States) #7

Yep, that’s what I did. Still didn’t work:

But, I assume you’d like me to explain why I don’t think this is necessary:

But I still can’t get it to work and I’ve been wrong plenty of times so I’m still very much open to new things to try.

Sangoma folks, any help here?


(Itzik) #8

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?


(United States) #9

Interesting! I get a 403 Forbidden error. What does that indicate?


(Itzik) #10

That there’s no network/firewall issues with the phone reaching the provisioning files.


(United States) #11

Sounding more and more like a bug to me. Might be time to open a ticket with Sangoma.


(Lorne Gaetz) #12

Hi @bentljo:

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?


(Mike Waldron) #13

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?


(United States) #14

@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.


(United States) #15

@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.


(United States) #16

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.


(United States) #17

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.

Thanks everyone for your help.

Someone from Sangoma care to comment?


(system) closed #18

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.