Introduction
SSL or TLS Certificates are a known industry standard for encryption and security. They are used on basically every website today. This page aims to explain the different scenarios of implementing SSL Certificates on your jtel acd, as well as provide a walkthrough on how to do the installation itself.
Note
Technically SSL has not been used in a long time. Rather, TLS or Transport Layer Security has been the more secure successor to SSL and in use for a long time. However, the word SSL is still widely used to indicate this family of certificates, standards and functionality. We will as such also use the word SSL for the following explanation
Your jtel ACD With SSL
Access to your jtel ACD can be secured by SSL. A certificate is installed on the jtel Load Balancer to enable SSL-Encryption when accessing either your jtel portal, Chat or WhatsApp API.
There are some differences depending on the location of your system. If you have purchased a license within the jtel Cloud environment, your certificate will be provided and managed by jtel year-round. However, for example on On Premise systems, you will have to provide your own SSL-Certificate. As for our Partners Cloud systems, the certificate might be provided by you, or our partner.
jtel Cloud
The certificate is provided by jtel and managed year-round.
jtel Partner Cloud
On the cloud systems of our partners, the certificate will either be provided by our partner, or by you.
jtel On Premise
The certificate will be provided by you.
Preparations
If you are providing the SSL certificate for your jtel installation, the following things described below are required.
The DNS-Name used in this example is as follows:
The Gateway used in this example is as follows:
xx.xxx.xx.xxx
Naming the Website / DNS
Before aquiring a new certificate or using a preexisting one, a name for the jtel Portal website must be chosen. This DNS-Name must then be created in your Public DNS-Zone like Azure DNS or Google Public DNS to ensure that it will be accessible by via the public internet. The Alias below will be the Public IP-Adress of your Gateway. This Gateway will route the incoming requests to the jtel Load Balancer. The DNS-Entry will look something like this:
DNS-Name | DNS-Zone | Alias |
---|---|---|
acd | .johntelephony.com | xx.xxx.xx.xxx |
Routing https requests
After creating the public DNS-Entry, all https requests made to acd.johntelephony.com will be routed through the public internet to your Gateway xx.xxx.xx.xxx. The gateway must then be configured to forward the https-requests to the jtel load balancer in your internal network via https. The jtel Load Balancer, where the certificate is installed, will then decrypt the https-request and route the now traffic to the webserver or chatserver internally.
A simplified explanation of the route could look as follows:
https request from any device → Travel through public internet → Your Gateway → Unchanged https request Routed to jtel Load Balancer
SSL Certificate Chain
The full SSL-Certificate Chain is required for installation.
Certificate section | Explanation | Example Filename | Note |
---|---|---|---|
End entity certificate Alias Server Certificate | This certificate section is a digitally signed statement issued by the Certificate Authority to a person or system. | end_entity_cetificate.crt | This certificate binds the public key to its contained identifying information. It can also be called the Server Certificate. |
Intermediate certificate | This certificate section is a certificate which is signed and authenticated by the Root certificate. The section acts as a middle-man between the End entitiy and root certificate. | intermediate_certificate.crt | More than one intermediate certificates can exist in a chain, but at least one is required. |
Root certificate | A root certificate is a trusted certificate which stits at the top of the certificate chain. It identifies and belongs to the trusted CA (Certificate Authority). | root_certificate.crt | The root certificate is used to issue intermediate certificates. All certificates issued by a root certificate inherit the trust of the root certificate. |
Private key | The private key is a unique key generated by the party who requests the certificate in a CSR (certificate signing request). It is the part of the chain which is always kept secret and never shared. It should if possible only be installed locally on the machine where the certificate chain is installed. | private_key.key | The private key is used to decrypt the incoming messages which were encrypted using the public key. |
Installation
If your system previously had no certificate installed and was running via http, start here. If you are exchanging your certificate before its expiry and your jtel ACD was configured for https before, start here.
Change the haproxy configuration to https
For systems with one Load Balancer and HAProxy use this.
For redundant systems with two Load Balancers and HaProxys use this.
Create the haproxy.pem file
The certificate chain will be put together with a simple cat command in Linux.
# Create a backup of the current haproxy.pem file if required cp /etc/haproxy/haproxy.pem /<backup-location>/haproxy.pem # Build the haproxy.pem Certificate file cat end_entity_cetificate.crt intermediate_certificate.crt root_certificate.crt private_key.key > haproxy.pem # copy the haproxy.pem file to the correct location on the Load Balancer cp <your-path-to-.pem>/haproxy.pem /etc/haproxy/haproxy.pem # change the file access rights cd /etc/haproxy/ chmod 400 haproxy.pem # reload the haproxy systemctl reload haproxy
Tests
After finishing, test access with your new https URL.
Example URL Admin
https://acd.johntelephony.com/CarrierPortal/admin
Example URL Client
https://acd.johntelephony.com/CarrierPortal/login/<ResellerUID>/<ClientUID>
Useful openssl commands
openss can be used to for exapmle ensure that the end_entity_cetificate.crt and private_key.key match. It can also be used to ensure that the private key is not corrupted and to check the validiy of the certificate itself.
Use the following commands if needed:
Checking the private key
Make sure the private key is not corrupted. If the output “RSA key ok“ then the private key is correct. openssl rsa -check -noout -in private_key.key
End entitiy and private key match
# Make sure the end entity certificate and the private key match together. Calculate the modulus of the of the private key openssl rsa -modulus -noout -in private_key.key | openssl md5 # Calculate the modulus of the server certificate openssl x509 -modulus -noout -in end_entity_certificate.crt| openssl md5 # If both outputs are identical then the private key matches to the end entity certificate.
Checking the certificate validity
openssl x509 -text -in haproxy.pem
Converting .pfx Certificates to .pem format
# The following command can be used to convert a .pfx certificate file to .pem Format (the password for the certificate will be required): openssl pkcs12 -in acd.cg.internal.pfx -out /root/haproxy.pem -nodes