TIPS Change port 80 GUI

[LitleBill]

acme.sh has a DNS handler for cpanel.

dnsapi2

A pure Unix shell script ACME client for SSL / TLS certificate automation - acmesh-official/acme.sh

github.com

it will put relevant files in .acme/your,domain.name/
and if you had added

--cert-file <file> Path to copy the cert file to after issue/renew..
--key-file <file> Path to copy the key file to after issue/renew.
--ca-file <file> Path to copy the intermediate cert file to after issue/renew.
--fullchain-file <file> Path to copy the fullchain cert file to after issue/renew.
--reloadcmd <command> Command to execute after issue/renew to reload the server.

where file was started with
/etc/asterisk/keys (copy the fullchain to your.domain.name.crt and the key to .key, the reload command should fwconsole certs import and reload your webserver, then you should be good to go and bypass the FreePBX certificate manager which you should disable when you get it working.

Thank you very much @dicko
This worked really well for ZeroSSL.

So for those who host their domain on
1) a Cpanel hosting
2)and use it as a Nameserver as well,
3) and want to use ZeroSSL the instructions would be simply:

Go to your Cpanel,
create subdomain : pbx.mydomains.com
Go to zone editor: add pbx.mydomains.com with IP address 123.45.67.89
get and API key: CXJ8HRXFNS363RQ71Z51TKM9KTHRFZVE

on your IncrediblePBX server,
login as root and type

export cPanel_Username="myadminuseratnordicway"
export cPanel_Apitoken="CXJ8HRXFNS363RQ71Z51TKM9KTHRFZVE"
export cPanel_Hostname="https://cp04.nordicway.dk:2083"


./acme.sh --issue --dns dns_cpanel -d pbx.mydomains.com

No need to add any TXT records, no need to open any ports. just need an API key for your Cpanel.


The cert is valid for 90 days. And hope it will renew automatically with cron job.

Now that my admin page is secured with SSL I will try to get TLS working for SRTP.

 

[dicko]

Thank you very much @dicko
This worked really well for ZeroSSL.

So for those who host their domain on
1) a Cpanel hosting
2)and use it as a Nameserver as well,
3) and want to use ZeroSSL the instructions would be simply:

Go to your Cpanel,
create subdomain : pbx.mydomains.com
Go to zone editor: add pbx.mydomains.com with IP address 123.45.67.89
get and API key: CXJ8HRXFNS363RQ71Z51TKM9KTHRFZVE

on your IncrediblePBX server,
login as root and type

export cPanel_Username="myadminuseratnordicway"
export cPanel_Apitoken="CXJ8HRXFNS363RQ71Z51TKM9KTHRFZVE"
export cPanel_Hostname="https://cp04.nordicway.dk:2083"


./acme.sh --issue --dns dns_cpanel -d pbx.mydomains.com

No need to add any TXT records, no need to open any ports. just need an API key for your Cpanel.


The cert is valid for 90 days. And hope it will renew automatically with cron job.

Now that my admin page is secured with SSL I will try to get TLS working for SRTP.

There will be a cron job created to auto-renew

acme.sh --cron

You will now 'source' .acme.sh/acme.sh.env in your .bashrc file, so neater to add those 'exports' in that file for when you think more security is good and your reverse proxy is working , in which case you will need more domains, wild-cards and sub-domain certs . . .
(Also you can get an A+ at ssllabs.com quite easily if that strikes your fancy)

You can arrange for acme.sh to issue LetsEncrypt instead of ZeroSSL certs if you feel the need to do so.

Server

A pure Unix shell script ACME client for SSL / TLS certificate automation - acmesh-official/acme.sh

github.com

 

[LitleBill]

more security is good and your reverse proxy is working , in which case you will need more domains, wild-cards and sub-domain certs . . .

using reverse proxy might be a little over my head but I tried to generate a separate TLS cert to use for TLS/SIPS between Incredible PBX 2021 and an IP Phone or Soft Phone.

Now I understand why you mentioned the need for more domains.

After I generate the cert, I assume the next steps would be changing the SIP settings:

 

[dicko]

