Resolved SSL It! Let's Encrypt Not Issuing Certificate on MX-only Domain

[G J Piper]

Server operating system version

AlmaLinux 8.10

Plesk version and microupdate number

Plesk Obsidian 18.0.68 Update 1

I have one domain that is hosting email (on an alias mail.domain.com) and webmail.domain.com but is set to "no web hosting" since the main domain's DNS is pointed to another remote server.
Let's Encrypt has been working well on it ever since they allowed mail and webmail domains to be issued even without the main root domain being hosted, until today.
Not sure when it changed, because it is only every couple months the domains get SSL reissued, but SSL It! and Let's Encrypt extensions have been updated since last time this domain was issued, and now it doesn't work. It failed and can't even manually be reissued since the "Get it Free" button is greyed out in the GUI.

Anyone else having this or is it just me because I have an alias running as MX server?

 

[G J Piper]

 

[G J Piper]

Update:
I was able to trick the GUI into allowing it to issue a new Let's Encrypt certificate for the mail domain services, webmail.domain.com and mail.domain.com alias that is the mail server domain. To do this, I had to enable forwarding in the hosting settings for the main domain, then reissue the certificate and allow it to fail on the forwarded root domain and "www" alias. Even though it failed to save the certificate with those, it still created a valid certificate for the mail server and webmail domain. Then, I turned hosting forwarding back off and all is set.

I strongly suspect that if this doesn't get fixed, however, I will have to do this again in June. I'm glad I don't have a hundred of these mail-only hosting scenarios to deal with!

Let me know if anyone needs me to test anything regarding this.

 

[Sebahat.hadzhi]

Hello, @G J Piper . I am not entirely sure I was able to fully understand the exact configuration you are having troubles with. Would you mind confirming how exactly is the domain name in question configured, e.g. an alias of an existing subscription with "no hosting" type, the main domain of a subscription, etc. If possible to provide us with step-by-step instructions on how to configure the subscription/domain in question and attempt to reproduce the SSL installation issue would be highly appreciated. Thank you in advance!

 

[G J Piper]

Hello, @G J Piper . I am not entirely sure I was able to fully understand the exact configuration you are having troubles with. Would you mind confirming how exactly is the domain name in question configured, e.g. an alias of an existing subscription with "no hosting" type, the main domain of a subscription, etc. If possible to provide us with step-by-step instructions on how to configure the subscription/domain in question and attempt to reproduce the SSL installation issue would be highly appreciated. Thank you in advance!

Sure thing.
I have external DNS at GoDaddy and it gets set up as follows (e.g. domain.com):

1. I set A records "@" and "www" to point to one remote IP address which I do not host, where the domain.com website resides.
2. I set A records "mail" and "webmail" to point to my hosting IP.
3. I set MX record (@) to point to "mail.domain.com" found in the A records.

Then, in Plesk:

1. I add a subscription of the root domain "domain.com" and add an alias to that domain of "mail.domain.com"
2. I turn on mail service for the domain, but turn "Hosting type" to "no web hosting".
3. I go into the "SSL/TLS Certificates" section and select "Reissue Certificate" then in the next window "Install".
4. In the resulting window I have options to secure webmail, mail, and the alias "mail" and I check them.

Unfortunately, that is as far as I get because the "Get it free" button to engage the process is greyed out.
Unchecking and re-checking boxes does not enable it.

The only way I was able to get the button to work is the go back and set the "Hosting type" to "Website" and then go in and the Certificate is able to be activated.
However, in this process the main domain and "www" fail to produce a certificate with errors from Let's Encrypt because the root domain IP is not on this server.
It DOES, though, set up a good certificate for the mail and webmail server at this point even though it says it failed, and it stays active even after going back in and then turning "Hosting type" back to "no web hosting".
Of course, this process is not ideal and will not ever automatically renew the certificate.

 

[Sebahat.hadzhi]

Thank you for the confirmation and the instructions. I think the alias is causing the issue in this particular case. Do I correctly understand that the mail alias is for the same primary domain name? If yes, please try removing the alias domain name. You should still be able to issue an SSL certificate for mail.domain.com and webmail.domain.com without the need of the alias. Please let me know if that worked out.

 

[G J Piper]

That seems to have worked, but how does plesk or Let's Encrypt know to add a certificate for the mail.domain.com when there is no alias for it?
What if I needed the mail server to be "smtp.domain.com" instead... how would it know?
*confused why it worked*

I have a "mail.domain.ext" alias on every domain I host, even fully hosted domains, specifically so the mail server will run with "mail.domain.ext" settings for my clients. Unneeded?

 

[Kaspar]

That seems to have worked, but how does plesk or Let's Encrypt know to add a certificate for the mail.domain.com when there is no alias for it?

Plesk has introduced this feature to work specifically with the mail.* prefix/subdomain for domains with the "no web hosting" type hosting. The prerequisite for this feature is that there needs to be a DNS record for the mail host pointing to the Plesk server (otherwise Let's Encrypt can't validate the domain).

What if I needed the mail server to be "smtp.domain.com" instead... how would it know?

It does not work for any another prefix/subdomain, only the mail.* prefix/subdomain is supported.

I have a "mail.domain.ext" alias on every domain I host, even fully hosted domains, specifically so the mail server will run with "mail.domain.ext" settings for my clients. Unneeded?

Still needed for domains which you fully host, just no longer needed for domains with the "no web hosting" type hosting.

 

[G J Piper]

I'd say my issue is resolved with your help, @Kaspar and @Sebahat.hadzhi! Thank you.