Getting a valid Certificate
From Pbxnsip Wiki
In order to establish a trust relationship between a client and a server the transport layer security (TLS, see e.g. http://en.wikipedia.org/wiki/Transport_Layer_Security) uses certificates. The principle is simple: I know someone who I do trust, and that someone certifies that the one that I want to talk to is the one that he pretends to be.
TLS is used in the PBX in two places. First, it is used to secure the traffic between the web browser and the PBX web interface. Second, it is used to secure the SIP traffic between the phone and the PBX signaling path.
The PBX by default generates a certificate on the fly; this is called self-signed certificate. While this provides a reasonable encryption of the traffic, it does not make sure that the client is really talking to the server. For example, it could also talk to a man in the middle that is just relaying the traffic. Essentially, that means the traffic is not private any more.
Because of that, most internet browsers are very strict regarding checking of certificates. The user must explicitly accept the untrusted certificate. Also, some IP phones do only accept SIP traffic on connections that have valid certificates. While the user of a web browser can just click and accept the certificate, a user of a phone usually does not have such a choice and the connection just fails.
Contents |
Buying a certificate
When you buy a certificate, you must somehow make sure that you are really the one who is operating a server. The mechanisms for that differ; what they have in common is that you need to pay some amount of money for the service and that your web browser is already set up to trust the certificate authority. This mechanism is suitable if you are operating a public service where it is not an option to load root certificates on many clients. You usually also need to specify which IP addresses are using this certificate for the service.
Making your own certificate
If you have control over the clients, you may also generate your own certificates. For example, you can join the community at http://cacert.org and generate your own certificates. Then you need to load the root certificate into the clients that should talk to the PBX.
There are various other sites available which provide a similar service. You may also download the openSSL toolkit and compile your own certificate generator and set up your own trust network. If you have done this already for security your other office infrastructure (for example, for email or VPN), you can probably reuse the certificates for that.
Certificate Size
Please use only 512 and 1024 bit certificates. The PBX currently has trouble handling certificates with other sizes. The security and the performance on these certificates is still reasonable.
Loading your certificate
In order to load your certificate, you need to feed the web interface of the PBX with the certificate and the private key (see Loading of a Certificate). We recommend that you do this locally on the machine, so that the private key does not have to travel over the network.
Currently the PBX supports only one certificate per server. The consequence is that you can secure only one domain. This is no problem for the web access, as you can just tell your users to log on to one web address for all domains, it does face a problem for SIP user agents. Depending on the implementation of the user agent, it checks either the domain name of the registrar or the domain name of the outbound proxy. If the SIP user agent checks the outbound proxy, you can still use the same outbound proxy for all domains and you are all set. If that is not the case, you can register this kind of SIP user agents only to one domain per PBX.
