Let's Encrypt and Dovecot not updating SSL Cert for host domain

[samrich]

@pcmerc

Well, you were right on the SMTP complaining. After running the nmap command we get the same results for all the ports for IMAP, POP, and SMTP:

Starting Nmap 6.40 ( http://nmap.org ) at 2022-08-17 12:57 CDT
Nmap scan report for domain1.com (123.45.678.910)
Host is up (0.000040s latency).
rDNS record for 123.45.678.910: server3.domain1.com
PORT    STATE SERVICE VERSION
587/tcp open  smtp    Postfix smtpd
|_smtp-commands: server3.domain1.com, PIPELINING, SIZE 52428800, VRFY, ETRN, STARTTLS, AUTH PLAIN LOGIN, AUTH=PLAIN LOGIN, ENHANCEDSTATUSCODES, 8BITMIME, DSN,
| ssl-cert: Subject: commonName=domain1.com
| Not valid before: 2022-04-20T08:44:03+00:00
|_Not valid after:  2022-07-19T08:44:02+00:00
|_ssl-date: 1987-02-12T11:23:21+00:00; -35y186d6h34m33s from local time.
Service Info: Host:  server3.domain1.com

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.75 seconds

So, as you can see, the “Not valid” before and after are set to dates for the last successful Let’s Encrypt grab of SSL certs. All of our domains’ sites are working as far as HTTPS is concerned. And we are not getting any errors when the Let’s Encrypt gets a new cert on its own, it is just not updating the services.

Plus, we are still looking into opening a Bug report from what we discovered with subdomains last night. (see post above)

[pcmerc]

What is your cert path in /etc/postfix/main.cf:

# Incoming
smtpd_tls_cert_file=/etc/letsencrypt/live/admin.example.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/admin.example.com/privkey.pem

# Outgoing
smtp_tls_cert_file=/etc/letsencrypt/live/admin.example.com/fullchain.pem
smtp_tls_key_file=/etc/letsencrypt/live/admin.example.com/privkey.pem

Is what I use in my postfix config for the hosts certs but there are also certs defined in sni_map that I also update & then regenerate that file using postmap -F sni_map

SNI will only work version of postfix that support it. I don’t recall if that started on 18.04.x or 20.04.x I’d have to do some testing etc.

I bet I can help ya fix the issues, I love to troubleshoot/fix problems.

I use something like the following to generate a full set FQDN cert: certbot certonly -a webroot -i apache -w /var/www/html -d example.com -d www.example.com -d webmail.example.com -d admin.example.com -d mail.example.com -d autodiscover.example.com --debug-challenges -vvvv --email user@example.com --agree-tos --renew-by-default -n

add the --dry-run to test initially. Use certbot certificates to get a list of current certs etc. Remove old ones & keep them clean.

[samrich]

Well, didn’t have a main.conf in that folder, but did have a main.cf. Looks like most of the entries are at the end of the file:

readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unknown_reverse_client_hostname reject_unauth_destination
mailbox_size_limit = 0
allow_percent_hack = no
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
smtpd_use_tls = yes
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level = may
smtp_tls_security_level = may
message_size_limit = 52428800
smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated reject_unknown_sender_domain reject_unknown_reverse_client_hostname reject_unknown_client_hostname
relay_domains = $mydestination permit_mynetworks permit_sasl_authenticated defe_unauth_destination
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access hash:/etc/postfix/helo_access reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_helo_required = yes
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

I can confirm the postfix.cert.pem and postfix.key.pem match what’s in the Dovecot files. I can also confirm that the files were created all the way back in April on the day that the nmap output shows for “Not valid before: 2022-04-20”. Which means in April was the last time these files were updated.

Also notice that there is now smtp_tls_cert_file like what you shared. I only have the smtpd_tls_cert_file options.

Finally, Postfix version is 2.10.1. This is a CentOS 7.9.2009 box that has been running Virtualmin for several years. Virtualmin and Webmin are up to date. I think Postfix supports SNI in versions 3.4 and later.

I’m cool with using a single domain (domain1.com) as the SMTP, POP, and IMAP incoming and outgoing server for all of our clients. So, SNI doesn’t matter much. Just need to direct the latest SSL certs I guess to these services.

[RJM_Web_Design]

@samrich

I think Postfix supports SNI in versions 3.4 and later.

Yes. Ghetto Forge has a package for CentOS 7.x if you’re interested. I managed to do the upgrade successfully despite being unfamiliar with Postfix at the time. It ran without a hitch until the server was decomissioned.

[pcmerc]

You should be able to update all the related service configs, postfix, dovecot, etc, with the path to your new cert.
If you get stuck, reach out. I love to troubleshoot.

[pcmerc]

Yes, I remember the days of working with RHEL/CentOS. I used to spend a lot of my time rebuilding rpm’s with newer versions of the source because the packages are always out of date & old.

[paulM]

Update renewal resets the period between renewals of Let’s Encrypt. You can change the period without actually triggering the renewal.

[samrich]

Thanks @paulM, that clarified the buttons.