Issue When Mail Domain SSL Renews The Cert Reverts To domain.tld

[Ladylinux]

Server operating system version

Debian 11

Plesk version and microupdate number

18.0.65

Hello,

So this is a reoccurring annoyance. I have some accounts that I migrated off Cpanel and Hsphere that customers use mail.domain.tld for incoming and outgoing mail server.

I had to manually create a mail.domain.tld sub domain and then bind its cert to its mail settings.

When the domain mail.domain.tld renews for whatever reason the cert for mail.domain.tld reverts to just domain.tld

This is repeatable and results in a lot of customers complaining about cert issues

I have to go into the panel and manually apply mail settings to get the renewed SSL to bind properly to the mail.domain.tld

Mind you the panel shows the binding correctly to mail.domain.tld SSL

This obvious Kludge only exists because Plesk refuses despite many many requests to natively support mail.domain.tld SSL

Feature Suggestions – Your Ideas for Plesk

So any work around to keep these mail.domain.tld ssl bound properly ?

Thanks!!

Ladylinux

 

[Ladylinux]

OK,

Guess voting is a waste of time here.

Add possibility issue Let's Encrypt SSL certificate for mail server when the "A" DNS record for domain is pointing to another server

This feature is required for users with the configuration when on the Plesk only mail server for domain is used. "A" DNS record for mail.example.com is pointing to Plesk server, when when "A" record for example.com is pointing to another server.

plesk.uservoice.com

https://support.plesk.com/hc/en-us/articles/12377057738135-Is-it-possible-to-secure-the-mail-server-mail-example-com-with-Let-s-Encrypt-SSL-certificate-when-the-A-record-for-example-com-is-pointing-to-another-server

Sigh,

LadyLinux

 

[Maarten]

This is a well-known issue that has been discussed frequently on the forum. Unfortunately, it doesn't seem like a solution will be available in the near future. Hopefully, Plesk will consider addressing this at some point, as it's been a recurring request for quite some time.

 

[Sebahat.hadzhi]

@Ladylinux, @Maarten, thank you for bringing that up. Our team is currently working on introducing the ability to secure email-only hosting with Let’s Encrypt certificates. I do not want to provide any ETA at the moment in case something goes wrong and they need to postpone it, but it is planned for the release of the next SSL It! (+ Let’s Encrypt) version.

 

[Ladylinux]

@Ladylinux, @Maarten, thank you for bringing that up. Our team is currently working on introducing the ability to secure email-only hosting with Let’s Encrypt certificates. I do not want to provide any ETA at the moment in case something goes wrong and they need to postpone it, but it is planned for the release of the next SSL It! (+ Let’s Encrypt) version.

Thank You!!

LadyLinux

 

[Ladylinux]

Hi,

This is still wacked

With a "New" mail only domain and the latest SSL It! (Version 1.16.0-4789) Lets Encrypt (3.2.9 (14 January 2025)) extensions one can not secure properly a clients mail server.

SSL binds webmail.customerdomain.tld to mail.customerdomain.tld unless you deselect "secure webmail" when issuing a ssl certificate

If you do this deselect webmail is no longer ssl protected

This is not what should happen

Sigh,

LadyLinux

 

[trialotto]

@Ladylinux , @Maarten, @Sebahat.hadzhi

Situation has been changed, slightly for the better, but certainly not for the best.

In general, it is not recommend (and not good practice) to create a (separate) mail.domain.tld - keep that subdomain for the mail server, not for domain hosting!

In essence, the LE certificate for domain.tld is and can be equivalently valid for the mail.domain.tld.

