Issue 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?