Fix incorrect calculation of secure mail server hostname
Our servers use a wildcard SSL certificate for cPanel/WHM/Exim/FTP etc. The certificate is issued to *.[our server domain name]
In cPanel 11.34, the information displayed under Configure Email Client (via Webmail or More dropdown in Email Accounts) displays mail.[our server domain name] as the mail server for secure connections, which is simply incorrect. Our server hostnames are s##.[our server domain name] where ## is the server number, and the server hostname is what should be used for secure mail connections.
To work around this we have some script code in /scripts/postupcp to replace the incorrect values in /var/cpanel/ssl/dovecot-CN and /var/cpanel/ssl/exim-CN with the correct values.
This needs to be better handled, otherwise all cPanel hosts using wildcard certificates for SSL across multiple servers are going to have support headaches from hosting client who see and try to use the invalid hostname for a secure mail connection.
My proposed fix would be to have similar options for this information in Tweak settings as you do for SSL redirect destination, i.e. allow us to choose between the SSL Certificate Name or the Hostname for the mail server hostname shown for secure mail connections in cPanel/Webmail.
This has been re-written with the addition of SNI and proper wildcard support in 11.38.
This has been re-written with the addition of SNI and proper wildcard support in 11.38.
This can't happen soon enough... To the OP - do you have a copy of the script tweaks?
This can't happen soon enough... To the OP - do you have a copy of the script tweaks?
We have this same issue. What a pain!
I would also like a copy of the script code you are using :)
We have this same issue. What a pain!
I would also like a copy of the script code you are using :)
my $host = `/bin/uname -n`;
my $dovecot = '/var/cpanel/ssl/dovecot-CN';
my $exim = '/var/cpanel/ssl/exim-CN';
if (open OUTF, ">$dovecot") {
print OUTF $host;
close OUTF;
}
if (open OUTF, ">$exim") {
print OUTF $host;
close OUTF;
}
# Check if /scripts/postupcp has been modified to call this script
my $postupcp = '/scripts/postupcp';
if (open CPS, "<$postupcp") {
# read log into array
@logf = <CPS>;
close CPS;
}
if (!(@logf ~~ m/cpanel_fixmailcn/)) {
# If the script is not in the hook file, then add it to the end
my $script = "/root/scripts/cpanel_fixmailcn.pl\n";
if (open CPS, ">>$postupcp") {
print CPS $script;
close CPS;
}
}
my $host = `/bin/uname -n`;
my $dovecot = '/var/cpanel/ssl/dovecot-CN';
my $exim = '/var/cpanel/ssl/exim-CN';
if (open OUTF, ">$dovecot") {
print OUTF $host;
close OUTF;
}
if (open OUTF, ">$exim") {
print OUTF $host;
close OUTF;
}
# Check if /scripts/postupcp has been modified to call this script
my $postupcp = '/scripts/postupcp';
if (open CPS, "<$postupcp") {
# read log into array
@logf = <CPS>;
close CPS;
}
if (!(@logf ~~ m/cpanel_fixmailcn/)) {
# If the script is not in the hook file, then add it to the end
my $script = "/root/scripts/cpanel_fixmailcn.pl\n";
if (open CPS, ">>$postupcp") {
print CPS $script;
close CPS;
}
}
I've just been bitten by this bug. Any way of correcting the existing entries for already created accounts?
I've just been bitten by this bug. Any way of correcting the existing entries for already created accounts?
I'm also seeing this issue which is causing my users some confusion. This needs to be addressed by cPanel right away!
I'm also seeing this issue which is causing my users some confusion. This needs to be addressed by cPanel right away!
This is also a simple fix in the meantime.
Create a file called fix_cn.sh and paste this in.
This is also a simple fix in the meantime.
Create a file called fix_cn.sh and paste this in.
Can someone confirm?
Can someone confirm?
This has at least updated the values, however I think it breaks the auto-discovery (at least in Thunderbird it seems to have)
This has at least updated the values, however I think it breaks the auto-discovery (at least in Thunderbird it seems to have)
This has been re-written with the addition of SNI and proper wildcard support in 11.38.
This has been re-written with the addition of SNI and proper wildcard support in 11.38.
Sorry I didn't notice the request for my script earlier! Just saw an update to this request and visited. What I did was simply to add this to /scripts/postupcp:
(replace mail.cpanelservices.com above with whatever incorrect hostname cPanel is using on your servers.)
Sorry I didn't notice the request for my script earlier! Just saw an update to this request and visited. What I did was simply to add this to /scripts/postupcp:
(replace mail.cpanelservices.com above with whatever incorrect hostname cPanel is using on your servers.)
Hi guys - I can see that a change has now been implemented - but the SSL info is simply displaying the same hostname as the non SSL info - i.e "mail.domain.com". How can we change this to show the server's hostname again? The above fixes worked great - but now we are on 11.38 it has changed.
Hi guys - I can see that a change has now been implemented - but the SSL info is simply displaying the same hostname as the non SSL info - i.e "mail.domain.com". How can we change this to show the server's hostname again? The above fixes worked great - but now we are on 11.38 it has changed.
In case anyone has the same issue... If using a wildcard cert - since the update to 11.38, The server's hostname will not be correctly identified if it contains uppercase letters, so it will revert to prefixing the customer's domain with "mail" instead of correctly displaying the server's hostname. While uppercase hostnames are not invalid - I've changed all mine to lowercase to make sure this works.
In case anyone has the same issue... If using a wildcard cert - since the update to 11.38, The server's hostname will not be correctly identified if it contains uppercase letters, so it will revert to prefixing the customer's domain with "mail" instead of correctly displaying the server's hostname. While uppercase hostnames are not invalid - I've changed all mine to lowercase to make sure this works.
Replies have been locked on this page!