Resolved Let's encrypt webmail keeps using old certificate

[m20230711]

Server operating system version

CentOS 7

Plesk version and microupdate number

Plesk Obsidian 18.0.53 Update #2

My domain has a valid SSL certificate from Let's Encrypt. I have used the wildcard specification to generate a certificate. However no matter what I try I the webmail does show as protected in Plesk, but the server is not providing the certificate when I access webmail.domain.com

• Issued wildcard certificate through Let's Encrypt
• Website is using newly issued certificate
• Manually restarted (through GUI) Dovecot, Postfix, Apache
• Executed through SSH:
  • plesk sbin httpdmng
  • plesk sbin websrvmng --restart
  • plesk sbin nginx_control --restart
  • plesk repair web for domain
    • Error messages: 0; Warnings: 0; Errors resolved: 0
  • systemctl restart sw-cp-server.service
  • echo 'Q' | openssl s_client -connect localhost:465 -servername example.com -showcerts 2>&1 | grep -Eo 'CN=[^/]+' | uniq
    • Displays the correct certificate
• PSA database shows single certificate for the domain
• Webmail settings points to the correct certificate

So far I have not been able to have the webmail serve the correct certificate.

 

[Peter Debik]

Is the correct SSL certificate selected from the "SSL/TLS certificate for webmail" drop down on the "Mail Settings" tab of the domain?

 

[m20230711]

Yes. There is only a single certificate available for the domain.

 

[Peter Debik]

Is the webmail subdomain addressing the right server or is it maybe routed to another server?

 

[m20230711]

Webmail resolves to a different IP than where Plesk manages the site. Though that did not prefent Plesk from configuring the webmail previously.

 

[Peter Debik]

A domain validated SSL certificate must be issued on the server where the domain is operated.

https://support.plesk.com/hc/en-us/articles/12377086594583-Is-it-possible-to-issue-a-Let-s-Encrypt-Wildcard-certificate-without-the-main-domain-in-SAN-

Maybe previously you had added the certificate manually to the other server or you confirmed a security exeception rule in your browser. It is not possible that it worked there automatically.

I'll mark this thread as solved, because it is clear that the issue is caused by a missing certificate on the target server.