SOLVED Oracle Incredible PBX no https GUI access

Patrick68

Member
Joined
Aug 23, 2020
Messages
32
Reaction score
5
I am discovering the Oracle instances and installed IncrediblePBX.

I have whitelisted my IP and I can access the FreePBX GUI with http://IPaddress but I can not reach with https://IPaddress.

I am sure there is an obvious setting somewhere to modify but I still can't find it.

Any hint where to look?
 
Mine is the same but given it can only be accessed from your whitelisted IP address I don't see a problem.

EDIT - Alternatively you could install openvpn and connect over the VPN if you don't have a static IP address.
 
Last edited:
I am discovering the Oracle instances and installed IncrediblePBX.

I have whitelisted my IP and I can access the FreePBX GUI with http://IPaddress but I can not reach with https://IPaddress.

I am sure there is an obvious setting somewhere to modify but I still can't find it.

Any hint where to look?
If you need access from the internet you need a certificate. Which needs a certificate authority recommend letsencrypt.

But why go there unless going public.
 
Last edited:
When I am login into webadmin it is automatically going to https and it uses the certificate I have installed in the server.

When I am login to incrediblePBX it refuses https connection and I have to use http only...

Again I don't see why this different treatment

And even if you only have your IP allowed, using http makes all your pages in clear text and someone can steal your SIP credentials by eavesdropping.
 
Thanks, it looks simple. If only I could find the "System Admin / HTTPS Setup" tab in the freePbx menu.
 
When I am login into webadmin it is automatically going to https and it uses the certificate I have installed in the server.

When I am login to incrediblePBX it refuses https connection and I have to use http only...

Again I don't see why this different treatment

And even if you only have your IP allowed, using http makes all your pages in clear text and someone can steal your SIP credentials by eavesdropping.
I am unsure what you mean by When I am login to incrediblePBX it refuses https

The instructions for web access via different methods is for security - so not to expose the oraclecloud iPBX directly to the internet. the code at the following link sets that up possibly you did that?

Access the webserver via FQDN

Assuming you have iPBX2021, and you have not run script for 'Going Public' (not recommended - unless necessary) as per:
Migrating-incredible-pbx-2021-to-a-public-facing-cloud-pbx

Then you have 3 Virtual hosts:
1st is on internet Port 80 or something and via the internet (not VPN) to <yourserverIP> Userdir access disabled
2nd internet Port 80 But using your own domain at example.com which points to the USER CONTROL PANEL
3rd Via the openVPN tunnel using IP 10.8.0.1 and points to DocumentRoot /var/www/html the web interface

So you should be accessing the web access over the openVPN (encrypted) tunnel from your openVPN client machine;
and for your 'users' they can access the User Control Panel via your domain.
Those using your serverIP and unable to authenticate get the FORBIDDEN page.
 
Last edited:
Thanks, it looks simple. If only I could find the "System Admin / HTTPS Setup" tab in the freePbx menu.
Woops
Admin / System Admin is a Commercial Licenced product so not installed by default.
COMMERCIAL MODULE REQUIRES A LICENSE FOR PRO FEATURES TO BE ENABLED ABOVE THE INCLUDED FREE FEATURES
 
Admin / System Admin is a Commercial Licenced product so not installed by default.
COMMERCIAL MODULE REQUIRES A LICENSE FOR PRO FEATURES TO BE ENABLED ABOVE THE INCLUDED FREE FEATURES
Yep. However, as pointed out before, if you use the IncrediblePBX firewall correctly, no one can access or even see your PBX unless they are whitelisted. If you want a pre-cooked HTTPS solution, it requires the commercial module. However if you do google searches for freepbx+https, you will discover some other solutions that may or may not work for you.
 
A very secure set of TLS services can be provided to only URL's refering to properly certified Domains using a reverse proxy and SNI.
IP connections would be dropped without leaking a domain if done properly .
Registration domain nor admin domains do not have to be the same as your internet facing user domain.

Drive by Layer 3 leaks to UDP/5060@IPADDRESS can be a thing of the past. having effectively moved 'firewalling' from Layer 4 to Layer 5 where more direct control is a possibility.
 
Last edited:
Well whether or not its actually needed when hidden behind the oracle firewall and using the public.conf style Virtual hosts methods - I'm looking at jerm's offering which is looking good to me on github.

jerm's - fpbx-lewatch from Github

