Resolved Bug in Plesk (new) feature mail.domain.tld

[Gjimi]

Server operating system version

Debian 11

Plesk version and microupdate number

18.0.71 Update 2

Plesk has added a new option for creating Let's Encrypt certificates for mail.domain.tld.
If you select this option (all customers do) you always get an error message stating that it is not possible to create a certificate for mail.domain.tld.

Reason:
Plesk does not create an alias (in Apache) for mail.domain.tld
(if one does not already exist).

So the link doesn't work:

http://mail.domain.tld/.well-known/acme......

Affected:
All (current) Plesk versions since the mail.domain.tld option was added to the SSL certificate.

 

[trialotto]

@Gjimi

I am not sure what you intend to report as a bug.

In essence, there is no relation between mail.domain.tld and Apache (and there should not be a relation).

The mail.domain.tld is used for other purposes than purposes related to the web server (Apache).

The "inclusion" of mail.domain.tld in a SSL certificate is "expected behavior" for the sole purpose of assigning a certificate to the mail server.

It seems to be the case that you are not reporting a bug, but something that is essentially "expected behavior".


HOWEVER!

There is an issue with the SslIt! extension, closely related (but not identical) to what you reported.

For instance, the following occurs :

1 - BUG : when selecting "wildcard" option in SslIt!, the checkbox for mail.domain.tld is NOT automatically selected (and this is not expected behavior)

2 - WORKAROUND : first select the mail.domain.tld checkbox and afterwards select the "wildcard" option


In short, there - certainly - is something wrong with the SslIt! extension, since it does not exhibit the behavior that should be expected.

Nevertheless, I am still trying to grasp the essence of your alleged bug.

Could you elaborate and provide images?


Kind regards.....

 

[trialotto]

@Sebahat.hadzhi

Could you be so kind as to participate in this topic thread, so we can summarize the issues with the SslIt! extension and file a bug report?

Thanks in advance!

 

[Gjimi]

Wildcard is not used here because we have external DNS. It's already disabled by "allow-wildcard-certificates = false," but it has nothing to do with the problem here.

Related to Apache, as explained above, Let's Encrypt cannot verify via http, which is why an error message appears.

Conclusion: If the mail.domain.tld checkbox is selected, it's not possible to create a certificate.

See screenshot in the attachment.

 

[trialotto]

Wildcard is not used here because we have external DNS. It's already disabled by "allow-wildcard-certificates = false," but it has nothing to do with the problem here.

Related to Apache, as explained above, Let's Encrypt cannot verify via http, which is why an error message appears.

Conclusion: If the mail.domain.tld checkbox is selected, it's not possible to create a certificate.

See screenshot in the attachment.

@Gjimi

It is an incorrect conclusion.

I have tested your alleged "bug" and your error notification cannot be reproduced.

This is expected, since the LE certificate created will be assigned to / used for the mail.domain.tld too.

The error notification that you receive is related to a - totally - different issue.

In your case, the cause of the problem seems to be some incorrect configuration with respect to IPv6 settings and/or DNS settings.


In fact, first check whether IPv6 is allowed and working properly on the server side.


Could you be so kind as to simply remove the AAAA record (if possible) or to replace it with a A record?

After that step, please retry certificate renewal.

If you still have some issues, please report them.


It is not necessarily related to DNS alone, it can also be related to IPv4/IPv6 config issues on the server.

If the replacement / removal of the AAAA record works, could you be so kind as to (only) allow IPv4 on the server, with afterwards certificate renewal?

If that works, could you also be so kind as to reinstate the IPv6 properly and try to renew the certificate (with IPv4 only settings).

If the latter also works, then please try to reinstate the AAAA record and ...... surprise, surprise ...... try to renew the certificate afterwards.


If the final step does not succeed, then is very likely - but not 100% certain - that you can report a bug concerning the SslIt! extension.


As a final remark, there are some other remarkable issues with SslIt!, so please do some careful testing in order to make sure that the potential bugs and solutions can be identified.

Kind regards....

 

[Gjimi]

Maybe your system settings are different, but there's no comparison.
For example, we only have external DNS and no nginx.

Check DNS? Yes, I'll wait for you to tell me I'm not a beginner!

Everything's OK with DNS and Plesk, but selecting the new mail.dmain.tld function gives an error message.
PS: I've already studied this, so I'll offer the solution straight away. Again:
Let's Encrypt wants or does check both URLs

http://domaind.tld (OK)
and

http://mail.domain.tld/.well-known/acme......

