Skip to main content

Comments

19 comments

  • 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.
    0
  • keat63
    Update. I tinkered in 'Manage Service SSL Certificates' resetting them and now it seems to be working.
    0
  • 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: [QUOTE="Gast"n, post: 2672919, member: 783141">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.
    0
  • keat63
    I see this error occured yesterday morning which seems to correspond to around the time I discovered the problem.
    0
  • 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!
    0
  • keat63
    I spotted 80.0.15 had been released. I assumed (wrongly) that it might have been to fix this issue.
    0
  • 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
    0
  • nixuser
    Is the ssl certificate still valid or using a self-signed one?
    0
  • cPanelMichael
    Hello, To update, here's the entry in the Release Tier on the link below:
    0
  • 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).
    0
  • cPanelMichael
    Hello Pete, It's possible this relates to the case discussed on the following thread: Can you review the above thread and confirm if you find the same error message in /usr/local/cpanel/logs/error_log? Thank you.
    0
  • PeteS
    Hello Pete, It's possible this relates to the case discussed on the following thread:
    0
  • 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.
    0
  • 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
    0
  • cPanelMichael
    Hello Pete, It's difficult to know for sure without access to the affected server. Feel free to open a
    0
  • PeteS
    Hello Pete, It's difficult to know for sure without access to the affected server. Feel free to open a
    0
  • 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.
    0
  • 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:
    0

Please sign in to leave a comment.