Valid service certificates replaced
Please see the following thread for reference...
hostname SSL cert replaced with cPanel issued version
I wanted to add to this because the problem is still not resolved.
1. We use Geotrust AlphaSSL Wildcard certificates for our service certificates.
2. These are not due to expire until next year, however we enabled the option in tweak settings to replace these when they are due to expire.
3. Unfortunately cpanel has immediately replaced these overnight.
It wouldn't normally be such a problem - but it seems this causes a major issue with Apple devices. They seem to notice that the certificate has changed and immediately revoke it, so we now have hundreds of customers who can't get their Email - at a time of year when we'd rather not have a sudden influx of support tickets!
-
but it seems this causes a major issue with Apple devices. They seem to notice that the certificate has changed and immediately revoke it
Sounds bad. Can you explain what you mean with "revoke it". Is there a error message on the iOS platform? AutoSSL installed the Comodo cpanel certs? Not the Let's Encrypt certs? The replacement shouldn't happend but the cpanel certs shouldn't cause any issue on iOS (at least 10 or 11) as well.0 -
Sorry I didn't mean "revoked" as such. The certificate becomes untrusted and in iOS10 there is no option tot trust the certificate. On a mac computer it seems the end user can simply trust the new cert. As with most cpanel servers, the servers certificate doesn't match the end users domain name, so certificate mismatch errors occur in the Email client. It's fine when the certificate can be explicitly trusted, but iPhones don't offer that anymore. So far we've asked the client to change their inbound and outbound mail server details from mail.domain to the actual server's hostname - which directly matches the hostname in the certificate. This may not pose a problem in the future when every domain has its own certificate for email, but currently it's an issue. 0 -
This may not pose a problem in the future when every domain has its own certificate for email, but currently it's an issue
This is possible. I was waiting for that feature too. But the issue with the cPanel cert is not a hostname mismatch, isn't it? Perhaps it is an issue with the intermediate cert on your server. I had no issues with the cPanel Comodo certs with iOS 10 and iOS 11. Did you try it with a iOS device you own? Just to reproduce the issue? Perhaps the cert chain is broken or the embedded host names in the cert are incorrect. Or did you solve the issue? Reinstalling your cert and deactivating AutoSSL? Or is the mail connection issue pending and your users are flodding your support-desk?0 -
Yes it turned out to be simply a hostname mismatch. The issue only happens when they are using mail.domain and they don't have a certificate of their own. Previously the iPhone user could trust the cert (and they will have done so originally, when adding the Email account on their phone) but that option has been removed in iOS10 - so when the cert was updated, they received the certificate error once again, but had no option to simply trust the certificate like they did originally. We had to ask the affected clients to change the incoming and outgoing servers to the server's hostname. The same issue happens in the Mac mail client -but the option to trust the certificate is still available. My main reason for posting is really to point out that the issue of the certificate being replaced has still not been resolved. If I'd known the cert would be replaced overnight, instead of a few days before expiry I wouldn't have enabled the option to replace the service certificate with the cpanel / comodo cert on expiry. 0 -
. We use Geotrust AlphaSSL Wildcard certificates for our service certificates. 2. These are not due to expire until next year, however we enabled the option in tweak settings to replace these when they are due to expire. 3. Unfortunately cpanel has immediately replaced these overnight.
Hi @4u123, The following option is found under the "Domains" tab in "WHM >> Tweak Settings": Replace SSL certificates that do not match the local hostname Per it's description: When you enable this option, the checkallsslcerts script will replace any SSL certificates that do not match the hostname of the server with a cPanel-signed certificate. This includes wildcard certificates. Can you confirm if this is the option you enabled? If so, it's by-design that it will immediately replace SSL certificates (including wildcard certificates) that do not match the hostname. It's not based on when the certificate expires. Thank you.0 -
Hi @4u123, The following option is found under the "Domains" tab in "WHM >> Tweak Settings": Replace SSL certificates that do not match the local hostname Per it's description: When you enable this option, the checkallsslcerts script will replace any SSL certificates that do not match the hostname of the server with a cPanel-signed certificate. This includes wildcard certificates. Can you confirm if this is the option you enabled? If so, it's by-design that it will immediately replace SSL certificates (including wildcard certificates) that do not match the hostname. It's not based on when the certificate expires. Thank you.
It's not "by design". It's just another oversight. You wouldn't realistically want to replace a wildcard certificate because it actually does match the server's hostname. It's only that your developers hadn't correctly considered wildcard certs and did a half arsed job - as seems to be the case with everything you guys do at the moment. You so often quote the term "by design" or Intended "behaviour" just to try to cover up for your lack of consideration and proper planning. It's getting a bit tired now.0 -
Hello @4u123, As I understand, you'd prefer to have the functionality of the "Replace SSL certificates that do not match the local hostname" option, but with built-in support for wildcard certificates so that it detects signed/trusted wildcard SSL certificates (e.g. *.domain.tld is not automatically replaced if the hostname is server.domain.tld). You are correct that this feature was not designed with the intent to detect or support wildcard SSL certificates. We added the Replace SSL certificates that do not match the local hostname option in "WHM >> Tweak Settings" in cPanel verison 64 to help prevent the exact situation you encountered: Fixed case CPANEL-8922: Allow disabling the replacement of certs during hostname mismatch. This may not pose a problem in the future when every domain has its own certificate for email, but currently it's an issue.
This seems to be the core of the issue. With AutoSSL and Domain TLS, free signed SSL certificates for each domain name are supported: What is Domain TLS - cPanel Knowledge Base - cPanel Documentation Could you provide some insight into what's preventing every domain name from having it's own separate certificate for email? Are you running into issues with AutoSSL? Thank you.0 -
Why do you assume that we would use AutoSSL on any server? The mail SNI doesn't work anyway. All users are presented with the servers service certificate when connecting to mail and not the certificate that is installed on the users domain. 0 -
The mail SNI doesn't work anyway. All users are presented with the servers service certificate when connecting to mail and not the certificate that is installed on the users domain.
Have the email clients been configured to use "mail.domain.tld" as the mail server name, or are they configured to use the server's hostname? Thank you.0 -
Makes no difference whether they use their domain name, the mail subdomain or the server hostname, they get presented with the servers certificate each time. FYI as far as I'm aware this is the same across all our servers and has never worked. We instruct all users to use the server's hostname - we always have, because that way you can guarantee a valid certificate - but unfortunately due to another oversight on your part, the information provided in the Email client setup area in cpanel is telling our customers to use their own domains, against the advice we give them. You haven't considered that for consistency, web hosts might want to always use the server hostnames, regardless of whether the client has a cert installed. So you've not put in any provision for that. The ideal scenario for me in our primary environment would be to enforce the use of the server hostname across the board, with no "mail" subdomains in existence at all, no mail sni, no silly vhost entries and with the info within the cpanel Email client configuration telling them to use the servers hostname no matter what. Perhaps if I put in a feature request, in a decade, an option might get added to tweak settings for us to do that. Unfortunately I will have died of frustration and disillusionment by then. 0 -
Makes no difference whether they use their domain name, the mail subdomain or the server hostname, they get presented with the servers certificate each time. FYI as far as I'm aware this is the same across all our servers and has never worked.
Hello, It seems like something isn't working correctly because the Domain TLS functionality should ensure this works as long as a SSL certificate is installed for the domain name (or the server's hostname if it matches the service certificate name): What is Domain TLS - cPanel Knowledge Base - cPanel Documentation We're happy to take a closer look at this via a support ticket if you are interested. You can post the ticket number here should you decide to open a support ticket and we'll update this thread with the outcome. Thank you.0
Please sign in to leave a comment.
Comments
11 comments