Getting 'Certificate expired' when trying to send mail

SYSTEM INFORMATION
OS type and version Rocky Linux 9.4
Webmin version 2.111
Usermin version 2.010
Virtualmin version 7.10.0
Theme version 21.10

Being told certificate has expired when trying to send mail even though I have manually created a new cert and copied files to all the usual places (and restarted postfix and dovecot):

Screenshot 2024-08-09 at 03.59.18

Certs are set-up/copied as per this post: How to configure SSL for Dovecot/Postfix manually? - #18 by Brook

Where else would Virtualmin look for certs? Does anything else need to be restarted? The domain itself is showing the correct cert date, but trying to send mail seems to be fetching the cert that expired yesterday.

Any idea what might be going on?

Go to virtualmin and then search for ssl certificate setup and go there.

on that screen at the bottom it should have a button to use the ssl cert for other services.

In the screenshot above it doesn’t show that option as I have already used it so it doesn’t show after that.

also on that screen to the right it should list what services are using your current ssl cert. like below.

What does yours show for used by services?

You can also add ssl certs for different services manually using the terminal.

sudo virtualmin install-service-cert --domain yourdomain.com --service proftpd --add-global

The above command adds the cert for proftpd but you can change that to postfix/dovecot or whatever service you want to use the cert.

Hope this helps.

Hi, thanks for the post but this is not what I am looking for. We need to be able to set up the certs via a script (as per this post: How to configure SSL for Dovecot/Postfix manually? - #18 by Brook) as we use HAProxy to handle https.

Having said that… it is working fine now. Wonder why it didn’t take effect immediately? :confused:

This is happening again - new certificate was obtained a couple of days ago but when I go to send an email it says the certificate has expired (and is showing the one old one when I click on view).

Have tried:

	systemctl restart postfix  
	systemctl restart dovecot

But has not made a difference.

Would my email client being holding on to an old cert? The website is showing the new one.

How can I check postfix and dovecot have got the latest certs?

Being told by whom? Where are you sending mail from and to? (i.e. do you mean from a client to Postfix on the Virtualmin server or do you mean sending from Postfix to a remote mail server?)

We generally need to see the exact error, and we need to see the relevant log entries.

You should not configure Dovecot and Postfix manually. You should use the “Set as default services certificate” button in the SSL Certificate page from one of your domains, whichever one you want to be the default certificate for mail services. (Modern systems should also use SNI for most services, so whatever domain name you connect with is generally the cert you’ll be served.)

Hi Joe, mail has been set up as pop/smtp on the server and I am getting the error when trying to send email from my computer (Apple Mail) as well as from software running on the server which has been configured to send mail.

They both say the certificate has expired (and indeed are showing the expiry date of the old cert). Where are the log entries? I’m guessing there won’t be any on the virtualmin server as it’s the clients that are rejecting the sending (they are reporting the cert as expired so are refusing to send).

I do not use virtualmin to create/update the certs. We use HAProxy on the server so HAProxy handles all of the SSL. A script runs Certbot twice daily to update any certs that are due to expire and our custom script then copies them to the locations as per this thread. The script then restarts dovecot and postfix with systemctl restart postfix and systemctl restart dovecot.

There is where they are copied to:

Webmin > Servers > Postfix > Certificate Mapping and Webmin > Servers > Dovecot > Edit Config Files (dovecot.conf) are also correctly set.

Everything seems like it should be pretty straight forward (it was working before - this only seems to be an issue after a cert gets updated). Does Dovecot/Postfix ‘cache’ certs? Should anything be done once the certs have been copied to the locations as described above?

[The odd thing is two domains were updated at the same time - the other one works fine, but this one doesn’t! The https sites work fine for both]

Here’s postfix status:

# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: disabled)
     Active: active (running) since Sun 2024-10-06 20:14:54 BST; 1min 15s ago
    Process: 4042177 ExecStartPre=/usr/sbin/restorecon -R /var/spool/postfix/pid (code=exited, status=0/SUCCESS)
    Process: 4042178 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
    Process: 4042180 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
    Process: 4042181 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
   Main PID: 4042249 (master)
      Tasks: 12 (limit: 408518)
     Memory: 21.0M
        CPU: 465ms
     CGroup: /system.slice/postfix.service
             ├─4042249 /usr/libexec/postfix/master -w
             ├─4042250 pickup -l -t unix -u
             ├─4042251 qmgr -l -t unix -u
             ├─4042260 smtpd -n submission -t inet -u -o stress= -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
             ├─4042261 proxymap -t unix -u
             ├─4042262 tlsmgr -l -t unix -u
             ├─4042263 anvil -l -t unix -u
             ├─4042281 smtpd -n smtp -t inet -u -o stress= -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
             ├─4042282 smtpd -n smtp -t inet -u -o stress= -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
             ├─4042535 smtpd -n smtp -t inet -u -o stress= -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
             ├─4042625 smtpd -n smtp -t inet -u -o stress= -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
             └─4042770 smtpd -n smtp -t inet -u -o stress= -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may

Oct 06 20:16:01 myserver.com postfix/smtpd[4042282]: warning: unknown[199.135.173.44]: SASL LOGIN authentication failed: authentication failure
Oct 06 20:16:01 myserver.com postfix/smtpd[4042282]: disconnect from unknown[199.135.173.44] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Oct 06 20:16:02 myserver.com postfix/smtpd[4042260]: warning: unknown[194.179.174.41]: SASL LOGIN authentication failed: authentication failure
Oct 06 20:16:02 myserver.com postfix/smtpd[4042260]: disconnect from unknown[194.179.174.41] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Oct 06 20:16:08 myserver.com postfix/smtpd[4042260]: connect from unknown[194.179.174.41]
Oct 06 20:16:08 myserver.com postfix/smtpd[4042535]: connect from unknown[172.17.0.2]
Oct 06 20:16:08 myserver.com postfix/smtpd[4042535]: SSL_accept error from unknown[172.17.0.2]: -1
Oct 06 20:16:08 myserver.com postfix/smtpd[4042535]: warning: TLS library problem: error:0A000415:SSL routines::sslv3 alert certificate expired:ssl/record/rec_layer_s3.c:1600:SSL alert number 45:
Oct 06 20:16:08 myserver.com postfix/smtpd[4042535]: lost connection after STARTTLS from unknown[172.17.0.2]
Oct 06 20:16:08 myserver.com postfix/smtpd[4042535]: disconnect from unknown[172.17.0.2] ehlo=1 starttls=0/1 commands=1/2 

A couple of other things I tried:

  • rebooting server (made no difference)
  • created a new dummy virtualmin server (domain account) (worked!)

Creating a new dummy server/domain via Virtualmin > Create Virtual Server seems to have fixed the issue. So my guess is something else needs to happen to complete the process we put together in this thread: How to configure SSL for Dovecot/Postfix manually? - #18 by Brook

I would guess that something needs to be copied to the Postfix config to make it aware a new cert has been created - any ideas if that’s the case? If so what are those steps?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.