SOLVED [CPANEL-27859] TLS failure preventing access to /cpanel , /whm , and /webmail

[Gastón]

When our clients enter to his domains https://clientdomain.com/cpanel or https://clientdomain.com/webmail, the apache redirectos to port 2083,2096 are giving "SECURE CONNECTIONS ERRRORS".

When we enter to the primary domain https://serveromain.com/cpanel or https://serveromain.com//webmail and there is no problem at all.

The client Lets Encrypt certificate are good, because when I enter to https:// clientdomain.com/ his site is correctly signed with SSL Cert and everything looks fine.


The error log in /usr/local/cpanel/logs/error_log is:

TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
Cpanel::Server::TLSCache write() failed: Broken pipe at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 445.

df -i / df -h shows no problem, I have space in the disk. And the partitions ar writeable.

I tried /scripts/upcp upgraded to the last version, and nothing change.

Any ideas?

Regards.

 

[cPanelMichael]

Hello @Gastón,

We're tracking reports of this issue as part of internal case CPANEL-27859. I'll monitor this case and update this thread with more information as it becomes available.

In the meantime, the temporary workaround is to restart cpsrvd using the following command:

 /scripts/restartsrv_cpsrvd --restart

Thank you.

 

[keat63]

I updated to 80.0.14 last night, and now can't open webmail.

If I navigate to https://www.mydomain.com:2096 (or /webmail), I receieve the follwing error.
also https://www.mydomain.com:2083 (cpanel)

Secure Connection Failed

An error occurred during a connection to www.mydomain.com:2096.

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the web site owners to inform them of this problem.

I can get in to webmail via whm though.
Seems to affect multiple domains

 

[keat63]

Update.

I tinkered in 'Manage Service SSL Certificates' resetting them and now it seems to be working.

 

[cPanelMichael]

Hello @keat63,

I merged your thread into this one as it looks to relate to the case noted here. You can confirm if that's the case by searching the cPanel error log for the error message quoted below:

The error log in /usr/local/cpanel/logs/error_log is:

TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.

Thank you.

 

[keat63]

I see this error occured yesterday morning which seems to correspond to around the time I discovered the problem.

 

[leith]

I had the same problem on just 1 server. It presumably began after the upgrade to 80.0.15. My error_log is full of the errors you note but, thankfully, the restart you prescribe has fixed it.

Thanks for this post and assistance!

 

[keat63]

I spotted 80.0.15 had been released.
I assumed (wrongly) that it might have been to fix this issue.

 

[PeteS]

cPanel v80.0.20

After a reboot to fix the server running outdated scripts (last night) it looks like some security issues have been tightened up. For instance I used to be able access WHM at example.com:2087 and now it requires hostname.example.com:2087 (which is fine, but the change caught me off-guard). Without the hostname the browser cycles through TLS handshaking and then the server returns nothing (drops connection). I assume this connected with removing TLS 1.1 and requiring 1.2. Any comments on what we need to do to update TLS on existing servers? (I know that on new installs it is automatic.)

However, now example.com/webmail fails. It routes to example.com:2096 which fails with this error:

Secure Connection Failed

An error occurred during a connection to www.example.com:2096.

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
​

webmail.example.com works as expected.

Please advise.

-Pete

 

[nixuser]

Is the ssl certificate still valid or using a self-signed one?

 

[cPanelMichael]

Hello,

To update, here's the entry in the cPanel & WHM version 82 Change Log noting the fix for this issue:

Fixed case CPANEL-27859: Fix cpsrvd EBADF errors when Chrome reused connections.

You can see which versions are published to each Release Tier on the link below:

Latest cPanel & WHM Builds

Note there are active requests to backport this fix into cPanel & WHM versions 78 and 80. I'll update this thread with the status of those backport requests as new information becomes available.

Thank you.

 

[PeteS]

Is the ssl certificate still valid or using a self-signed one?

All certs are valid, not self signed. Autossl is enabled across the server. The only red padlocks are for cpanel., webdisk., and webmail. on the add-on domains (which are not in question here).

 

[cPanelMichael]

Hello Pete,

It's possible this relates to the case discussed on the following thread:

SOLVED - [CPANEL-27859] TLS failure preventing access to /cpanel , /whm , and /webmail

Can you review the above thread and confirm if you find the same error message in /usr/local/cpanel/logs/error_log?

Thank you.

 

[PeteS]

Hello Pete,

It's possible this relates to the case discussed on the following thread:

SOLVED - [CPANEL-27859] TLS failure preventing access to /cpanel , /whm , and /webmail

Can you review the above thread and confirm if you find the same error message in /usr/local/cpanel/logs/error_log?

Thank you.

Yes, I see the same error messages in the log file.

Looking around those lines (grep 'LS failure:' -B 4 -A 4) I sometimes find another script error:

TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
Cpanel::Server::TLSCache write() failed: Broken pipe at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 445.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
Cpanel::Server::TLSCache write() failed: Broken pipe at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 445.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.
Cpanel::Server::TLSCache write() failed: Broken pipe at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 445.
TLS failure: Cpanel::Server::TLSCache - read() failed: Bad file descriptor at /usr/local/cpanel/Cpanel/Server/TLSCache.pm line 275.

​

 

[cPanelMichael]

Hello @PeteS,

I merged your thread into this one, as it appears to match the description of case CPANEL-27859.

The temporary workaround (until your server is updated to a version with the fix) is to restart cpsrvd using the following command:

/scripts/restartsrv_cpsrvd --restart

Thank you.

 

[PeteS]

Hello @PeteS,

I merged your thread into this one, as it appears to match the description of case CPANEL-27859.

The temporary workaround (until your server is updated to a version with the fix) is to restart cpsrvd using the following command:

/scripts/restartsrv_cpsrvd --restart

Thank you.

Is it possible the fix already has been backported into v80? Because before applying the workaround I retested both issues I reported (example.com:2087 requiring hostname.example.com:2087, and example.com:2096 failing) and now they both work as before.

If not, then is this intermittent, and if so, does it require a re-run of the workaround after any reboot? (I assume the workaround persists only to the next reboot, correct?)

There have been no reboots since I initially diagnosed and reported this problem and it now appearing to be corrected (upcp has run daily).

-Pete

 

[cPanelMichael]

Hello Pete,

It's difficult to know for sure without access to the affected server. Feel free to open a support ticket and we can take a quick look to confirm that for you.

Thank you.

 

[PeteS]

Hello Pete,

It's difficult to know for sure without access to the affected server. Feel free to open a support ticket and we can take a quick look to confirm that for you.

Thank you.

Understood, and I opened a look-only ticket, but can you also answer my questions about the fix, work-around, and back-porting?

I will leave it to you as to whether you want to post ticket results here.

Support Request ID is: 12830653

-Pete

 

[cPanelMichael]

Hello Pete,

Thanks, I added a note to the ticket explaining the issue.

Is it possible the fix already has been backported into v80?

No, the fix from CPANEL-27859 is not published to cPanel & WHM version 80 at this time. The backport request remains open. One of the reasons for a ticket is so we can investigate and confirm the issue you encountered definitely stems from case CPANEL-27859. Generally, we require access to the affected system to make that determination.

Thank you.

 

[cPanelMichael]

Hello,

For anyone using cPanel & WHM version 80, this case is planned for backport to version 80.0.24. The full change logs are available on the link below:

Change Logs - Change Logs - cPanel Documentation

documentation.cpanel.net

Thank you.