The problem nowadays seems to be that the SslIt! extension (that includes Let's Encrypt) has some (major and minor) issues.

This issue - assigning a certificate to mail.domain.tld properly - is one of them.

Duly noted, it will be added to a list of "requested changes" that will be submitted in the form of a bug report.

In summary, @Ladylinux, if you have encountered some bugs in SslIt! extension, please elaborate!

Kind regards.....

 

[Ladylinux]

This issue - assigning a certificate to mail.domain.tld properly - is one of them.

Duly noted, it will be added to a list of "requested changes" that will be submitted in the form of a bug report.

Yes this is maddening. I have existing clients who are thousands of miles away from me who barely can change a password much less change mail server incoming and outgoing. These clients were migrated from Cpanel where mail.domain.tld is standard. The deselecting of mail.domain.tld when renewing is a massive annoyance and should have been resolved long ago.

My Debian 11 server with Plesk 18.0.70 and latest extensions still has the issue.

Lady Linux

 

[Kaspar]

Yes this is maddening. I have existing clients who are thousands of miles away from me who barely can change a password much less change mail server incoming and outgoing. These clients were migrated from Cpanel where mail.domain.tld is standard. The deselecting of mail.domain.tld when renewing is a massive annoyance and should have been resolved long ago.

My Debian 11 server with Plesk 18.0.70 and latest extensions still has the issue.

Lady Linux

The recently update of the SSL It! extension introduced native support to include the mail. subdomain into the domain certificate. There should be no need anymore to separately create subdomains and set/configure different certificates for the mail service on a domain.

 

[Ladylinux]

The recently update of the SSL It! extension introduced native support to include the mail. subdomain into the domain certificate. There should be no need anymore to separately create subdomains and set/configure different certificates for the mail service on a domain.

Oh very nice I will give this a try

Fran

 

[trialotto]

The recently update of the SSL It! extension introduced native support to include the mail. subdomain into the domain certificate. There should be no need anymore to separately create subdomains and set/configure different certificates for the mail service on a domain.

@Kaspar,

There has not been a necessity for ages to create separate (mail) subdomains and/or certificates.

Nevertheless, SslIt! is still a bit buggy, in the sense that (a) the most recent updates of the extension are bug fixes to a high degree (read: previous bugs were not fixed properly) and (b) the extension itself does not always function properly (read: some minor bugs still exist, which minor bugs are annoying though).

However, "no necessity" is not equivalent to "not desirable".

In some cases, it might even be desirable or more secure to use a separate certificate for the mail server (via a mail subdomain or via better methods) and another certificate for the main domain (and its subdomains).

In terms of security, it is often recommendable to "separate certificates" if applications run on the main domain (or subdomains) require more security OR if the mail server is a high volume mail server prone to spam (or attacks - in the case of attack vulnerability, one is best off by using a dedicated server for mail).

Kind regards....

 

[NatuurlijkHosting]

Although I read that the issue with the mail. subdomain not being included in the SAN certificate should be fixed in the latest SSL It! version, we are still having problems with this. On several Plesk servers we by default provision all ‘mail.’ subdomains of our clients websites with a Let's Encrypt certificate, yet, when we perform ssl-checks on those ‘mail.’ subdomains we see the server responding with it's hostname's wildcard certificate instead of the Let's Encrypt we expect to see. This causes an SNI mismatch.I've checked the SSL! it version and it appears to be up to date: Version
1.18.4-3731
Am I wrong in interpretating the statement in "plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/41337271-add-mail-example-com-mail-subdomain-in-subject" as "this shouldn't be an issue anymore, we fixed it."....?

 

[Kaspar]

@NatuurlijkHosting, if the following conditions are met, it should be possible to secure the .mail sub domain for mail usage.

• A DNS record for the mail host exists on the domain's DNS zone.
• There is no sub domain named mail for the domain present in Plesk.
• The mail service is enabled for the domain.

If those conditions are met, you should have the option the secure the mail service on the .mail sub domain like in the screenshot below.

 

[NatuurlijkHosting]

Ah Kaspar, thank you for your reply!
Yes, we do see that option, and after checking the boxes for the 'mail.' subdomain and clicking on "get it free" the domain level interface states that it is secured, however when we perform openssl / online checks on the 'mail.' subdomains they always return the servers hostname's certificate instead of the Let's Encrypt certificate, causing the SNI mismatch.
To me this sounds exactly like the inconsistent behaviour that ought to be fixed by the latest update - however it does not seem to be fixed on our servers.
(Mind you: I know we can circumvent it by adding the 'mail.' subdomain as a subdomain in plesk, or by using a subdomain of our servers hostname as the actual MX record and removing the DNS records for "mail.", but it's just not very convenient )

 

[Kaspar]

The mail certificate only secures mail services (POP, IMAP and SMTP). When checking for the certificate, did you test/connect to the relevant ports of any these mail services? Or just to the default 443 port for http? The later will always serve the hostname's certificate. While if you connect on a mail port, the domains the certificate will be used (or at least it should).

 

[trialotto]

@NatuurlijkHosting, if the following conditions are met, it should be possible to secure the .mail sub domain for mail usage.

• A DNS record for the mail host exists on the domain's DNS zone.
• There is no sub domain named mail for the domain present in Plesk.
• The mail service is enabled for the domain.

If those conditions are met, you should have the option the secure the mail service on the .mail sub domain like in the screenshot below.

View attachment 28855

@Kaspar,

This "mail.domain.tld" setting does not work properly.

There - essentially - is a serious bug, related to "lack of development logic".

With the current "development logic", the setting works as intended, but not as expected.

Stated differently, the current "development logic" causes inconsistent and illogical behavior that causes mismatches with LE certificate assignments.

The behavior is so erratic that it is even to find unique STR (steps-to-reproduce).


Plesk Team should simply be aware of the facts that

1 - it is not a good idea to allow for the creation of the subdomain "mail.domain.tld"

2 - the "mail.domain.tld" should be reserved for the mail server

3 - it is an odd concept that one can choose to assign certificates to a mail server

4 - assignment of certificates to a dedicated (sub-)domain of a mail server should be obligatory and automatic

and these facts imply that

a) there are "conditions", as described in point 2 and point 4 above,

b) there is no value in the "secure mail on this domain" option, taking into account the facts described in point 1 and point 3.


