Facebook
Twitter
DerDanilo
Basic Pleskian
Thanks for providing this option but it's missing some important features to be properly usable. Also there seem to be some kind of bugs (or it's designed this ways by default).
Auto discovery also still seems to have issues before being properly usable.
1. mail. / imap. / mail. / pop3. / pop. <domain> don't seem to be included when creating a certificate while also assigning it to the mailserver.
Plesk could check DNS for such subdomains and include them into the certificate. It would already be of great help if "mail.<domain>" would be included in the certificate request since auto discovery configured mail.<domain> per default. It's possible to make sure the name is included manually but this required extra steps (not good, nor does this scale).
In some cases auto discovery seems to configure the root domain as mail server which is a really(really!) bad idea. e.g. if a CDN or e.g BruteForce protection is used in front of the root domain website. Hence mail. or webmail. should be the default.
2. webmail.<domain> doesn't seem to be served with the right certificate by the mail server (IMAP + SMTP)
Webmail.<domain> is included in the same cert that is used by the website and also by the mailserver (Assign the certificate to mail domain"), so why isn't webmail.<domain> accepted here? Some SNI mapping seems
Hence when a mail client tries to connect to the mailserver using webmail.<domain> the server default cert is served.
For dovecot I could easily test to allow other mail (sub)domains:
Postfix SNI maps are hased but should also be possible to change.
"mail.<domain>" seems to serve the selected (assign the cer...) certificate by default even though mail.<domain> is not included in a certificate request by default. Why is that?
- Why is mail.<domain> not included when assigning the certificate to the mailserver?
- Why seems mail.<domain> to be served with the selected certificate even though it's not even included in the cert alternative names?
- Why was this feature released if not fully tested and properly implemeted (full process tests with many pilot users) ?
In the current state it's more or less unusable since it just causes a lot of headache and customer tickets. So we have to stick to the default servername for now.
@plesk Team
Please "fix" these issues to make customer certificates properly usable.
It would also be of huge help if domains/subdomain/more domains that should be used for mail server config/SNI maps would be configurable in the `Panel.ini`.
Maybe these settings can find it's way into the mail server settings.
The same goes for the autodiscovery config -> What subdomain to use etc.
Thanks in advance!
---
Here is the content of my post on the autodiscovery support article:
support.plesk.com
Auto discovery also still seems to have issues before being properly usable.
1. mail. / imap. / mail. / pop3. / pop. <domain> don't seem to be included when creating a certificate while also assigning it to the mailserver.
Plesk could check DNS for such subdomains and include them into the certificate. It would already be of great help if "mail.<domain>" would be included in the certificate request since auto discovery configured mail.<domain> per default. It's possible to make sure the name is included manually but this required extra steps (not good, nor does this scale).
In some cases auto discovery seems to configure the root domain as mail server which is a really(really!) bad idea. e.g. if a CDN or e.g BruteForce protection is used in front of the root domain website. Hence mail. or webmail. should be the default.
2. webmail.<domain> doesn't seem to be served with the right certificate by the mail server (IMAP + SMTP)
Webmail.<domain> is included in the same cert that is used by the website and also by the mailserver (Assign the certificate to mail domain"), so why isn't webmail.<domain> accepted here? Some SNI mapping seems
Hence when a mail client tries to connect to the mailserver using webmail.<domain> the server default cert is served.
For dovecot I could easily test to allow other mail (sub)domains:
Code:
/etc/dovecot/conf.d# cat 14-plesk-sni-<domain>.conf
local_name <domain> {
ssl_cert = </opt/psa/var/certificates/scfOdrQcV
ssl_key = </opt/psa/var/certificates/scfOdrQcV
}
local_name webmail.<domain> {
ssl_cert = </opt/psa/var/certificates/scfOdrQcV
ssl_key = </opt/psa/var/certificates/scfOdrQcV
}
systemctl restart dovecotPostfix SNI maps are hased but should also be possible to change.
Code:
/etc/postfix/main.cf:tls_server_sni_maps = hash:/var/spool/postfix/plesk/certs"mail.<domain>" seems to serve the selected (assign the cer...) certificate by default even though mail.<domain> is not included in a certificate request by default. Why is that?
- Why is mail.<domain> not included when assigning the certificate to the mailserver?
- Why seems mail.<domain> to be served with the selected certificate even though it's not even included in the cert alternative names?
- Why was this feature released if not fully tested and properly implemeted (full process tests with many pilot users) ?
In the current state it's more or less unusable since it just causes a lot of headache and customer tickets. So we have to stick to the default servername for now.
@plesk Team
Please "fix" these issues to make customer certificates properly usable.
It would also be of huge help if domains/subdomain/more domains that should be used for mail server config/SNI maps would be configurable in the `Panel.ini`.
Maybe these settings can find it's way into the mail server settings.
The same goes for the autodiscovery config -> What subdomain to use etc.
Thanks in advance!
---
Here is the content of my post on the autodiscovery support article:
How to manage mail autodiscover in Plesk Obsidian?
Applicable to: Plesk Obsidian for Linux Question How to manage mail autodiscover in Plesk? Answer Autodiscover is enabled by default on all new Plesk Obsidian installations for all domains. For...
Last edited:
