Forwarded to devs Mail certificate is no longer assigned after it gets renewed by Let's Encrypt

[Maarten]

Username:

TITLE

Mail certificate is no longer assigned after it gets renewed by Let's Encrypt

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

CentOS Linux 7.9.2009
Plesk Obsidian Version 18.0.45 Update #2
SSL It! Version 1.11.0-1509

PROBLEM DESCRIPTION

Currently, Let's Encrypt is unable to secure the mail when the A record for a domain is pointed to another server.

I've implemented this workaround:



1. Go to Domains > domain.com > SSL/TLS Certificates
2. Unassign the current certificate ad reissue a new certificate for the webmail only
3. Create a web hosting enabled subdomain mail.domain.com
4. Go to Domains > mail.domain.com > SSL/TLS Certificates
5. Issue a new certificate
6. Go to Domains > domain.com > Mail Settings
7. Assign the certificate for mail.domain.com

This works fine until the certificate gets renewed. The mail certificate on domain.com is no longer assigned to mail.domain.com. It's empty.

As a workaround for this issue, I've added a cronjob:



/sbin/plesk bin subscription_settings -u domain.com -mail_certificate "Lets Encrypt mail.domain.com"

STEPS TO REPRODUCE

1. Go to Domains > domain.com > SSL/TLS Certificates
2. Unassign the current certificate ad reissue a new certificate for the webmail only
3. Go to Domains > mail.domain.com > SSL/TLS Certificates
4. Issue a new certificate
5. Go to Domains > domain.com > Mail Settings
6. Assign the certificate for mail.domain.com

Wait until the certificate gets renewed. The mail certificate on domain.com is no longer assigned to mail.domain.com. It's empty.

ACTUAL RESULT

The mail certificate on domain.com is no longer assigned to mail.domain.com. It's empty.

EXPECTED RESULT

The mail certificate on domain.com is still assigned to mail.domain.com.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[IgorG]

@maartenv it is known bug EXTSSLIT-1870

 

[bmbuero]

I have a similar problem. I cant use webmail because there is no certificate assigned. When I issue a new certificate and assign ist to webmail it works for a couple of minutes but then it disappears. In plesk it says that the issue will be fixed automatically...
How to fix this?

 

[zubasoft]

I also have a similar problem. A-Record points to another server. I'm trying to issue a brand new Let's encrypt certificate for webmail.domain.com but I only get the error "No domains have passed validation". Hosting is deactivated on this mail only server (as described in this article: https://support.plesk.com/hc/en-us/...s+encrypt+-+no+domains+have+passed+validation). The strange thing is, that the response tries to issue the certificate for the main domain name and not only for the webmail subdomain. Of course for the main domain this request will fail, because the A-Record points to another server.

I have also tried to use the CLI tool to issue the certificate only for the webmail-Subdomain:
plesk bin extension --exec letsencrypt cli.php -d webmail.c-studio.com -m [email protected]

But I only get the following error message:
ERR [extension/letsencrypt] The execution of cli.php has failed with the following message:
Could not find any domain to install.

 

[Ahmed]

Also affected by this issue.

Please fix it. It's extremely annoying.

 

[Peter Debik]

While this has been previously submitted as a product issue, it is actually a feature request. Please vote for it here: Add possibility issue Let's Encrypt SSL certificate for mail server when the "A" DNS record for domain is pointing to another server

 

[Ahmed]

While this has been previously submitted as a product issue, it is actually a feature request. Please vote for it here: Add possibility issue Let's Encrypt SSL certificate for mail server when the "A" DNS record for domain is pointing to another server

I disagree. That's a related but different issue, which would indeed also be nice to have.

The reported issue here is when you actually create a subdomain (mail.example.com), issue a Let's Encrypt certificate for it, and then on the main domain's (example.com) "Mail Settings" screen you select that subdomain's certificate to secure the mail server (SSL/TLS certificate for mail). This actually works, but when the certificate for the subdomain is automatically renewed, it isn't "picked up" by the main domain until you go to the "Mail Settings" form again and submit it, without modifying anything.

The result is that when the old certificate expires, mail clients configured to use SSL stop working until you resubmit that form.

 

[peterbrejassou]

Hello, does anyone have any news about this bug ? Thanks !

 

[haax]

While this has been previously submitted as a product issue, it is actually a feature request. Please vote for it here: Add possibility issue Let's Encrypt SSL certificate for mail server when the "A" DNS record for domain is pointing to another server

Peter, do you have any update on this issue? By this issue I mean the original post from @maartenv and my own post:

Question - Obsidian 18.0.52 wrong certificates selected after renew

Hi all, I have an issue with a (hosted) Plesk setup. There are a couple of sites configured, including letsencrypt certificates. For a specific site I am using an alternative certificate for the mail server (SMTP/IMAP). By default it uses the "domain.com" cert, but I use "mail.domain.com"...

talk.plesk.com

Martin

 

[Peter Debik]

I do not have any updates.

 

[futureweb]

@Peter Debik - I find it quite astonishing that this feature has not yet been incorporated into Plesk. Our support team is currently managing an extensive Excel list containing hundreds of domains, they have to manually renew every three months. This process consumes a significant amount of time each month.

Could someone please help escalate this matter to the Product Management team? It's imperative that they recognize the importance of addressing this issue.

Your assistance would be greatly appreciated. Thank you.
Andreas

 

[Peter Debik]

Could you please open a support ticket on the case, referring to EXTSSLIT-1870? It's the best way to raise more attention.

 

[Reinier Post]

This message is also issued when the hosting type for the domain is set to No web hosting. Set it to Website to allow validation to pass.

 

[Ahmed]

Crazy that this has been "Forwarded to devs" and still not fixed. More than 2 years since it was reported.

 

[Sebahat.hadzhi]

Hello, everyone. We understand that you might've expected the resolution to occur earlier. However, this case hasn't been classified as critical and it is more of a feature request rather than a bug. Additionally, the complexity involved in the implementation has also significant impact on our decision to delay the release and prioritize other more pressing issues. I would like to apologize to everyone affected by the issue and thank you all for your patience.

 

[Maarten]

Thank you for your response regarding the Let's Encrypt mail certificate renewal issue. I'd like to propose a straightforward solution that has proven effective in the industry.

Suggested Solution:

Introduce a global setting in Plesk:

[ ] Use mail.domain.tld subdomains for all mail certificates
    ⓘ This setting will automatically assign mail certificates
    through mail.domain.tld subdomains for all subscriptions.

Benefits of this approach:

• Provides a consistent, automated way to handle mail certificates.
• Solves the automatic renewal issue without requiring manual intervention.
• Simplifies subscription migration between Plesk servers. Customers won't need to adjust settings, reducing frustration for both clients and administrators.
• Adapts to current market trends, where clients often host their websites externally (e.g., on Wix) while keeping their email on the Plesk server. This setup is increasingly common, and mail.domain.tld addresses this by providing a stable, predictable mail server name for clients.

This approach has been successfully adopted by cPanel, which creates mail.domain.tld subdomains for all subscriptions by default. Their implementation has been reliable, scalable, and widely accepted by users.

Additional Advantages:

• Optional global setting provides flexibility.
• Allows administrators to choose the new approach or retain the current behavior.
• Minimizes changes to existing infrastructure, which could simplify implementation.

Given its proven success in production environments, I believe the complexity of this solution may be significantly lower than initially estimated.