I prefer to use an haproxy TCP frontend to handle TLS:5061 with strict-sni filtering and absolutely yes a completely unrelated domain, sending any verified connection handled by a backend connecting to the local FreePBX TCP listening port, it's a little messy/tricky to get FreePBX to only listen on 127.0.0.1 and not ubiquitously 0.0.0.0, so for ease of use don't use 5060 for the TCP transport and drop that port on your firewall. (you won't need any TLS transport in FreePBX and you can of course use a similar recipe for HTTPS on 443)

 

[LitleBill]

Would your suggestions be applicable to a PBX that has just a few whitelisted IPs in IPtables?

Would there be a need for multiple domains and TLS certs if all subdomains resolve to the same IP?

I wonder if it would make sense to whitelist some ASN for mobile users, like Verizon, AT&T, T-mobile ASN's or are these ASN's abused as well (fast flux etc..)

 

[dicko]

Would your suggestions be applicable to a PBX that has just a few whitelisted IPs in IPtables?

Would there be a need for multiple domains and TLS certs if all subdomains resolve to the same IP?

I wonder if it would make sense to whitelist some ASN for mobile users, like Verizon, AT&T, T-mobile ASN's

SNI is the method to differentiate connections to the 'same' ip, completely completely separate domains/sub-domains for admin,ucp, provisioning ,TLS transport will reduce 'snooping' and leakage if your webserver is serving HTTPS directly, using sub-domains over apex domains also better as new certs are public and Amazon/microsoft/google/bad guys will drive past quite quickly, sub-domain 'a' records are not so public so generally too 'expensive' for the bad-guys to troll.

NameCheap sells domains for as little as $3 for the first year

I find whitelists of any kind are kinda as necessary as the Whirlpool Repair Man when all is working well. Routine blacklisting of bad-guy's ASN's reduces noise as time goes on, use ipsets over iptables.

 

[LitleBill]

SNI is the method to differentiate connections to the 'same' ip, completely completely separate domains/sub-domains for admin,ucp, provisioning ,TLS transport will reduce 'snooping' and leakage if your webserver is serving HTTPS directly, using sub-domains over apex domains also better as new certs are public and Amazon/microsoft/google/bad guys will drive past quite quickly, sub-domain 'a' records are not so public so generally too 'expensive' for the bad-guys to troll.

NameCheap sells domains for as little as $3 for the first year

I find whitelists of any kind are kinda as necessary as the Whirlpool Repair Man when all is working well. Routine blacklisting of bad-guy's ASN's reduces noise as time goes on, use ipsets over iptables.

I still can't quite figure out how to get separate domains and separate Certs for the same PBX/IP/VPS-server.
I think I am slowly getting the concept of using SNI, originally I thought it would be quite easy for the bad guys to figure out what domains or subdomains are associated with the same IP.

So with SNI instead of using pbx.mydomain.com/admin ,for everything,,
it will be e.g.
admin.newpbx.com
and ucp.newucp.com
sip.newsip.com

 

[Samot]

I still can't quite figure out how to get separate domains and separate Certs for the same PBX/IP/VPS-server.
I think I am slowly getting the concept of using SNI, originally I thought it would be quite easy for the bad guys to figure out what domains or subdomains are associated with the same IP.

So with SNI instead of using pbx.mydomain.com/admin ,for everything,,
it will be e.g.
admin.newpbx.com
and ucp.newucp.com
sip.newsip.com

You will end up with admin.newpbx.com/admin as the URL string to get to the admin GUI. As well as ucp.newucp.com/ucp unless you modify all the link calls to not include them and that is a lot of work.

 

[dicko]

I still can't quite figure out how to get separate domains and separate Certs for the same PBX/IP/VPS-server.
I think I am slowly getting the concept of using SNI, originally I thought it would be quite easy for the bad guys to figure out what domains or subdomains are associated with the same IP. Raw IP based connections should be dropped but be aware that many webserver setups will 'leak' the domain name if yo redirect HTTP to HTTPS. So with SNI instead of using pbx.mydomain.com/admin ,for everything,,
it will be e.g.
admin.newpbx.com
and ucp.newucp.com
sip.newsip.com

Certificates are awarded to domains, not IP's, if your name service has A records for all these domains pointing to the same IP, THEN you can use SNI to differentiate the connections and presumably use that to forward to various http virtual servers or TCP services.

If such connections are not all http(s), a reverse proxy answering connections to that IP makes that very easy if it supports both HTTP(S) and TCPS (SIP TLS transport or a secured mail server as examples)

 

[dicko]

You will end up with admin.newpbx.com/admin as the URL string to get to the admin GUI. As well as ucp.newucp.com/ucp unless you modify all the link calls to not include them and that is a lot of work.

Not really a 'lot of work', he can have one virtual server listen to admin.newpbx.com:443 (no default) with a document root of /var/www/html/admin/ and another listening to ucp.newucp.com:443 (no default) which has a document root of /var/www/html/ucp/ with both accepting index.php these both set up in the sites-enabled directory for cleanness. Both virtual servers need the needs to verify their particular certs though.

sip.newsip.com is a different story as I assume it is looking to forward to the asterisk server on port 5061, this is probably not possible to do with apache2/httpd, probably possible with nginx with a lot of RTFM, personally I gave up when then i needed to license nginx plus ;-)