The second check isn't possible, of course, because this subdomain doesn't exist in Plesk. Therefore, a good solution (if the subdomain doesn't exist) would be to use an alias for the main domain in Apache, which would allow the Let's Encrypt check.

 

[Gjimi]

example Domain: sytest.de
You can see that all DNS are OK.

Even *.sytest.de points to IPv4 and v6.
Additionally, mail.sytest.de is also in DNS and points to IPv4 and v6.

Both IP's are enabled in Plesk and otherwise work normally.

But it's not a mail.sytest.de subdomain, so it doesn't have to be normal...

 

[Gjimi]

PS: If I create a subdomain mai.domain.tld in Plesk, it works, but it's not too complicated for customers.

 

[Kaspar]

@Gjimi, just to be sure; is ngnix disabled on your server?

 

[AYamshanov]

Hi @Gjimi,

As I understand, this behaviour only occurs in some cases. To create a bug report, I need to provide clearer steps for developers to reproduce the issue on our servers. It helps to find the root cause; if the bug is confirmed, it also helps to test the fix to be sure it really works.

Could you please open a support ticket in Plesk support so that we can get more details about the environment in which you are experiencing the issue and find steps to reproduce (STR) the bug?

 

[trialotto]

Hi @Gjimi,

As I understand, this behaviour only occurs in some cases. To create a bug report, I need to provide clearer steps for developers to reproduce the issue on our servers. It helps to find the root cause; if the bug is confirmed, it also helps to test the fix to be sure it really works.

Could you please open a support ticket in Plesk support so that we can get more details about the environment in which you are experiencing the issue and find steps to reproduce (STR) the bug?

@AYamshanov

It is very likely that no STR will exist for the - alleged - issue reported by @Gjimi.

The feedback / posts from @Gjimi give an indication that there is no relation with an issue or bug in SslIt! extension (or on the LE side).

I have tried to find STR and was not able to reproduce those errors, even though similar (but not identical) issues can be recreated when fiddling with IPv6 settings (on the server side) and/or when simply adding AAAA records (pointing to a server only configured for IPv4).


Nevertheless, there are some other minor and major issues (or bugs) that can be mentioned with respect to the SslIt! extension.

Somehow, the TLSA records are of the format 3 0 1 .....

......... and this is not recommend at all : see Lets Encrypt documentation / forums.

@AYamshanov, can you be so kind as to code the default of 3 1 1 format for the TLSA records?

I need to do some additional testing, but that is one thing that can be improved and that should be improved.


Kind regards.....

 

[Gjimi]

So much chatter and fantasies here, it's unbearable.

It has nothing to do with AAAA or BBBB, it has nothing to do with DNS, it's simply a false message from Plesk.

I also explained why it can't work.

And yes, ALL servers, ALL domains are affected. To reproduce it, it's very simple: add a new domain (without subdomains, without wildcard SSL).

Let's Encrypt, issue certificate - Check the boxes for:
- domain.tld
- www.domain.tld
- mail.domain.tld
- IMAP, POP, SMTP for domain.tld

And there you have the message.

PS: no report is saved, it's just a notice from Let's Encrypt.

 

[trialotto]

@Gjimi

If and when you have a problem, then it is not automatically safe to assume that your problem is caused by Plesk or one of its components.


The alleged issue cannot be reproduced in a "normal environment" - with or without external DNS.

In most cases, the alleged issue is then not an issue related to SslIt! or Letsencrypt, but often a symptom of some other issue.

Network configuration, firewall settings, Apache config errors, Nginx config errors, DNS config mistakes and even erroneous configuration of nameservers by the nameserver provider - they all can be the root cause of the problem that results in symptoms that you noticed and identify as SslIt! or Letsencrypt related.


Your statement

And yes, ALL servers, ALL domains are affected.

simply indicates (a) that you have a network related issue (since all issues are allegedly identical across servers) OR (b) that you have used identical config on all servers affected (with that config not being correct) OR (c) that you have used a DNS template that is configured incorrectly.


As stated by the letsencrypt notification, being that

"the systest.de DNS zone contains an AAAA record, but the domain is not assigned an IPv6 address in Plesk. To resolve the issue, either assign an IPv6 address to systest.de or remove the AAAA record from the systest.de DNS zone"

the alleged issue with SslIt! or Letsencrypt extension is a SYMPTOM of either network related config or DNS related issues.


Letsencrypt simply provides a nice hint to a solution of your issue : test removal of the AAAA records first and, if that did not work, assign an IPv6 address.

If changing DNS records and IPv6 settings does not work, then you have another issue that is - very likely - related to network config or nameserver config.


If your statement

So much chatter and fantasies here, it's unbearable.

would be read as it is, then you apparently find it unbearable that you yourself are not satisfied with the answers that people can provide out of their own free will on a forum that you yourself posted on.

I have the choice to not post any response in order to prevent that you "find it unbearable".

I also have the choice to ignore the statement.

I have chosen to keep it polite and, as always, find some spare time to respond.

I hope that you can do the same and provide all necessary information that is actually required to help you out.


Kind regards...

 

[Gjimi]

change virtual host
from:

<VirtualHost 138.xx.xx.xx:443 >
ServerName "sytest.de"
ServerAlias "www.sytest.de"
...

to:

<VirtualHost 138.xx.xx.xx:443 >
ServerName "sytest.de"
ServerAlias "www.sytest.de"
ServerAlias "mail.sytest.de"
...

then it works immediately.

Let's Encrypt can then also verify URLs.
http://mail.domain.tld/.well-known/acme......

So the solution is actually simple: Plesk needs to create an alias, but only if NO subdomain mail.domain.tld exists.

Unfortunately I have no way to report this to Plesk.

 

[trialotto]

change virtual host
from:

......

<VirtualHost 138.xx.xx.xx:443 >
ServerName "sytest.de"
ServerAlias "www.sytest.de"
ServerAlias "mail.sytest.de"
...

then it works immediately.

Let's Encrypt can then also verify URLs.

@Gjimi,

In short, not a SslIt! or Letsencrypt related issue.

However, you have created a workaround with respect to certificates .......... and that workaround will create additional issues.


In a normal scenario, the following applies :

1 - the mail server is assigned the mail.domain.tld subdomain by default

2 - the mail server is accessible from the internet by means of a - properly configured DNS record (A or AAAA record)

3 - the mail server is accessible via a number of ports

4 - the mail server (and mail traffic) can be secured by adding a letsencrypt certificate - this works (almost) without error!


In your case, the following applies :

1 - you have a subdomain that - on purpose - has the name mail.domain.tld and that can be used for hosting and mail purposes,

2 - the subdomain is accessible from the internet by means of a - properly configured DNS record (A or AAAA record)

3 - the subdomain is accessible via port 443 (given the config that you posted)

4 - the subdomain can be secured by adding a letsencrypt certificate - only traffic via port 443 will be secured!

5 - the subdomain is working over Apache - the mail traffic will not!

Stated differently, the subdomain with the name mail.domain.tld will be associated with a mail server, but not necessarily associated with a certificate that can be used to secure the mail server.


In short, if you configure the domain.tld as the domain for the mail server, then the mail.domain.tld will be automatically added and that mail.domain.tld can be secured with letsencrypt certificates.

Otherwise, when configuring a mail.domain.tld subdomain, this is a valid workaround, but also a workaround that makes things unnecessarily complicated.

In general, adding a letsencrypt certificate to the mail.domain.tld subdomain is adding a certificate to the hosting function of that subdomain - most people do not realize that and often leave the mail server exposed in some way or another.


All of the above is in very very very rough outlines.

The quintessence of the whole story is : make life easy and use the default setup (and not the mail.domain.tld subdomain approach).


Kind regards.....

 

[Gjimi]

Certificate for mail.domain.tld is not created, otherwise I wouldn't be writing here.

 

[Gjimi]

Mail Server Certificate for mail.domain.tld is not created, otherwise I wouldn't be writing here.

 

[trialotto]

Mail Server Certificate for mail.domain.tld is not created, otherwise I wouldn't be writing here.

@Gjimi,

That is no surprise.

The creation of the LE certificate for the mail server will cause issues due to the existence of the mail.domain.tld subdomain on your server.

The creation of the LE certificate for the mail.domain.tld subdomain can and often will cause issues for the creation of the LE certificate for the mail server and, as a result, often leave the mail server associated with the mail.domain.tld subdomain exposed (read: it is not associated with a LE certificate).

At this moment, you have a LE certificate for the hosting part of the mail.domain.tld subdomain.

In addition, you can expect issues to arise from the fact that you created an Apache alias (on port 443) for the mail.domain.tld subdomain.

You expect that the Apache alias will be sufficient to assign LE certificates to a mail server, but it is not - it is only an Apache alias for a (hosting) subdomain that has a name exactly identical to the name mail.domain.tld that is reserved by default for the mail server.

Stated differently, the Apache alias will sooner or later interfere with the proper functioning of and certification of the mail server.


In short, if you simply revert to domain.tld (as opposed to the currently used mail.domain.tld), then you would not have to write here.

The domain.tld approach would simply create LE certificates for the domain that can also be used for the associated mail server.

Stated differently, if you would not have deviated from default setup, you would not have written here with this particular set of questions.


I can only recommend to do a test with a testdomain.tld - create a domain in Plesk, assign a LE certificate to the domain and the mail server.

If that works, then it is obviously clear that your current setup is flawed.


I can highly recommend to not apply workarounds, since workarounds are not solutions.

Workarounds are merely combatting symptoms of issues that can and should be resolved.


As a final remark, it is normally the case that thread starters are providing all information required to do a proper analysis.

In your case, there is much more to be provided, such as logs and - more importantly - the actual DNS settings.

Not only the original LE error notification indicates a minor issue with DNS, but also the Apache alias workaround indicates minor DNS issues.

In essence, using LE with external DNS providers simply requires that you should have

1 - a DNS A (or AAAA) record for domain.tld
2 - a DNS A (or AAAA) record for *.domain.tld - otherwise, the Apache alias would not work
3 - a DNS A (or AAAA) record for mail.domain.tld - explicit DNS that can be replaced with the record from point 2
4 - a MX record with the value mail.domain.tld
5 - a TXT record for the subdomain _acme-challenge.domain.tld with the value (key) provided by LE during certificate setup

and if you

a) do not have the _acme-challenge.domain.tld TXT record,

