- Solution Overview
- Security Layers
- Services Architecture
- Administration Tools Overview
- Clustered Operations
- Integrating with Other Solutions
Updated: July 30, 2021
Starting with Axigen X3, SSL certificates — including the Let's Encrypt ones — can be centrally managed from WebAdmin. See Managing SSL Certificates for more details.
Starting with version X2, Axigen can use the Let's Encrypt service to generate SSL certificates.
Let’s Encrypt is the first attempt by the Internet Security Research Group to make obtaining SSL certificates easier and in an automated way.
The certificates can be used for the following Axigen services:
Proxy services — WebMail Proxy, IMAP Proxy, POP3 Proxy
For each certificate it generates, Axigen will attempt automatic renewal 25 days before the certificate expires.
Prerequisites for Let’s Encrypt SSL Certificates
For Axigen to be able to generate SSL certificates using the Let's Encrypt service, 2 way network connectivity over HTTP and HTTPS is required between the Axigen server and the Let's Encrypt web servers.
Also, make sure that DNS entries for the hostname(s) you are planning to generate SSL certificates for have been properly configured.
For example, to generate a valid "Let's Encrypt" certificate file for webmail.example.com from your Axigen server that has the IP address 18.104.22.168, you should add a DNS A record entry similar with:
Check if the DNS entry has been propagated with the following command:
If you previously configured a CAA DNS record for your Axigen domain pointing to another certificate authority modify it to allow Let's Encrypt to issue the certificate. For example the CAA DNS entry for webmail.example.com would be similar to:
It is mandatory to have the CAA record set to the correct Certificate Authority but is optional to have this type of DNS record
The Let's Encrypt free SSL service places a limit on the number of requests you can register each day so, unless your network connectivity and DNS setup work, you may have to re-run your certificate request in the following day.
Generating and Installing a Certificate
Axigen uses a file system based certificate repository when generating and storing certificates.
With the exception of the
cert.pem file, which is the actual certificate used by SSL listeners, the files in the certificate repository are considered opaque to the system administrator. Files in the letsencrypt directory (default location
/var/opt/axigen/letsencrypt) should never be edited unless instructed by Axigen support.
Generating a Certificate from CLI
Certificate generation can be triggered from the CLI interface using
To connect to Axigen command line interface (CLI), you should use the
telnet command followed by your CLI Listener IP and port (the default Axigen settings uses IP 127.0.0.1 and port 7000).
To generate the "Let's Encrypt" certificate from the Axigen CLI interface for a specific domain (e.g. webmail.example.com), you can use commands similar to the following:
terms command parameter allows the sys admin to confirm that the Let's Encrypt service terms have been read and accepted.
See all available options in the
CERTS context by issuing the "help" command:
In the Axigen log file you should find lines similar to:
The generated SSL certificate will be available in your
<Axigen working directory>/letsencrypt/<domain name>. For example, on Linux:
Backing Up Your SSL Certificates
It is highly recommended that you back up your server certificate in a secure location (it is recommended to backup the SSL certificates in a password protected archive). This will allow you to restore your certificate and private key in case the original becomes corrupted.
Consider the fact that omitting an SSL certificate from your backup increases recovery time and complexity.
Installing the Certificate
Once the certificate has been generated, it can be assigned in WebAdmin (or CLI) to a given SSL listener.
For example, to add the newly generated certificate to a WebMail listener that was created using as IP 0.0.0.0 and port 443, you may use the following steps:
Open the WebAdmin interface and navigate to Services →WebMail→Click on "Edit" for the listener that is configured to use port 443 (the default https port)→SSL Settings tab )→Configure SSL subcategory
Tick the "Enable SSL for this listener" box
Under "Certificate file:" text box enter the certificate path that by default is letsencrypt/<domain name>/cert.pem
Under "Certificate Authorities file:" text box enter the certificate path that by default is letsencrypt/<domain name>/cert_auth.pem
Click on "Save Configuration"
After you completed this configuration, you may check the SSL listener, by opening its HTTPS address in a browser(e.g. https://webmail.example.com) and by clicking/hovering your mouse over the "lock icon" in the status bar of your browser:
To redirect all insecure connections you may edit the non-SSL listener (that by default is set on port 80) and under the SSL Settings tab )→Secure login subcategory → Tick the "Redirect to secure login page" option box and click on "Save Configuration".
You may add the certificate on any Axigen SSL listener (for example IMAP, SMTP, POP3) but if they have different hostnames, a certificate needs to be generated for each hostname and set on each listener.
Once a day Axigen checks if any of the domains' certificates are to be renewed; each check logs a couple of lines like:
Five days before the certificate expires, Axigen will attempt to automatically ask for renewal.
Starting with Axigen 10.2.2.53 the LE certificates renewing starts 25 days before expiry.
When a certificate in the renewal period is found, Axigen will log a few lines similar to:
Axigen will attempt to automatically ask for renewal:
Since certificate generation and renewal are operations that sometimes happen without sys admin intervention, Axigen uses email messages to notify the sys admin of progress regarding certificate operations.
Axigen will send alerts:
at certificate generation time (when the certificate is generated and when an error prevents Axigen from generating the certificate).
at certificate renewal time.
Axigen uses the following algorithm when deciding where to send notifications:
given a hostname webmail.example.com
it will tokenize the hostname and look for domain webmail.example.com, example.com
should it find domain example.com it will mail the notification to postmaster+Alerts@example.com and the contact email address provided at certificate generation time (if it exists)
if no domain matching the hostname is found, the notification is only sent to the contact email address provided at certificate generation time (if it exists)
Below you may find a renewal notification sample:
Validating the Let's Encrypt Peer Certificate
Axigen uses the operating system's certificate bundle to validate that the data is received from a trusted Let's Encrypt server.
Axigen checks for the certificate bundle path in the following order:
caBundlePath configured in axigen.cfg
if no path for caBundlePath is set in the Axigen configuration(axigen.cfg) – the default setting – Axigen X2 is using the working directory as bundle directory path (on all operating systems Axigen X2 places in the working directory a default certificate bundle file –
On Linux if above options do not result in a satisfactory result it tries to search for distribution's default certificate bundle paths
Taking into consideration the above order, usually there is no need to do any changes to caBundlePath