Safely Create and Deploy Postfix TLS Certificates

You will finish with a Postfix SMTP server certificate workflow that can be checked before it changes configuration: test the defaults, generate a key and self-signed certificate, prepare a CSR or DANE records, and deploy only after reviewing the result. The examples match Postfix 3.8.6 and its postfix tls command. Allow 20 to 30 minutes, plus however long your certificate authority or DNS provider takes.

You need the postfix package, the postfix administrative command, a hostname that resolves to this server, and root privileges for commands that update Postfix configuration. Replace mail.example.org with the public SMTP hostname you actually use. These commands affect the SMTP service and private keys, so take a backup of the Postfix configuration before deployment.

1. Check the installed command and configuration

Confirm the version and find the configuration directory before generating anything:

$ postconf mail_version
mail_version = 3.8.6
$ postconf config_directory
/etc/postfix

The command is invoked as postfix tls, but the administrative interface is restricted to the superuser on this machine. Read-only inspection through postconf can normally be done as an ordinary user. Do not use a guessed configuration path in later commands.

2. Confirm that the defaults are safe to enable

enable-server changes settings only when the SMTP server TLS parameters still have their defaults. Test that condition first:

# postfix tls all-default-server
# printf 'status=%s\n' "$?"
status=0

Status 0 means all relevant server TLS settings are at their defaults. A non-zero result means the command will not silently take over an existing TLS design. Stop and inspect the current values instead:

$ postconf smtpd_tls_security_level smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_eccert_file smtpd_tls_eckey_file

Do not overwrite an intentional configuration merely to make the check pass. The client has a matching guard, all-default-client, if you are configuring outbound opportunistic TLS rather than the receiving SMTP server.

3. Generate a server key and certificate without deploying it

Generate an RSA key and self-signed certificate for the server name and its alternative name:

# postfix tls new-server-key -a rsa -b 2048 mail.example.org smtp.example.org

This creates files with UTC timestamped names such as key-20260926-120000.pem and cert-20260926-120000.pem in the Postfix configuration directory. The actual timestamp and output filenames will differ. The command displays deployment, CSR and TLSA commands; save that output. This subcommand does not deploy the new files.

RSA 2048 is the documented default. ECDSA is also supported when the local OpenSSL and clients support it:

# postfix tls new-server-key -a ecdsa -b secp256r1 mail.example.org smtp.example.org

Use only the documented curves secp256r1, secp384r1 or secp521r1 for broad interoperability. DSA is not supported. If you need both algorithm families, generate and deploy both rather than assuming every client can use ECDSA.

# ls -l /etc/postfix/key-*.pem /etc/postfix/cert-*.pem
# openssl x509 -in /etc/postfix/cert-YYYYMMDD-HHMMSS.pem -noout -subject -issuer -dates

Use the exact filenames printed by your run. The self-signed certificate is temporary until a CA-signed certificate replaces it.

4. Prepare a CA request or DANE record

For a public CA, produce a CSR from the generated key. The -k option accepts a pathname or an algorithm name such as rsa:

# postfix tls output-server-csr -k /etc/postfix/key-YYYYMMDD-HHMMSS.pem mail.example.org smtp.example.org > /root/mail.example.org.csr
# openssl req -in /root/mail.example.org.csr -noout -subject

Protect the CSR file, although it does not contain the private key. When the CA returns the server certificate, put the server certificate first in the chain file, followed by every required intermediate certificate. Keep the matching private key unchanged.

If you operate DANE, generate TLSA data from the key files and publish it before deployment:

# postfix tls output-server-tlsa -h mail.example.org /etc/postfix/key-YYYYMMDD-HHMMSS.pem

Wait for DNS secondaries and cached records to update before switching to a new key. A DANE deployment made in the wrong order can make TLS verification fail for remote senders.

5. Deploy the reviewed certificate and key

Deploy the certificate file and its matching private key. Use the exact paths from the generation step, or the CA chain file you prepared:

# postfix tls deploy-server-cert /etc/postfix/cert-mail.example.org-chain.pem /etc/postfix/key-YYYYMMDD-HHMMSS.pem

The filenames may be relative to config_directory, but absolute paths make a change record less ambiguous. Check the resulting parameters:

$ postconf smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_eccert_file smtpd_tls_eckey_file

Reload Postfix through the normal service manager used by your system, then test an SMTP connection from a separate host. If the certificate is wrong, redeploy the previous certificate and key with the same deploy-server-cert command, then reload again. Do not delete old files until mail flow and certificate validation have passed.

6. Enable opportunistic TLS only when appropriate

If every server TLS setting was still at its default and you want Postfix to enable opportunistic TLS and create its own initial certificate, the combined operation is:

# postfix tls all-default-server && postfix tls enable-server mail.example.org

If the guard fails, enable-server suggests parameter settings without changing them. Treat that output as advice to review, not as a command to paste blindly. For outbound SMTP, the equivalent guarded operation is:

# postfix tls all-default-client && postfix tls enable-client

Neither guard proves that a remote server will trust your certificate, and opportunistic TLS is not the same as mandatory authenticated encryption.