and/or

b) a setup in Plesk that "hints" or "instructs" to have a look at another than the aforementioned TXT record,

then LE certification processes will fail miserably.

Please note that it does not make a difference whether or not you are using external DNS or Plesk based DNS - the concept is the same.


Stated differently, by creating the Apache alias and corresponding DNS settings, you are "instructing" LE to have a look at domain.tld (not mail.domain.tld) and certify domain.tld (not mail.domain.tld).

As a workaround, this will work, since the certificate for domain.tld will be assigned to the mail.domain.tld subdomain and can be assigned to a mail server associated on the domain.tld domain.

The reason why this workaround will work is the simple fact that the mail.domain.tld subdomain has the exact identical name that would otherwise be used by default for the mail server, being the name mail.domain.tld.

Nevertheless, even when the mail.domain.tld subdomain is absent, Plesk can and will assign the LE certificate for domain.tld to the mail server of domain.tld that has the name mail.domain.tld.

In essence, the Apache alias is an "instruction" to overrule another instruction that makes LE fail.

Stated differently, before the Apache alias, the Plesk setup and/or the DNS setup was not proper.

It can be that DNS is not setup properly.

It can also be the case that you have setup mail.domain.tld as a subdomain - one should use a domain setup with the name mail.domain.tld.


As a final remark, I use / have used / test / have tested the setup with both domain.tld and mail.domain.tld for many years now.

