FreePBX on a private network, TLS and self-signed certificates?

We are developing a new PBX using FreePBX 14 on a private class B network (172.16.x.x) and things are going along well, Our phones are Grandstream GXP 1615, 1630 and 2170 and we have a T1 for the PSTN.

We now would like to activate TLS and SRTP between the PBX and the phones.

We plan to use a self signed certificate generated by the FreePBX certificate manager, as it seems public certificates does not exist for private networks.

I have extracted the .crt file and uploaded it to the phones. Our first test does not look too good, so I want to validate :

Q : can TLS (and SRTP) run at all on FreePBX using self-signed certificates ?

Obvious question: Why?

Yes. However, the phones/endpoints do not have a CA for that cert, they cannot validate against it. They need to have the Cert/CA installed on them locally.

You can use public certificates for private networks… if your private networks are designed to allow this. Unfortunately, while the new restrictions on obtaining public certificates are quite sensible they create a lot of issues with networks that weren’t built in the last few years (the overwhelming majority of them). Our solution has generally been to have a secondary “real” domain (publicly registered, etc.) that we use only for visible internal infrastructure purposes like this (we use tertiary domains for “invisible” infrastructure). The additional DNS server maintenance overhead is minimal. Eventually we’ll transition our legacy .local and other unsupported domains over to these “real” domains. I’m not a fan of split DNS for security reasons and relative complexity of maintenance.

So a typical example would be: - public resources
xyzcorp.local - legacy internal domain - internal, user-facing infrastructure (intranet servers, printers, WAN routing hops, etc.). - internal, hidden infrastructure (which should be invisible and unnoticed, like a ninja - hypervisors, backup, network management, etc.).

We also generally run internal CAs - this makes using TLS internally more reasonable and cost-effective. EJBCA is an extremely pleasant option to use if you have the patience to get it set up and running. Microsoft’s CA is the opposite - easy to install but a ridiculously absurd pain to actually use.

The real question is - do phones actually validate certificate chains or just accept them blindly for establishing TLS? I can’t imagine that they actually validate - this would require constant firmware updates to keep track of changes in the various trusted roots and I’ve never seen that (doesn’t mean it isn’t a thing - I haven’t really looked either, but I think I’d notice). I’d use proper certs just for form (and to keep your users from having to ignore browser warnings - not a good thing to train them to do), but I’d bet you could get away with a lot here if you really had to.

1 Like

Thank you very much for taking the time for that long answer. It points me to several avenues.

So, as it is a private network, my simplest next step would be (knowing FreePBX supports it) to check if my phone vendor (Grandstream) supports self-signed.

If not, I will have the longer trek of setting up an internal CA.

Really appreciate, cheers !

Self-signed and internal CAs may give you similar problems, depending on the specific issues. Adding another internal domain and official cert is cheap (<$40/year) and should be a bulletproof solution.

The question that was posed earlier still stands. If this is all on a local network, why do you need TLS for calls?

Internal security. Request from our network guys, we are a small university.

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