Issue Postfix SNI TLS-Certs not auto-updated

[TimReeves]

This morning I could not send mail from some accounts, Thunderbird said the certificate has expired.

Problem: When selecting "SSL/TLS certificate for mail" in the mail settings of an individual domain,
the certificate for Postfix for that domain is stored by Plesk in /var/spool/postfix/plesk/certs.db

Sadly it is NOT (yet) updated by the SSL-It! or Lets Encrypt Extension:

FAQ for Plesk
If SNI for mail is supported now, how can I automate mail securing with the SSL It! or Let's Encrypt extensions?
Such automation is currently not supported. However you can issue a wildcard SSL/TLS certificate via SSL It! or Let's Encrypt and manually assign this certificate to mail using the "Mail Settings" tab in the subscription mail settings.

# postconf mail_version => mail_version = 3.4.5 This is the NEW one which supports SNI

o Show which certificate is currently being presented by Postfix
# echo 'Q' | openssl s_client -connect localhost:465 -servername {domain} -showcerts 2>&1

o Show a particular certificate stored in /var/spool/postfix/plesk/certs.db:
# postmap -s /var/spool/postfix/plesk/certs | grep '{domain}' | cut -d$'\t' -f2 | base64 -d

Quick and Dirty Fix: Change the Domain setting for "SSL/TLS certificate for mail" to "Not selected" and then back to the Lets Encrypt of the domain. This puts the current version of the Lets Encrypt certificate into /var/spool/postfix/plesk/certs.db - but note that there will still be no automatic updates, the procedure needs to be repeated manually every 2 months.

Dovecot: /etc/dovecot/conf.d/11-plesk-security-ssl.conf sets the default cert /etc/dovecot/private/dovecot.pem
Then any domains (and aliases) with an individual "SSL/TLS certificate for mail" get an own config file:
14-plesk-sni-{domain}.conf

Here the certificate is configured like this:
local_name {domain} {
ssl_cert = </opt/psa/var/certificates/scfXhbsvc
ssl_key = </opt/psa/var/certificates/scfXhbsvc
}

Original Lets Encrypt certificate parts linked
at /usr/local/psa/var/modules/letsencrypt/etc/live/{domain}
to /usr/local/psa/var/modules/letsencrypt/etc/archive/{domain}

The certificate at /opt/psa/var/certificates/scfXhbsvc is generated from the current parts.
So it looks like Dovecot will get the current certificate, problem is only with Postfix.

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"

For me this is not an option for Dovecot, as I previously had an own solution based on acme.sh to provide SNI-based certificates. So all my users email client accounts are set up for IMAP to expect the correct domain and certificate )-:

What to do? I need the automatic update of /var/spool/postfix/plesk/certs.db asap! I'm sure many others will too, as the 3-month certificates from Lets Encrypt now start to expire.

Last idea: What about using a wildcard cert as noted in the FAQ?
A hassle to have to add a DNS record, but never mind, tried it.

o Dovecot works as expected, picks up the new wildcard cert in /opt/psa/var/certificates
o Postfix - hard to tell. The new wildcard cert has been put into /var/spool/postfix/plesk/certs.db - but will it be updated?

 

[sebgonzes]

Hello, seem have an very similar problem : Issue - Problem postfix with an lot of ssl renew @IgorG , thanks to review the case!

 

[TimReeves]

Thanks to @sebgonzes for linking up. Indeed I have been wondering, when a staff member can reply to this issue? @IgorG - can you write something about this issue? Thanks, Tim

 

[IgorG]

I just note that latest SSLIt! extension update (from 26.12.2019) can update LE certificates for mail server. For postfix and dovecot.
Certificates will not be updated if you have only one LE extension installed.

 

[Adam Dobruczky]

I just note that latest SSLIt! extension update (from 26.12.2019) can update LE certificates for mail server. For postfix and dovecot.
Certificates will not be updated if you have only one LE extension installed.

I can confirm this problem too, with the latest LE and SSL iT! extension, on debian 9.