If you have done
Bash:
apt list git -a
# Listing... Done
# git/focal-updates,focal-security,now 1:2.25.1-1ubuntu3.5 arm64 [installed]
# git/focal 1:2.25.1-1ubuntu3 arm64
If it doesn't say git is [installed]
Then try the untested code below. Feel free test and to post bugs.
Code:
#!/bin/bash
apt-get -y install git
#caution ad lib coding untested!
mkdir -p /root/lewatch
git clone https://github.com/jerrm/fpbx-lewatch.git  /root/lewatch
cd /root/lewatch
chmod +x lewatch.sh
cat ./LICENCE
read -p "To continue only If you agree to MIT Licence press [Enter] or [ Ctrl + c ] to abort"
cat ./README.md
read -p "Are you ready to continue press [Enter] or [ Ctrl + c ] to abort"
./lewatch.sh
So now add the code specific to debian/ubuntu specified in the README.md file. to enable the ssl setup.
Bash:
#!/bin/bash
# Code here from '/root/lewatch/README.md' for debian/ubuntu as file /root/lewatch/fix-deb-ssl.sh
# point SSLCertificateFile to the FreePBX "default" certificate full chain pem file
sed -i '/^\s*SSLCertificateFile\s/ s|SSLCertificateFile\s.*$|SSLCertificateFile /etc/asterisk/keys/integration/certificate.pem|g' /etc/apache2/sites-available/default-ssl.conf

# comment out the SSLCertificateKeyFile line as it isn't needed
sed -i '/^\s*SSLCertificateKeyFile/ s/SSLCertificateKeyFile/#SSLCertificateKeyFile/' /etc/apache2/sites-available/default-ssl.conf

# enable ssl
a2enmod ssl
a2ensite default-ssl

# restart apache to pick up our changes
systemctl restart apache2

The script as published is intended to "just work" for most any iptables rule
set. It can certainly be tweaked to be more restrictive, but it is difficult
to be more restrictive in a generic way. Some user customization is required;
but it is beyond the scope of this post. If necessary see /root/lewatch/README.md for more details.
 
Last edited:
Bash:
# enable ssl
a2enmod ssl
a2ensite default-ssl

# restart apache to pick up our changes
systemctl restart apache2
For someone who is only familiar with RedHat derivatives, finding two a2 commands to enable SSL was a huge pain. SSL should have been enabled by default, IMHO.
 
This is a locked-down PBX platform with access only from whitelisted IP addresses and VPNs. There is virtually no risk of a man-in-the-middle attack so we regard SSL access as a needless, never-ending complexity that is more trouble than it is worth. We appreciate that there are differing points of view, and our platform is completely open so mods can be made to meet any individual's unique requirements.
 
This is a locked-down PBX platform with access only from whitelisted IP addresses and VPNs. There is virtually no risk of a man-in-the-middle attack
With all respect, I strongly disagree. Whitelisted IP's don't help hiding your credentials from ISP and other intermediates and system comes with no VPN configured. Wiki recommends using OpenVPN and while configuration is well documented it requires significant efforts and its client installation. If you really want to offer a customer friendly VPN solution the best way is to configure IKEv2 server during installation because IKEv2 clients are present on all desktop and mobile devices from the factory and only require simple username/password to connect.
we regard SSL access as a needless, never-ending complexity that is more trouble than it is worth.
Installing SSL requires significantly less efforts then VPN
 
Be aware that if you ever get any 'drive-by' snooping to your ip address (we all do, so and for this example we will use 8.8.8.8) then

openssl s_client 8.8.8.8:https < /dev/null

Surprises many folks as to what it gives away, they now have a domain name. Best to not first answer connections with a webserver , use a reverse proxy like HAProxy,, and only allow connections to a domain name, which doesn't have to be the same as your Web Facing business domain and and enforce SNI, ip connections then get dropped anonymously.

JM2CWAE
 
well this is what that get me pointed to an Oracle sloudserver when using the Virtual Hosts in public.conf

# openssl s_client <mysvrIP>:https < /dev/null
3069448256:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
3069448256:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111

YMMV
 
$ openssl s_client <myoraclecloudip>:https </dev/null
....
Verify return code: 18 (self-signed certificate)
---
DONE
$
 
Current browser won't respect self signed certification so won't render the content without you jumping through hoops
 

Members online

No members online now.

Forum statistics

Threads
26,687
Messages
174,411
Members
20,257
Latest member
Dempan
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Back
Top