SNI Certificate Selection for SSL listeners

Axigen Documentation

Automatic SNI certificate selection for SSL listeners is available starting with Axigen X7 (10.7.0).

Overview

Axigen supports Server Name Indication (SNI) for SMTP, IMAP, POP3 and proxy services. When a client connects using TLS (either implicit SSL or STARTTLS) and provides an SNI hostname, Axigen automatically selects the appropriate certificate from the certificate directory. If no certificate matches the requested hostname, the listener-level certificate is used as a fallback.

How It Works

At startup, at regular intervals and whenever a certificate changes, Axigen scans two directories for certificates:

  • {WORKDIR}/certs/ — manually managed certificates (PEM files containing both certificate and private key)

  • {WORKDIR}/letsencrypt/ — Axigen-managed Let's Encrypt certificates

Each certificate file is examined and indexed by its Common Name (CN) and Subject Alternative Names (SANs). Certificates that are expired, invalid, or missing a matching private key are skipped.

When an SSL client (IMAP, POP3, etc) initiates a TLS handshake with an SNI hostname, Axigen looks up the hostname in the certificate index. If a match is found, that certificate is served. Otherwise, the certificate configured on the listener is served.

Wildcard certificates are supported. A certificate with CN *.example.com will match any subdomain such as mail.example.com or imap.example.com.

Certificate Requirements

For a certificate in certs/ to be eligible for SNI selection, the PEM file must:

  • Contain a valid, non-expired X.509 certificate

  • Contain a private key that matches the certificate

  • Both certificate and key in the same .pem file

For Let's Encrypt certificates in letsencrypt/<hostname>/, the following files must be present:

  • cert.pem — the certificate

  • cert_priv.key — the private key

Cache and Renewal

Certificates are cached at the server level and shared across all SSL listeners (including listeners that are STARTTLS aware). The cache is invalidated automatically when:

  • A certificate file is added, deleted or modified on disk

  • A certificate is replaced or renewed through the WebAdmin interface

  • A Let's Encrypt certificate is renewed by Axigen

No restart is required after adding, replacing, or renewing certificates.

Conflict Resolution

If multiple certificates cover the same hostname (e.g., both a manually uploaded certificate and a Let's Encrypt certificate for mail.example.com), the most recently issued certificate is preferred.

Logging

Certificate discovery and SNI decisions are logged at the INFO level. The log prefix identifies the service (IMAP, POP3, etc.).

During certificate scanning:

CertCache scanning certs directory '/var/opt/axigen/certs'
CertCache 'mail_example_com.pem' is valid, CN='mail.example.com', 2 SANs
CertCache 'mail_example_com.pem' indexed hostname 'mail.example.com'
CertCache rebuild complete, 3 certificates covering 5 hostnames

During TLS handshake:

SNI request for 'mail.example.com', serving matched certificate 'mail_example_com.pem'

When no matching certificate is found:
SNI request for 'unknown.example.com', no matching certificate, serving listener certificate 'axigen_cert.pem'

Affected Services

  • IMAP (ports configured for IMAPS and IMAP+STARTTLS)

  • POP3 (ports configured for POP3S and POP3+STARTTLS)

  • SMTP (ports configured for SMTPS and SMTP+STARTTLS)

  • IMAP proxy

  • POP3 proxy

Other services (WebMail) continue to use their existing virtual host certificate configuration.