My solution otherwise documented here is to use haproxy which simply can verify and strip the S part of the both https and tls connection after verifying the SNI against it's certs and then forward the HTTP/TCP bit to whatever service you want. In which case admin.newpbx.com might well be answered by 127.0.0.1:8000 (but not 443) and ucp.newucp.com by 127.0.0.1:8001 (also not 443) and sip.newpbx.com:5061 to the tcp transport listening on 0.0.0.0:50612, haproxy will log all these connection attempts to /var/log/haproxy.log by default, 'SSL handshake failures' for IP attempts, 'NOSRV' for drivebys that have any of your domain names but are spiders, 'http~' log legitimate certified page access.

 

[LitleBill]

What would be the steps to get TLS/SRTP working for IncrediblePBX 2027 or 2027 on Ubuntu or Debian with blocking most ports?



1) get a domain name with subdomain e.g. sip.mydomains.com
2) get a certificate for the subdomain using acme.sh
3) change settings in Settings ...Asterisk SIP Settings
4) choose a port for TLS -- I am not sure what port should be used for this ???
if my pjsip port is 5061 then the TLS port has to be something else, I would think
if my pjsip port is 5060 I think TLS port could be 5061 ??

5)imports cert and provision phones . I assume this will have to be done every 59-60 days when the cert is about to expire

 

[dicko]

I feel we have been here way too long, but yes, to use TLS you need a certificate, and No, it doesn't need to be one from an 'acceptable' CA which is needed for https on modern browsers., but it won't hurt if it is. To use sub domains and using unlikely to be discovered domains will help but seem to confuse most folks as to why, so for baby steps don't worry about it.

You can choose any port you want for TCP and TLS but if they are the same, again you will confuse yourself (but not the network stack (TLS will still use TCP)) . UDP and TCP (including TLS) can be on the same port, but everyone and their grannies are scanning 5000-5999 to one extent or another on both protocols, UDP is mostly vulnerable, TCP less so and TLS if well done is pretty damn solid.

Sangoma's packaged 'distro' handling of port choice and forwarding is mired in layers of needing commercial licensing with it's concomitant obfuscation, possibly further needing it's bundled 'firewall', which is equally impeded. So here and elsewhere I recommend using more robust open-source network systems because FreePBX itself works very well without the added commercial 'helpers'

Ward's distro here ignores your situation by preferring to accept insecure protocols but only from whitelisted hosts, which is another way of doing it, but you can probably relieve the whitelist thing if you use my documented method of having the certs managed by a reverse proxy and only passing the connections that pass muster to the insecure services currently running on your PBX a la PIAF. This general method should work for https both public UCP and less public ADMIN web-roots as separate entities, both tls registrations and provisioning on separate certs, and if you need, also mail, mysql, mqtt or ftp by extension and apart from adding that 's(ecured)' layer without upsetting the underlying 'distro' should do no damage.