Frequently Asked Question
Secure protocols use SSL (Secure Sockets Layer) technology for establishing an encrypted link between a server and a client. An SSL Certificate is required in order to be able to establish a secure connection. SSL Certificates have a key pair: a public and a private key. These keys work together to establish an encrypted connection. The certificate also contains what is called the “subject,” which is the identity of the certificate owner.
To get a certificate, you must either create a certificate signing request on the server, use self-signed certificates, or use Let's encrypt certificates.
Let's encrypt Certificates
Let's encrypt certificates support was added in version 1.9.5. This service offers an automated process designed to overcome manual creation, validation, signing, installation, and renewal of
To issue a certificate using Let's encrypt's service, go to "Configuration :: System :: Certificates Management". You will see the "Let's Encrypt" tab. Click on the "New Certificate" button and fill in the hostname of the server as shown below:
NOTE: It is required that port 80 (HTTP) of the system is accessible from the internet using the hostname specified. This means that DNS must already be set up properly (A record fofr the hostname points to the system's internet IP). The hostname corresponds to the Common Name (CN) of the certificate's subject. Port 80 is used to verify the certificate request.
If something is not configured properly the certificate will fail to be issued and an error will be displayed explaining what went wrong. Otherwise the new certificate will appear:
Click on the hostname to view the details of the issued certificate. Let's Encrypt certificates are valid for 90 days, during which renewal can take place at any time. You can use the issued certificates in most services that require a certificate for encryption.
Certificates issued from a trusted CA
The certificate signing request process creates a private key and public key on your server. The CSR data file that you send to the SSL Certificate issuer (called a Certificate Authority or CA) contains the public key. The CA uses the CSR data file to create a data structure to match your private key without compromising the key itself. The CA never sees the private key.
It is also possible to use self-signed certificates that are entirely generated and signed by the same server. This is a quick, cheap and easy way to provide encryption options for the clients connections to the services provided. However, since those certificates are not verified by a trusted Certificate Authority, most clients will prompt the users with a security alert because the certificate was not verified:
Below is an example security prompt:
Most browsers or other client software provide a way to add a security exception for the specified certificates, so that they are considered trusted.
Self Signed Certificates
To produce a certificate go to "Configuration :: System :: Certificates Management". You will see the "Repository" tab. Click on the "Create Self-signed Certificate" button and fill the form as shown below:
The most important field here is the Name field. When this certificate is used by a server, the name of the certificate must be the same as the server's hostname, as advertised by the server. This hostname is the combination of the hostname and domain name as provided on the system general settings.
In our example, the full host name is mail.mydomain.com, so this is what we use as the certificate's name.
NOTE: The password you provide here will be used to encrypt the private key on the server. This password is not stored anywhere and cannot be recovered. Make sure you do not forget it. You will be prompted for this password whenever an operation is required to use this key (when issuing a new certificate, revoking a certificate etc.).
Finally click on the "Create Self-Signed Certificate" button.
You can now see the certificate that was generated.
Using the certificates
Now we can select the certificate that we created for use by our services. Let's use it in our mail server:
Go to "Configuration :: E-Mail Service :: General Settings" and click on the "Change" button next to the certificate.
At the popup prompt, click on the "Select from repository" button.
You should see here the certificates stored in the certificate repository.
Click on the certificate we created earlier (mail.mydomain.com). You will be prompted for the password that was used to create the certificate:
Fill in the password and click on the "OK" button.
The certificate should now be selected:
Finally click on the "Save" button and the secure protocols should be available right after.
You can easily check the certificate by accessing the webmail service over HTTPS now.
Secure services and associated ports
Secure POP3 connections are available on normal POP3 port (tcp 110) using TLS, or direct SSL connection on port 995,
Secure IMAP connections are available on normal IMAP port (tcp 143) using TLS, or direct SSL connection on port 993.
Secure SMTP connections are preferably established using port 587 and STARTTLS. It is also possible to use port 25 and STARTTLS or direct SSL connection to port 465, but these methods are considered deprecated.
Secure connection to the Groupware is available using HTTPS.
HTTPS connection on the default port 443*
TLS option on standard FTP port (tcp 21)
SFTP connection on port 9222
FTPS connection on port 990
TLS option on standard LDAP port (389*)
LDAPS connection on port 636*
* These ports can be customized
NOTE: Since version 1.9.2, a self-signed certificate is always created and is assigned to all services that can use it, in order to provide the ability to clients to connect securely. All encrypted protocols are now enabled by default.