User Rating: 5 / 5

Star Active Star Active Star Active Star Active Star Active
 
ssl-certificate-300x250.png

It is almost a direct yes answer. SSL certificates protect the integrity and privacy of your service. If you google a little, you will find you can create your own SSL certificates yourself. However, using a home-made it is not always the best solution.

Self-signed home-made certificates offer the same level of protection than a commercial one. The difference is that certificate authorities from commercial certificates are already imported in most of the devices. Which it enables a trust relationship when verifying the certificate. Commercial certificates have some levels of review, therefore when getting a certificate for inside-out.xyz domain, there could be a trust relationship as depending the kind of commercial certificate you were getting, some identity reviews were done.

On the other hand, there are multi-domain, wildcard or single FQDN certificates. Multi-domain certificates take advantage of the multi DN capability of SSL certificates and allow you to have for example inside-out.xyz and inside-out.com domains together. Wildcard certificates are those that accept anything on the hostname part of the domain, for example, www.inside-out.xyz and blog.inside-out.xyz will be accepted in the same certificate.

I will write about the different options and the implications of using an SSL certificate.

FusionPBX with SSL Certificates

As FusionPBX is just a FreeSWITCH frontend. I will focus here on the HTTP part. FusionPBX may utilize  the SSL certificates in the following flows:

  • Importing the CDR
  • Pulling the Provisioning data
  • Accessing the WEB interface

HTTPS when Importing the CDR

In a standard deployment, FusionPBX pushes the CDR to the 127.0.0.1 address. Therefore, there is no need to use a certificate as the information flow does not touch anything but inside the server. If you have a more complex deployment, like the one I describe in my XML Importing article, then you probably need a self-signed one if the information travels through the Internet (for example, between two VPS'es). I find useless to use a commercial certificate here as the information flow is private. There is no exposure to the end user.

HTTPS when Pulling the Provisioning Data

Provisioning is the capability that FusionPBX gives to "auto-configure" your IP Phones without system administrator intervention. It is almost human-free as the first interaction you must tell the device where to pull information from.

FusionPBX links an IP Telephone in two possible ways:

  • domain and mac address (default): this force the telephone to query to the correct domain, for example, if my IP Phone has the mac address 00:11:22:AA:BB:CC and it is under the domain pbx.to-call.me, then it will work if I query http://pbx.to-call.me/001122aabbcc.xml, but it will fail if I query http://mybusiness.to-call.me/001122aabbcc.xml, regardless both URL points to the same FusionPBX. The domain makes a difference.
    In this case, you will need a wildcard certificate.
  • only mac address: FusionPBX does not validate the domain part. It will deliver the information regardless of the domain matches or not.
    In this case, you only need a single FQDN certificate, as you can put always the same hostname in the IP Phone.

HTTPS when Accessing the WEB Interface

If you are giving access to your users to the WEB Interface of FusionPBX, I do not need to explain why you need a commercial certificate. Now, the question is if you want a wildcard or a single FQDN one.

FusonPBX links the user access in two possible ways:

  • domain and username (default): this will force your user not only to have their username but to access using the correct domain. As the provisioning example, the user will need to log to http://pbx.to-call.me/ to log into their user linked to that domain instead of using http://mybusiness.to-call.me/. Again, the domain makes a difference.
    In this case, you will need a wildcard certificate.
    There is a workaround where users may use the @domain to force another domain. For example, if a user registered under the mybusiness.to-call.me domain accesses the FusionPBX interface using the domain pbx.to-call.me, in the login textbox, he will need to input This email address is being protected from spambots. You need JavaScript enabled to view it. in order to have access. This could be a good way to save money and avoid a wildcard certificate, however, not every user is high-tech and experience has shown me this may give you more headaches when dealing with people.
  • only username: this is called unique username. Your user will be unique in the system. It is a good idea to use their email as username if you go for this approach.
    In this case, you only need a single FQDN certificate as users always access using the same domain.

FreeSWITCH with SSL Certificates

Usually, VoIP utilizes SIP for signalling and RTP for the sound. And optionally, you can crypt SIP only or SIP+RTP. In my experience, a self-signed certificate has worked with me when implementing this. So, there is not too much to add.

Where do I get an SSL Certificate?

Good question, happily for everyone, I am SSL reseller. I can give you a very good deal for a single FQDN or for a wildcard SSL Certificate. Just contact me.

Good luck!

blog comments powered by Disqus