I can safely conclude that everything will work like a charm, unless your Plesk or DNS setup was not proper, before applying the Apache alias workaround.

As a result, I would not recommend your workaround at all .......... due to the simple fact that the root cause of the problem is not solved.


Kind regards.....

 

[Gjimi]

@trialotto
Thanks for senseless useless texts
you really littered my post
and please don't write anything else here!!

 

[trialotto]

@Gjimi,

Again, keep it polite.

You have an issue that you cannot resolve and, as a result, you are starting a thread that nobody else will post on.

It certainly will not help if you become impolite.

You do not have to do anything with my posts.

A small tip : your Apache alias workaround will not work anymore or is not very likely to work, if and whenever

- a plesk repair cli command is run in such a way that Apache config will be adjusted, and/or
- the Webserver Configuration Troubleshooter is being used from Plesk GUI, and/or
- Plesk Panel is updated in such a way that Apache config is updated, and/or
- Apache config is adjusted in any other way,

since the Apache config regenerated from the default templates are not containing the Apache alias that you manually added as a workaround.

I suppose that this detail is also useless text.


As a final remark, I am not posting for you alone.

Whatever you might want to do with my posts, that is up to you.

It is simply a forum where all people can share questions and answers.

I suppose that your problem is solved, given your "workaround" and the fact that you have the opinion that everything else is "nonsense".


It is not about you and your opinions, this thread is equivalently valid and relevant for other people that might encounter similar issues.

Nevertheless, since your issue seems to be solved (at least in your opinion), this topic thread can be closed.


Kind regards.....