Issue Add Let's Encrypt certificate for e-mail (DNS not hosted on Plesk)

[federicosayd]

Server operating system version

Linux Debian 10

Plesk version and microupdate number

Obsidian

We have a Plesk Obsidian Linux server hosting several domains. We only host e-mail servers for every domain on Plesk. We don't host web pages/sites on these domains. So DNS isn't managed/delegated to Plesk server.

We want to secure a domain with Let's Encrypt certificates, but when we try to get the certificates Plesk throws the following error:

The xxxx.com 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 xxxx.com
("Websites & Domains" > "Web Hosting Access") or remove the AAAA record from the xxxx.com DNS zone.

The DNS records for the domain are OK, as the main domain points to another server and we only need to configure records related to e-mail services.

We can't delete current records nor reconfigure IP address on Plesk server.

How can we solve this issue?

 

[IgorG]

Have you tried solutions from this KB article https://support.plesk.com/hc/en-us/...main-is-not-assigned-an-IPv6-address-in-Plesk ?

 

[mow]

Have you tried solutions from this KB article https://support.plesk.com/hc/en-us/...main-is-not-assigned-an-IPv6-address-in-Plesk ?

Those solutions are to delete the AAAA record or reconfigure the IP address. They expressly stated that they can't do that.

 

[Bitpalast]

@federicosayd I understand that you want to keep your web services elsewhere while you want to use your Plesk server for email services of several domains. You also do not want to use the host name as the mail server name, but want to create individual SSL certificates for email only so that the clients can use the domain name to connect to the mail server and receive individual SSL certificates for these connections.

The problem with that configuration is that Let's Encrypt certificates are domain validated certificates. They can only be issued and prolongated for domains that can be reached on the Internet through ports 80 (or 443) on the IP address where the certificate shall reside. If your domains are not routed to the Plesk server, Let's Encrypt cannot validate the authenticity correctly. For that reason it will not issue a certificate for a server that is not actually operating the domain. That's the "domain validated" in domain validated certificates like Let's Encrypt certificates.

The best practice here will be to use the host name of the mail server instead of an individual domain name as the outgoing or incoming mail server name. For the host name you can always have a certificate.

It is also thinkable that you route subdomains like imap.<yourdomain>, pop.<yourdomain>, smtp.<yourdomain> to your server and issue separate SSL certificates for these. That would be a kind of "simulation" that makes it look as if that server was responsible for the domain. Your other routes will not be affected. Your clients are used to using subdomains for mail clients like "imap.", "pop.", "smtp." so they will probably not notice that these subdomains are routed to a different server.

 

[mow]

Ugly workaround: Mount Plesk's .well-known directory on the real webserver (I used sshfs).

 

[manos]

@federicosayd I understand that you want to keep your web services elsewhere while you want to use your Plesk server for email services of several domains. You also do not want to use the host name as the mail server name, but want to create individual SSL certificates for email only so that the clients can use the domain name to connect to the mail server and receive individual SSL certificates for these connections.

The problem with that configuration is that Let's Encrypt certificates are domain validated certificates. They can only be issued and prolongated for domains that can be reached on the Internet through ports 80 (or 443) on the IP address where the certificate shall reside. If your domains are not routed to the Plesk server, Let's Encrypt cannot validate the authenticity correctly. For that reason it will not issue a certificate for a server that is not actually operating the domain. That's the "domain validated" in domain validated certificates like Let's Encrypt certificates.

The best practice here will be to use the host name of the mail server instead of an individual domain name as the outgoing or incoming mail server name. For the host name you can always have a certificate.

It is also thinkable that you route subdomains like imap.<yourdomain>, pop.<yourdomain>, smtp.<yourdomain> to your server and issue separate SSL certificates for these. That would be a kind of "simulation" that makes it look as if that server was responsible for the domain. Your other routes will not be affected. Your clients are used to using subdomains for mail clients like "imap.", "pop.", "smtp." so they will probably not notice that these subdomains are routed to a different server.

Using the root domain eg domain.com for MX is not good at all for users (i think we are majority) who use cloudflare as DNS and proxy. Ips for domain.com and www.domain.com will be cloudflare's ips so no connection can established to mailserver.
So can use mail.domain.com or smtp.domain.com whatever, and would be useful to issued SSL only for these that are not proxied by cloudflare, because wildcard need new acme record every 90 days.
Cpanel does it many years now