It should be clear by now that the "development logic" applied when introducing the "secure mail on this domain" option was a bit far-fetched.


At this moment, this "development logic" (or lack thereof) creates dangerous situations with mail servers not being assigned a certificate.

In combination with some other (still present) bugs and caveats (not being bugs) in SslIt! extension, there is a serious and potential THREAT.


In summary, I really wish that Plesk returns to the basics of

- dedicated subdomain for the mail server
- AUTOMATIC assignment of certificates to the mail server, with assignment of default certificate if LE certification renewal fails
- NO option to "secure mail on this domain", since that "asking the wrong question for the wrong reasons"

At this moment, we are supposed to have steel doors, bullet-proof glass and state-of-the-art alarm systems to safeguard our possessions .....

..... but Plesk asks us : do you want to keep your door open and unlocked?

In my humble opinion, that is totally wrong and a complete lack and failure of "development logic".


Kind regards.....

 

[Kaspar]

This "mail.domain.tld" setting does not work properly.

Haven't had any issues with it so far and I am actually quite happy with the way it's been implemented. It does fulfill my needs and I think it does too for a lot other user (Plesk) users.

 

[trialotto]

@Kaspar,

That is - probably - because you factually have a mail.domain.tld subdomain.

Otherwise, LE would give an error.

 

[Kaspar]

That is - probably - because you factually have a mail.domain.tld subdomain.

Otherwise, LE would give an error.

A dedicated mail subdomain (one I manually add in Plesk) you mean? I don't. That would be way to much hassle for my taste.

 

[trialotto]

A dedicated mail subdomain (one I manually add in Plesk) you mean? I don't. That would be way to much hassle for my taste.

It is a hassle, but some people do it : they create a separate subdomain mail.domain.tld via Plesk GUI.

But if you do not have such a subdomain, which setup do you use? Plesk DNS? TLSA? etc etc.

In addition, do you have issues with webmail certs not renewing / not being assigned (when other parts are renewed properly)?

In addition, is your checkbox (secure mail) also not active when first selecting "assign cert to the mail domain"?

I am looking for the differences ;-)

These differences can - probably - tell us more.

Kind regards....