Hello,
Has anyone been successful when provisioning old Aastra 6757i IP phones using HTTPS and LetsEncrypt cert ? If positive, which firmware version did you use ?
Best regards
I’ve got a few of those in my test bench. I’m sure it would be possible - assuming the phone supports TLS - but it’s going to not support modern encryption so it’s not going to be secure anyway. The bigger problem with those phones is that their jitter buffer is too small or non-existent, they are extremely poor audio phones because of that. I’d pitch them and replace them with nice used Polycom’s if I was in your shoes…
Thank you very much for replying.
I’m asking because I’m using a public web server to provision SIP (hard or soft) phones from various vendors. I would like to drop HTTP entirely to only keep HTTPS (or maybe only keep HTTP for LetsEncrypt cert renewal).
During my trials, I couln’t move Aastra phones from HTTP to HTTPS (though I must say I didn’t try very hard because I wondered if this could possible in the first place).
I thought maybe current LetsEncrypt required to import some files the phones before attempting HTTPS provisioning.
Maybe these details better explain why I was asking.
Of course, you remark about jitterbuffer is very important.
The Aastra’s work fine if they are on a nice fast gigabit switch with the Asterisk server plugged into the same switch. That is, a 100% on-premise solution where you probably don’t need to bother with encryption between the phone and the Asterisk server. But you won’t be happy running them over the Internet as call quality will suffer.
I would also review the recent post from the fellow with a Grandstream ATA that blew chunks about the wrong encryption curve being used when the version of OpenSSL that was used to generate certs for the TLS connection for that was upgraded. Even if the Aastra can be made to work with TLS, you may have to use some additional options to generate a certificate that the Aastra will digest.
I wouldn’t worry about exposing HTTP. You can put some directives into the web server to prevent script kiddies who get all excited when they port scan you and discover port 80 open, from using the port to fish around in your server for interesting things to look at, and to prevent customers with more modern phones that support HTTPS from using HTTP to connect to you.
The biggest drawback to using encryption with phones or pretty much anything, is that the encryption community has gotten extremely anal-retentive about issuing keys with very long expirations. Time was that you could get public keys with 10 year expirations and so on. Those days are gone. So as a result, any device out there that uses encryption, is now stuck in a trap where they pretty much more or less have to get constant and incessant firmware updates with new public CA root keys in them that replace old ones that expire.
Manufacturers of course, absolutely LOVE this since they can now easily obsolete 3 year old kit by dropping firmware updates for them. The kit will still work with unencrypted protocols but not encrypted ones.
There are some phone models that do allow you to upload your own private CA keys so you can get off the commercial public/private key merry go round but I don’t think the Grandstream the fellow was dealing with was one of these.
I’m just waiting for the day that the major Cloud providers like Ring Central start telling customers “uh, you know those 500 Snom phones you have on site - well you gotta pitch all of them since Snom isn’t releasing firmware updates for them and the CA keys in them are all expiring next month so either you switch them over to unencrypted SIP registrations or buy new phones”