Best Practices for SSL Certificate Hostname Configuration in SMTP Server (Exim/MTA Setup)


2 views

When configuring TLS for an SMTP server, the certificate hostname must match what remote clients expect to see. In your case with:

  • Server hostname: foo.example.com (192.0.2.1)
  • MX records pointing to mx.example.com
  • Exim as MTA handling multiple domains

The SSL certificate should contain mx.example.com as the primary CN (Common Name) and SAN (Subject Alternative Name). Here's why:

# Example OpenSSL certificate configuration
[ req ]
default_bits       = 2048
default_keyfile    = mx.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
countryName                = Country Name (2 letter code)
stateOrProvinceName        = State or Province Name
localityName               = Locality Name
organizationName           = Organization Name
commonName                 = mx.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = mx.example.com
DNS.2 = foo.example.com  # Optional for management access

SMTP clients perform TLS hostname verification against:

  1. The hostname used in MX records (mx.example.com)
  2. The EHLO/HELO response (foo.example.com)

Modern MTAs prioritize MX hostname matching. For maximum compatibility:

# Exim TLS configuration snippet (exim.conf)
tls_certificate = /etc/ssl/certs/mx_example_com.pem
tls_privatekey = /etc/ssl/private/mx_example_com.key
tls_advertise_hosts = *

For a multi-domain setup, consider these certificate strategies:

Option Pros Cons
Single cert with mx.example.com Simplest to maintain May trigger warnings if clients check HELO host
Wildcard certificate (*.example.com) Covers all subdomains Security implications if key compromised
Multi-SAN certificate Explicitly lists all valid names More complex certificate management

Use these commands to validate your setup:

openssl s_client -connect mx.example.com:25 -starttls smtp -servername mx.example.com
openssl x509 -in /path/to/cert.pem -text -noout | grep -A1 "Subject Alternative Name"

Online tools like checktls.com are correct - they verify the MX hostname match, which is the standard behavior for most SMTP implementations including Exim, Postfix, and Exchange.

For large-scale deployments, automate certificate management with:

  • Let's Encrypt ACME protocol with DNS-01 challenges
  • Certificate transparency logs monitoring
  • OCSP stapling configuration in Exim
# Automated renewal with Certbot for Exim
certbot certonly --manual --preferred-challenges=dns \
  -d mx.example.com \
  --manual-auth-hook /path/to/dns-auth-script.sh \
  --non-interactive --agree-tos \
  --email admin@example.com

When configuring TLS for an SMTP server like Exim, the certificate's hostname must match what remote clients expect to see during the TLS handshake. In your case with:

  • Server hostname: foo.example.com
  • MX record: mx.example.com
  • IP address: 192.0.2.1

The SSL certificate should contain mx.example.com as the primary hostname because:

  1. Remote MTAs connect using the MX record (mx.example.com)
  2. Modern SMTP clients verify the certificate against the hostname they connected to
  3. RFC 6125 specifies this as the proper verification method

Here's how to properly configure your Exim server:


# In exim.conf
tls_certificate = /etc/ssl/certs/mx.example.com.crt
tls_privatekey = /etc/ssl/private/mx.example.com.key
tls_advertise_hosts = *

For maximum compatibility:

  • Include both mx.example.com and foo.example.com as Subject Alternative Names (SANs)
  • Use a certificate from a trusted CA (not self-signed for production)
  • Ensure the certificate includes the full chain

Verify your setup with these commands:


openssl s_client -connect mx.example.com:25 -starttls smtp
checktls.com/TestReceiver

Avoid these mistakes:

  • Using server hostname when clients connect via MX record
  • Mismatched HELO/EHLO and certificate names
  • Missing intermediate certificates