SSL/TLS with mail. subdomain

Should the mail. subdomain be set as it's own VirtualHost ServerName in the Apache configuration? I know the push is being made to provide secure certificates for everything. With Let's Encrypt (or at least the way I'm manually issuing these, can't speak for cPanel's Comodo certificates but I suspect it functions in much the same way) you can specify what SANs to include on a certificate. We typically do example.tld, [plain]www.example.tld[/plain], and mail.example.tld. This allows for web links to either [plainhttps://example.tld[/plain] or [plainhttps://www.example.tld[/plain] to be secure while also allowing the user to use mail.example.tld in their email client to use secure POP3/IMAP/SMTP. But what if someone purchases a secure certificate? I know with PositiveSSL DCV certficates the only hostnames that get listed on the certificate are example.tld and [plain]www.example.tld[/plain]. mail.example.tld does not get listed as a SAN on the certificate. I believe RapidSSL DCV certificates are the same way. I really can't speak for most of the other non-multi-domain or non-wildcard certificates. Why does this matter? If someone installs a PositiveSSL DCV certificate for example.tld and [plain]www.example.tld[/plain], then they won't be able to install a Let's Encrypt (or cPanel Comodo) certificate for mail.example.tld. This is because the Apache configuration only allows one certificate to be installed per VirtualHost (on the basis of ServerName). Because mail.example.tld is added as a ServerAlias you can't install another certificate. Possible Solutions: 1) Somehow convince all of the certificate authorities to add mail.example.tld to the SAN for all issued certificates. They did this for [plain]www.example.tld[/plain], so maybe they can be convinced to do the same thing for mail.example.tld. Downside: What to do about certificates that are already issued? 2) Separate out mail.example.tld into it's own VirtualHost container. This way example.tld and [plain]www.example.tld[/plain] could install it's own certificate any way that they want to. And then mail.example.tld can have it's own Let's Encrypt or cPanel Comodo certificate installed. Downside: How would this affect domains and certificates that are already issued for example.tld, [plain]www.example.tld[/plain], and mail.example.tld and how these certificates would be installed going forward? 3) Allow for separate service installations for certificates. I don't think this exists, but if it does feel free to correct me. Getting a certificate for mail.example.tld issued is academic. But cPanel does not provide a facility for installing that certificate on select services. Instead there is just an "install certificate". Now, you could manually add the certificates to /etc/dovecot/sni.conf and to /var/cpanel/ssl/domain_tls/mail.example.tld/combined but I suspect that doing so would create it's own problems with cPanel (especially /etc/dovecot/sni.conf since I suspect this file is rebuilt by cPanel on a need to basis) since the whole thing isn't exactly cPanel kosher. If cPanel would provide a way to install a certificate for specific services (Apache, Dovecot, Exim, All Three) that might resolve this issue. Keeping track of these certificates and where what is installed might become a headache. It would appear that you can install the combined key, certificate, ca bundle into the file /var/cpanel/ssl/domain_tls/mail.example.tld/combined, the certificate and ca bundle into /var/cpanel/ssl/domain_tls/mail.example.tld/certificate and run /scripts/build_mail_sni --rebuild_dovecot_sni_conf this will install the mail.example.tld certificate for Exim and Dovecot. But it does not add the certificate into cPanel's certificate database, so cPanel doesn't know about it. This means the certificate is not backed up or treated as part of the account during a migration. 4) Just ignore this and tell clients to use example.tld as their mail server hostname. The mail. prefix really isn't needed, but for whatever reason it's come to be expected when using email clients. This "issue" can be further extended into domain aliases, since they are added as ServerAliases in the Apache configuration and not as their own VirtualHost container. If a domain alias registration expires that can interfere with the automatic renewal of the certificate for that VirtualHost container or if a domain alias is added, the whole VirtualHost container secure certificate has to be reissued. This can become problematic for accounts that add and remove Domain Aliases on a whim. All-in-all this move to secure everything is resulting in some issues that were never properly thought all the way through. ServerAliases in Apache did not matter way back when, when SSL/TLS wasn't expected to be every where. Now that it is, the application of a lot of tasks is having to be reworked to fall in line with SSL/TLS behavior.