If i manually update a subscription's mail setting, (everything is checked, i just click on save settings) than the proper sni conf in /etc/dovecote/ and by postfix updates.
Automatic cert update by SSL it! DO NOT update those conf files, i have tested it on several servers.

 

[learning_curve]

FWIW We haven't had any of the issues that are described above.

However... Every domain that we provide a mail service for, also uses a Let's Encrypt wildcard certificate too, which always has to be renewed manually, due to the required DNS verification checks.This means that it's not definitive evidence in our case unfortunately, because any domains that we host, that auto-renew their normal, non-wildcard Let's Encrypt certificates, don't use the mail service at all. So there's no mail or SNI checks required for them afterwards anyway.

The post above from @Adam Dobruczky doesn't specifically say, so just guesssing here, but it looks like some of the certificates that were manually renewed in his tests were actual, normal, non-wildcard Let's Encrypt certificates?

If so, wouldn't our own experience and the post above from @Adam Dobruczky reinforce the probability that the auto-renew function, is actually the area where the bug is present? It certainly does appear that way, because in both our cases, the renewal process itself, works absolutely fine... if... it's done manually!

 

[Adam Dobruczky]

Hi @learning_curve!

You have may right with the auto-renew function of the certifications. We use wildcard cert. to all domains, and before the latest update of the SSL it! extension there was no problem with the auto-renewal. (everybody used their own domain as imap/pop host eg: domain.com)

But interesting that after the ext. update and after an auto-update of a certification, postfix still use the old outdated one for the domain, what should not exist any more.

So i think the problem is not in the renewing process because it works for wildcard too.

I will testing it for a while

 

[G J Piper]

I'm experiencing this too. I upgraded to Obsidian 3 months ago now, and therefore all my certs are expiring. They were actually renewed automatically on time, but the SMTP certs are not renewed unless you manually re-issue a certificate in the GUI.

I'm leaving the real domain in the code on in this email so you can check them yourself if needed.
This user is not using any SMTP but has it configured so I let it stay expired since the domain certs are reading correctly for HTTP.

Running this command shows an expired certificate:

echo | openssl s_client -servername mail.corlisspainting.com -connect mail.corlisspainting.com:465 2>/dev/null | openssl x509 -text

While running the same command checking it from a different port reveals that the certificate is renewed correctly for different ports:

echo | openssl s_client -servername mail.corlisspainting.com -connect mail.corlisspainting.com:443 2>/dev/null | openssl x509 -text

To allow my customers to send email I had to re-issue all the certificates for the domains I host manually in the GUI.

Is there a faster workaround by command line somehow?

I am running Obsidian with SSLit and Let's Encrypt up to date.
I am not using wildcard certificates.

 

[learning_curve]

To allow my customers to send email I had to re-issue all the certificates for the domains I host manually in the GUI

This ^^ kinda of confirms the previous supposition in our previous post i.e. the auto-renew function

Running this command shows an expired certificate:

echo | openssl s_client -servername mail.corlisspainting.com -connect mail.corlisspainting.com:465 2>/dev/null | openssl x509 -text

While running the same command checking it from a different port reveals that the certificate is renewed correctly for different ports:

echo | openssl s_client -servername mail.corlisspainting.com -connect mail.corlisspainting.com:443 2>/dev/null | openssl x509 -text

We have no expired date issues, if we run those commands on any of our domains that are using the mail service c/w wildcard certificates that have been manually renewed.

Is there a faster workaround by command line somehow?

If the bug IS indeed the auto-renew function, unless you write your own script to manually renew them all, can't see that there could be a faster workaround. Has anybody that uses the auto-renew function for domains that have the mail service applied actually posted a bug with Plesk yet?

I am running Obsidian with SSLit and Let's Encrypt up to date. I am not using wildcard certificates.

FWIW We're running the same but do use wildcard certificates on all domains with the mail service (perhaps quite a lucky choice in this case...).

 

[G J Piper]

This kinda of confirms the previous supposition in our previous post i.e. the auto-renew functionWe have no expired date issues, if we run those commands on any of our domains that are using the mail service c/w wildcard certificates that have been manually renewed.

Just to clarify, the commands shown are on one of the only domains I left in the state of auto-renew that they accomplished, showing that the certificate has indeed renewed as is seen from Dovecot, but Plesk's configuration of postfix is not serving the renewed certificate for some reason for SMTP unless it is manually renewed.

 

[learning_curve]

Just to clarify, the commands shown are on one of the only domains I left in the state of auto-renew that they accomplished, showing that the certificate has indeed renewed as is seen from Dovecot, but Plesk's configuration of postfix is not serving the renewed certificate for some reason for SMTP unless it is manually renewed

Yes, fully understood and it is the same problem for the OP and others (isn't it?) The short term workaround (as has been included in posts above) being; manually renewing a certificate, thus our earlier supposition of the bug, being somewhere within the associated Plesk auto-renew function.

 

[vaelu]

Hello @TimReeves

Thank you very much for reviewing this case and writing a detailed report about it.
We were struggling to find the issue since our Postfix certificate in /etc/postfix/postfix.pem and the Dovecot certificate in /etc/dovecot/private/dovecot.pem were both correctly updated from the certificate we uploaded in Tools & Settings → SSL/TLS Certificates → Certificate for securing mail.

But still checking the certificate with openssl s_client -showcerts -connect mail.example.com:465 -servername mail.example.com threw the error Verify return code: 10 (certificate has expired) and we didn't know why.

After deselecting all individual certificates for the mail domains in the Plesk control panel, the file /var/spool/postfix/plesk/certs.db was updated - before it was not.

Would be nice if this bug would get fixed. Thanks.

 

[Fredrik Svensson]

Hi everyone.

Do you know if there is any official bug report written about this?
I represent a web provider company with the exact same problem. Certificates for Dovecot (incoming mail) are replaced with the newly generated by Let's Encrypt while the corresponding for postfix (SMTP) are not. Very frustrating.

Cheers
/Fredrik

 

[larsg]

I have this exact problem on a second server now. Certificates do not renew in the postfix map and it holds still the old cert from 3 months ago. (i am not sure if i have changed some cert options in the meanwhile.)

Inspecting those with postmap -s /var/spool/postfix/plesk/certs | grep MAILDOMAIN | cut -d$'\t' -f2 | base64 -d gives me those old certs, despite that /etc/postfix/postfix.pem as configured in main.cf is up to date.

My solution:

I removed the custom setting of SSL certificates under the Email settings (plesk url like /smb/mail-settings/edit/id/5/domainId/5) and immediately the output of `postmap -s certs` is empty and SMTPS uses the correct certificate.

 

[Jérôme Dejoie]

Still the same problem when using the command :

plesk bin certificate --update 'domain.com certificate' -domain domain.com

The new certificate is not deployed on Postfix. Actual workaround is to run this command after :

plesk bin subscription_settings --update domain.com -mail_certificate 'domain.com certificate'

Found here.

 

[big_cookie]

I still (or again?) encountered the issue on latest Plesk Obsidian Web Admin Edition, Version 18.0.54 Update #4.

The above commandlines helped me fixing this. I will potentially need to put this on a cron job. Anybody knows, if the issue is known to Plesk and being worked on?

 

[futureweb]

Still the same problem when using the command :

plesk bin certificate --update 'domain.com certificate' -domain domain.com

The new certificate is not deployed on Postfix. Actual workaround is to run this command after :

plesk bin subscription_settings --update domain.com -mail_certificate 'domain.com certificate'

Found here.

This forum comment just became our support team's hero, potentially slashing hours from their monthly workload. Taking inspiration from the solution shared here, we're crafting a script to automate SSL certificate renewal for all our mail.dom.tld domains. Running it bi-monthly should keep everything shipshape!

Everyone please also upvote here: Add possibility issue Let's Encrypt SSL certificate for mail server when the "A" DNS record for domain is pointing to another server

 

[futureweb]

First untested script draft: Question - Issues with SSL Certificate Renewal for Mail Services in Plesk: Seeking Automated Solution via CLI or API