Facebook
Twitter
- Server operating system version
- CentOS Linux 7.9.2009 (Core)
- Plesk version and microupdate number
- Version 18.0.43 Update #1
This morning I ran into issues with the TLS cert on mail. The mail services – Dovecot + Postfix are secured with Let’s Encrypt certs issued by Plesk, although for some reason I sometimes need to come into the Home > Tools & Settings > SSL/TLS Certificates panel and use the ‘+ Let’s Encrypt’ button to create a new cert. I then manually rename it to the server fqdn, start and end dates and ensure the cert securing Plesk and securing mail is set to the new cert. All good, has worked like this for years across numerous Plesk servers, until today.
This morning Outlook started giving me cert errors. Checking on the SSL/TLS certs panel I could see the cert in use was named <[fqdn] 29-Mar-22 to 27-Jun-22> and today is 03-Jun. The Plesk panel itself did indeed was using a LE cert to 27-Jun, but mail was showing one to 03-Jun which had just expired despite the panel saying it was using the cert to 27-Jun. What’s going on?
I refreshed the default cert via the Plesk panel and changed both Plesk and Email to the new LE cert running to 01-Sep. Despite this update, both Dovecot on mail collection and Postfix on SMTP were reporting this other 03-Jun cert … which wasn’t even in my list of certs under Home > Tools & Settings > SSL/TLS Certificates
Searching the Plesk KB I found ‘How to secure Plesk and mail server with Let's Encrypt certificate via CLI?’ and so refreshed that way. NO CHANGE!
Then I found ‘[Bug?] Dovecot mail certificate wrong paths’ and 'interpolating' from that specific issue, found <14-plesk-sni-[domain].conf> was pointing to a cert file from 05-Mar. That would indeed be expiring today as was clearly the cert in use. A manual update to <14-plesk-sni-ipsa-[domain].conf> to point to one of the certs issued today resolved Dovecot, but this is only a temp fix, because as the file notes: “DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY, SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.” Quite so, and I’d be more than happy not to be ‘playing’ like this.
Of course, the Postfix SMTP service was still failing with the 03-Jun expired cert, so I went looking at that.
This led me to ‘Postfix SNI TLS-Certs not auto-updated’ and this got me to go check the cert under the subscription for the domain used for the mail service. Here I discovered the cert was indeed expiring today and so here was the clue. The cert related to this domain was clearly in use, not the default server cert.
The article mentions; “But what happens to Dovecot and Postfix when we deselect "SSL/TLS certificate for mail" on a domain? They both default to the standard mail certificate as set in "Tools & Settings | SSL/TLS Certificates". Ah ha!
This cert should have also been auto-renewed and I have no idea why ths wasn't the case as a ‘Reissue’ immediately renewed the cert without acme-challenge or other problem. And this refresh also immediately resolved the Postfix issue as I ensured the ‘Assign the certificate to the mail domain’ option was unchecked during the renewal.
Looking then again in /etc/dovecot/conf.d I noticed the <14-plesk-sni-[domain].conf> I had previously manually update had now disappeared, clearly having been removed during the cert renewal, however, other <14-plesk-sni-[other-domains].conf> files do still exist and inspecting a few of the subscriptions associated with these I see the ‘Assign the certificate to the mail domain’ option under the renew cert is enabled on each domain for which there is a corresponding <14-plesk-sni-[domain].conf> file.
Has there been some Plesk update recently over SNI support for SMTP/POP3/IMAP on multiple domains on a single Plesk server? ’14-plesk’ sounds like this has been around a long time given we’re on v18 at the moment, but this is the first time I’ve had this issue in maybe 20 years. What’s happened? Wondering if I’m going to go around this problem again in the future!
I presume too that now it's possible for the single mail service to support multiple domains. This then does away with the default cert managed via Home > Tools & Settings > SSL/TLS Certificates and instead uses separate certs under each subscription for mail sent/received via that domain??
In the past I have always used only mail fqdn, basically the default server domain, as the mail server for all domains on a single Plesk box. In the past this seemed to be the only way to support mail over TLS, but it would seem things have changed although 'somehow' the ‘Assign the certificate to the mail domain’ option has been enabled, I presume via some Plesk update which caused this issue.
Anyone else had similar issues or any general advice about this and avoid a mail outage?
This morning Outlook started giving me cert errors. Checking on the SSL/TLS certs panel I could see the cert in use was named <[fqdn] 29-Mar-22 to 27-Jun-22> and today is 03-Jun. The Plesk panel itself did indeed was using a LE cert to 27-Jun, but mail was showing one to 03-Jun which had just expired despite the panel saying it was using the cert to 27-Jun. What’s going on?
I refreshed the default cert via the Plesk panel and changed both Plesk and Email to the new LE cert running to 01-Sep. Despite this update, both Dovecot on mail collection and Postfix on SMTP were reporting this other 03-Jun cert … which wasn’t even in my list of certs under Home > Tools & Settings > SSL/TLS Certificates
Searching the Plesk KB I found ‘How to secure Plesk and mail server with Let's Encrypt certificate via CLI?’ and so refreshed that way. NO CHANGE!
Then I found ‘[Bug?] Dovecot mail certificate wrong paths’ and 'interpolating' from that specific issue, found <14-plesk-sni-[domain].conf> was pointing to a cert file from 05-Mar. That would indeed be expiring today as was clearly the cert in use. A manual update to <14-plesk-sni-ipsa-[domain].conf> to point to one of the certs issued today resolved Dovecot, but this is only a temp fix, because as the file notes: “DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY, SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.” Quite so, and I’d be more than happy not to be ‘playing’ like this.
Of course, the Postfix SMTP service was still failing with the 03-Jun expired cert, so I went looking at that.
This led me to ‘Postfix SNI TLS-Certs not auto-updated’ and this got me to go check the cert under the subscription for the domain used for the mail service. Here I discovered the cert was indeed expiring today and so here was the clue. The cert related to this domain was clearly in use, not the default server cert.
The article mentions; “But what happens to Dovecot and Postfix when we deselect "SSL/TLS certificate for mail" on a domain? They both default to the standard mail certificate as set in "Tools & Settings | SSL/TLS Certificates". Ah ha!
This cert should have also been auto-renewed and I have no idea why ths wasn't the case as a ‘Reissue’ immediately renewed the cert without acme-challenge or other problem. And this refresh also immediately resolved the Postfix issue as I ensured the ‘Assign the certificate to the mail domain’ option was unchecked during the renewal.
Looking then again in /etc/dovecot/conf.d I noticed the <14-plesk-sni-[domain].conf> I had previously manually update had now disappeared, clearly having been removed during the cert renewal, however, other <14-plesk-sni-[other-domains].conf> files do still exist and inspecting a few of the subscriptions associated with these I see the ‘Assign the certificate to the mail domain’ option under the renew cert is enabled on each domain for which there is a corresponding <14-plesk-sni-[domain].conf> file.
Has there been some Plesk update recently over SNI support for SMTP/POP3/IMAP on multiple domains on a single Plesk server? ’14-plesk’ sounds like this has been around a long time given we’re on v18 at the moment, but this is the first time I’ve had this issue in maybe 20 years. What’s happened? Wondering if I’m going to go around this problem again in the future!
I presume too that now it's possible for the single mail service to support multiple domains. This then does away with the default cert managed via Home > Tools & Settings > SSL/TLS Certificates and instead uses separate certs under each subscription for mail sent/received via that domain??
In the past I have always used only mail fqdn, basically the default server domain, as the mail server for all domains on a single Plesk box. In the past this seemed to be the only way to support mail over TLS, but it would seem things have changed although 'somehow' the ‘Assign the certificate to the mail domain’ option has been enabled, I presume via some Plesk update which caused this issue.
Anyone else had similar issues or any general advice about this and avoid a mail outage?
