Let's Encrypt Support

The Axigen Solution: Overview & Architecture

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:

  • WebMail

  • IMAP

  • POP3

  • SMTP Incoming

  • 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, 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

Certificate Repository

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 CERTS context.

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 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:

The optional 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 and port 443, you may use the following steps:

  1. Open the WebAdmin interface and navigate to ServicesWebMail→Click on "Edit" for the listener that is configured to use port 443 (the default https port)→SSL Settings tab )→Configure SSL subcategory

  2. Tick the "Enable SSL for this listener" box

  3. Under "Certificate file:" text box enter the certificate path that by default is letsencrypt/<domain name>/cert.pem

  4. Under "Certificate Authorities file:" text box enter the certificate path that by default is letsencrypt/<domain name>/cert_auth.pem

  5. 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.

Automatic Renewal

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 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:

Progress Notifications

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:

  1. at certificate generation time (when the certificate is generated and when an error prevents Axigen from generating the certificate).

  2. at certificate renewal time.

Axigen uses the following algorithm when deciding where to send notifications:

  1. given a hostname webmail.example.com

  2. it will tokenize the hostname and look for domain webmail.example.com, example.com

  3. 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)

  4. 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:

  1. caBundlePath configured in axigen.cfg

  2. 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 – cacert_default.pem)

  3. 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