Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 03/14/2019 in all areas

  1. 1 point
    Hey all, I've noted this thread in the internal case log and have asked internally if we can look at the priority on this one 🙂
  2. 1 point
    @WHMCS John your reply illustrates the biggest problem of WHMCS. You can't communicate. Not to your customers and not to each other. There hasn't been a single request on requests.whmcs.com asking for this feature, yet it is implemented. This has obviously been fuelled by your MarketPlace partners, not by your customers. And to be fair I wouldn't mind if a feature is useful and works, but you have to be open about it. You're not. And if it breaks, step up and get it fixed. Stop hiding behind arguments that you're not a system administrator. This is a developer at fault, 100%. You're only telling part of the story. You're not helping, at all. I can understand why your customers are getting more and more frustrated. It checks for a 51 error; It tries to get the SSL details for which it needs CURLINFO_CERTINFO. Even if cURL is working on the CLI, your PHP implementation can still fail. But that's not all. If you have a version of cURL on your server that supports CURLINFO_CERTINFO the cron doesn't necessarily work, simply because WHMCS needs a different database collation; which isn't part of a database migration nor of your release notes or documented requirements. WHMCS has been informed about the CURLINFO_CERTINFO problem AND have been given a workaround by at least two of your customers. It has already been reported as a bug. The fact that you keep saying that the 51 error code is what WHMCS is looking for shows that you're not communicating with each other. If you would, the troubleshooting page would have been updated with both the CURLINFO_CERTINFO information and the changed collation requirements would have been communicated, too. Neither is the case. On to solving the actual problem for those who read this too. Copy the following into a PHP file on your server. <?php $domain = 'www.whmcs.com'; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'https://' . $domain); curl_setopt($ch, CURLOPT_CERTINFO, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_NOBODY, 1); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); curl_setopt($ch, CURLOPT_TIMEOUT, 10); curl_setopt($ch, CURLOPT_VERBOSE, true); if(curl_exec($ch) === false){ echo 'Curl error: ' . curl_error($ch); } $certInfo = curl_getinfo($ch, CURLINFO_CERTINFO); print_r($certInfo); ?> If you open it in your browser. The first line should start with: Array ( [0] => Array ( [Subject] => CN = *.whmcs.com [Issuer] => C = US, O = DigiCert Inc, OU = www.digicert.com If it doesn't your version of cURL doesn't come with CURLINFO_CERTINFO. You either need to update cURL or speak to WHMCS to implement an alternative (and keep your fingers crossed). If you need to update cURL tread carefully. Don't use third party repositories, either speak to a sysadmin or to support of the control panel you're using. If it does, try to run the cron manually: php -q crons/cron.php do --SslSync -vvv Are you seeing errors? They will probably be something like: SQLSTATE[42000]: Syntax error or access violation: 1253 COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1' (SQL: select `userid`, `domain` from `tblhosting` left join `tblsslstatus` on concat("" COLLATE utf8_unicode_ci, tblhosting.domain) = `tblsslstatus`.`domain_name` where `domain` != and `tblsslstatus`.`id` is null limit 100) This is because WHMCS made a breaking change. The solution is to add the following to your configuration.php: $mysql_charset = 'utf8'; Be careful as this may break your currency character(s). Head over to Setup >> Payments >> Currencies and save each and every currency you use. Double check if everything works by looking at transactions, invoices. Don't forget the PDFs. Was this so hard to document, WHMCS? Stop hiding. Start listening.
  3. 1 point
    perhaps by reading the PHP manual. http://php.net/manual/en/function.checkdnsrr.php
  4. -1 points
    Hi @ju5t, CURLINFO_CERTINFO is used to obtain the certificate information for display. If this is empty, you're correct that WHMCS will also be unable to retrieve certificate data. Thanks for your feedback regarding the help article on that point, I have passed that on to the documentation team. The Help > System Health Check status page has a version check to advise on the appropriate version of cURL to return this data. We are also tracking the specific environments with this flaw. As yet we've been unable to reproduce on stock CentOS7 repos we set up for testing this. But please do keep that info coming: PHP version OS OS Version CURL Version Output from Test Script In 7.7.0 we added PHP path detection logic to the cron command on the Setup > Automation Page, to help users in EasyApache Multi-PHP environments specify the same PHP binary for web and the CLI. In 7.7.1 we fixed an illegal mix of collations error which was reported. This specifically applied to older installations of WHMCS made where the server's default database charset/collation was not utf8. The Collation error now being discussed is unrelated to certificate validation; it would not prevent the SSL check on page load or cause false positives/negatives. But does stop the checks being performed in the background by the daily automation tasks. The `mysql_charset =utf8` line is standard on all installations since v5.3 (released in 2013) so most people should have it. It's presence is recommended. Case CORE-13267 has been opened to investigate how this error could be negated for installations with an latin1 charset.
×

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated