websavers Posted February 19, 2019 Share Posted February 19, 2019 (edited) curl output on the server looks fine to me, yet I get red locks for everything: * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=snipped.com * start date: Feb 17 20:13:14 2019 GMT * expire date: May 18 20:13:14 2019 GMT * common name: snipped.com * issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: snipped.com > Accept: */ (Domain is not snipped.com -- actual domain submit in support ticket). This is just one among many domains with the problem. Running the latest curlĀ release for CentOS 7: curl-7.29.0-51.el7.x86_64 Edited February 19, 2019 by jas8522 0 Quote Link to comment Share on other sites More sharing options...
websavers Posted February 21, 2019 Share Posted February 21, 2019 (edited) In case anyone else is having this problem, after some discussion and investigation by both the WHMCS dev team and Plesk dev team (they provide the PHP 7.x binaries), the issue appears to be directly with the CentOS 7 binary package of libcurl. It fails to return the certinfo data. This would presumably be a common issue as many hosting providers use CentOS 7 with its built in libcurl version. Given that it will probably take some time for the CentOS/RHEL dev team to implement a fix for this, I've asked WHMCS if they'd be willing to switching to using a stream_socket_client call to get certificate info rather than curl and am awaiting a response. Edited February 21, 2019 by jas8522 0 Quote Link to comment Share on other sites More sharing options...
wp4all Posted February 21, 2019 Author Share Posted February 21, 2019 (edited) Hi jas8522, you do not have to wait for WHMCS, so far you got root access just follow this forums entry here : https://talk.plesk.com/threads/curl-upgrade-on-plesk-12-5.338168/ Result:Ā # cat /etc/centos-release CentOS Linux release 7.6.1810 (Core) # ~# curl --version curl 7.64.0 (x86_64-redhat-linux-gnu) libcurl/7.64.0 NSS/3.36 zlib/1.2.7 libpsl/0.7.0 (+libicu/50.1.2) libssh2/1.8.0 nghttp2/1.31.1 Release-Date: 2019-02-06 # # # Ā Greetings Christian Edited February 21, 2019 by wp4all 0 Quote Link to comment Share on other sites More sharing options...
malfunction Posted February 21, 2019 Share Posted February 21, 2019 1 hour ago, wp4all said: Hi jas8522, you do not have to wait for WHMCS, so far you got root access just follow this forums entry here : https://talk.plesk.com/threads/curl-upgrade-on-plesk-12-5.338168/ Result:Ā # cat /etc/centos-release CentOS Linux release 7.6.1810 (Core) # ~# curl --version curl 7.64.0 (x86_64-redhat-linux-gnu) libcurl/7.64.0 NSS/3.36 zlib/1.2.7 libpsl/0.7.0 (+libicu/50.1.2) libssh2/1.8.0 nghttp2/1.31.1 Release-Date: 2019-02-06 # # # Ā Greetings Christian What, you mean the community thread where the guy from Plesk says "don't do this"? 2 Quote Link to comment Share on other sites More sharing options...
websavers Posted February 22, 2019 Share Posted February 22, 2019 3 hours ago, malfunction said: What, you mean the community thread where the guy from Plesk says "don't do this"? Haha, yep. It all depends on your level of trust and how that applies to your server. Do you trust the repo owner/packager in that they're not going to modify the packages to include spyware or some kind of possible backdoor? And possibly the more likely scenario: are they *always* going to be available to apply security patches when they need to be applied and release a new version in their repo. You know you can trust the CentOS/RHEL developers to do this, but with third party repos it's not a sure thing. I'd be OK with taking these risks on a single-site low-traffic VPS of my own, but I wouldn't do so on a shared hosting server. 0 Quote Link to comment Share on other sites More sharing options...
malfunction Posted February 22, 2019 Share Posted February 22, 2019 38 minutes ago, jas8522 said: I'd be OK with taking these risks on a single-site low-traffic VPS of my own, but I wouldn't do so on a shared hosting server.ļ»æ Yes, exactly right, same here. Ā For what its worth I believe Plesk 17.9 will bring an officially supported cURL update to 7.63, but that's still at the preview stage and I wouldn't consider it for production for a couple months at least. Ā So for the moment we're left with the latest version from the CentOS repo which is 7.29 as you know. Ā Of course if WHMCS actually did any meaningful testing before they threw this stuff out there.... 0 Quote Link to comment Share on other sites More sharing options...
websavers Posted February 22, 2019 Share Posted February 22, 2019 1 hour ago, malfunction said: Yes, exactly right, same here. Ā For what its worth I believe Plesk 17.9 will bring an officially supported cURL update to 7.63, but that's still at the preview stage and I wouldn't consider it for production for a couple months at least. Ā So for the moment we're left with the latest version from the CentOS repo which is 7.29 as you know. Ā Of course if WHMCS actually did any meaningful testing before they threw this stuff out there.... Well, at the very least, RedHat or the CentOS dev team *should* be responsible to fix this particular issue in their libcurl release without requiring the major version bump. But it's also very true that WHMCS devs should have tested this on the most common hosting platform out there: CentOS 7 stock. Given that it's an issue upstream with the OS packager which should affect many, I'm hopeful they'll seriously consider a workaround using stream sockets. 0 Quote Link to comment Share on other sites More sharing options...
wp4all Posted February 22, 2019 Author Share Posted February 22, 2019 Good morning, 7 hours ago, malfunction said: What, you mean the community thread where the guy from Plesk says "don't do this"?ļ»æļ»æ I certainly won't start a religious war here.Ā But even Plesk already states this approach as a solution on the support page. How to update cURL on a Plesk server by Alexandr TumanovĀ And hey yea there is also a WarningĀ Info regarding the OS package Manager but not against the repro. How safe you keep this repro is up to you. I'll only show you one solution, you can start to compile your own pack is your choice. Of course, you can also wait for WHMCS to create a solution for you which will probably never happen.Ā I toldĀ WHMCS in the BETA before the 7.7 publication theyĀ have a problem with the query, the answer was: "Sorry our query request works as expected,Ā please get in contact with your Systemadministrator to solve the ProblemĀ šĀ " Now it was a part of feeling 1000 Hotfixes in 7.7.1. !!!! So again don't do it if you feelĀ uncomfortable !!!! I will not justify myself and I will not write a leaflet with 100 side effects under my post. You are all adults but don't panic with such stupid comments. Sometimes I'm really surprised that nobody screams when a new source code encrypted addon comes out, guys think about the Trojans & Backdoors. Greetings Christian Ā Ā 0 Quote Link to comment Share on other sites More sharing options...
ju5t Posted March 3, 2019 Share Posted March 3, 2019 On 2/21/2019 at 9:28 PM, jas8522 said: In case anyone else is having this problem, after some discussion and investigation by both the WHMCS dev team and Plesk dev team (they provide the PHP 7.x binaries), the issue appears to be directly with the CentOS 7 binary package of libcurl. It fails to return the certinfo data. This would presumably be a common issue as many hosting providers use CentOS 7 with its built in libcurl version. Given that it will probably take some time for the CentOS/RHEL dev team to implement a fix for this, I've asked WHMCS if they'd be willing to switching to using a stream_socket_client call to get certificate info rather than curl and am awaiting a response. I wasn't aware of this thread but I have asked WHMCS for the exact same solution.Ā We were lucky as we're using DirectAdminĀ as it can update curl for you. However, we're still running into all sorts of issues. The cron fails silently with collation errors--even though the collation seems to be set right. The ssl check essentially runs a DDoS on your server when the above happens when your customers have 100+ domains. The ssl check is an AJAX-call which returns a hardcoded link to an image. Good luck if you have a custom theme. @WHMCS John, I think you should be much more open in your decision making process, requests.whmcs.com is a wasteland and so far every major release has included a 'feature' that includes new banners in the admin area. I am 100% willing to increase our monthly subscription fee if you would start to listen to your customers, improve your changelogs and documentation, and stopped shipping new features that have not been tested properly. 2 Quote Link to comment Share on other sites More sharing options...
DennyS Posted March 13, 2019 Share Posted March 13, 2019 On 18/02/2019 at 6:02 PM, WHMCS John said: Hi @jas8522, This is addressed in 7.7.1: https://docs.whmcs.com/Changelog:WHMCS_V7.7.1 Ā If you're still experiencing an issue, please refer to the following resources: https://docs.whmcs.com/SSL_Monitoring#Troubleshooting https://help.whmcs.com/m/85428/l/1035090-troubleshooting-red-ssl-monitoring-padlock-icons I am running version 7.7.1 and this red padlock is still an issue.Ā Why did you not give us the option to disable this? This is causing confusion from our customers and we look like idiots. My curl on the server is fine and does not return any errors. Its your code thats wrong. AllĀ of our customer sitessites that have SSL certificates are showing up with the red padlock!Ā unacceptable. So can we have a proper solution now? please provide a hotfix to clean up this mess. Ā 1 Quote Link to comment Share on other sites More sharing options...
Vox Posted March 13, 2019 Share Posted March 13, 2019 Hi @WHMCS John, On 2/18/2019 at 11:02 PM, WHMCS John said: Hi @jas8522, This is addressed in 7.7.1: https://docs.whmcs.com/Changelog:WHMCS_V7.7.1 Ā If you're still experiencing an issue, please refer to the following resources: https://docs.whmcs.com/SSL_Monitoring#Troubleshooting https://help.whmcs.com/m/85428/l/1035090-troubleshooting-red-ssl-monitoring-padlock-icons I will explain what a HUGE car-crash this is at the moment... I have a client who has transferred their domain registration to me. However, his site is currently hosted elsewhere but also subsequently redirected to another site. In his client area it is showing a Green Padlock for the domain. His final destination site does not support https and there is no SSL installed (which he wants). It would seem from doing an SSL check that you are picking up the server SSL of where the redirect is in place. He is asking me now why he is getting a Green padlock but cannot access his site via https Now I'm getting drawn in to a whole load of support issues that are not my making, I do not have the time or effort to waste on this! Are WHMCS now going to provide support direct to this client for me because I do not have the time or the inclination. WHAT AN ABSOLUTE FARCE. 1 Quote Link to comment Share on other sites More sharing options...
WHMCS Support Manager WHMCS John Posted March 13, 2019 WHMCS Support Manager Share Posted March 13, 2019 17 hours ago, DennyS said: I am running version 7.7.1 and this red padlock is still an issue.Ā Why did you not give us the option to disable this? This is causing confusion from our customers and we look like idiots. My curl on the server is fine and does not return any errors. Its your code thats wrong. AllĀ of our customer sitessites that have SSL certificates are showing up with the red padlock!Ā unacceptable. So can we have a proper solution now? please provide a hotfix to clean up this mess. Ā Hi @DennyS and @Vox WHMCS is looking for a "51" error code from cURL to determine that no SSL certificate exists. Provided a success response is returned, then cURL evaluates the certificate is valid, and WHMCS will report the same. What response code do you get when performing a cURL connection test from the WHMCS server to the domain in question please? 0 Quote Link to comment Share on other sites More sharing options...
DennyS Posted March 13, 2019 Share Posted March 13, 2019 16 minutes ago, WHMCS John said: Hi @DennyS and @Vox WHMCS is looking for a "51" error code from cURL to determine that no SSL certificate exists. Provided a success response is returned, then cURL evaluates the certificate is valid, and WHMCS will report the same. What response code do you get when performing a cURL connection test from the WHMCS server to the domain in question please? Hi John, there is no error in Curl. red lock in whmcs Spoiler https://screenshots.firefox.com/OYcFYZcQNAHbNnph/manage.bluebirdhosting.ca Ā curl -v https://webhosting-canada.net * About to connect() to webhosting-canada.net port 443 (#0) * Trying 155.138.128.186... * Connected to webhosting-canada.net (155.138.128.186) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=webhosting-canada.net * start date: Mar 11 19:57:47 2019 GMT * expire date: Jun 09 19:57:47 2019 GMT * common name: webhosting-canada.net * issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: webhosting-canada.net > Accept: */* > < HTTP/1.1 301 Moved Permanently < Server: nginx < Date: Wed, 13 Mar 2019 19:05:25 GMT < Content-Type: text/html; charset=iso-8859-1 < Content-Length: 248 < Connection: keep-alive < Location: https://webhosting-canada.net/index.html < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://webhosting-canada.net/index.html">here</a>.</p> </body></html> * Connection #0 to host webhosting-canada.net left intact Ā Ā 0 Quote Link to comment Share on other sites More sharing options...
DennyS Posted March 13, 2019 Share Posted March 13, 2019 Adding... using your curltest php script. #cat curltest.php <?php $url = "https://www.webhosting-canada.net/index.html"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_TIMEOUT, 10); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $data = curl_exec($ch); echo "CURL Connection: "; if (curl_error($ch)) { echo "ERROR ".curl_error($ch)."<br><br>"; } else { echo "SUCCESS<br><br>"; } curl_close($ch); echo "Data:<br><textarea rows=\"20\" cols=\"120\">$data</textarea>"; ?> [root@bs1 public_html]# php curltest.php CURL Connection: SUCCESS<br><br>Data:<br><textarea rows="20" cols="120"><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://webhosting-canada.net/index.html">here</a>.</p> </body></html> </textarea># Ā 0 Quote Link to comment Share on other sites More sharing options...
ju5t Posted March 13, 2019 Share Posted March 13, 2019 @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%. 49 minutes ago, WHMCS John said: WHMCS is looking ļ»æfor a "51" error code from cURL to determine that no SSL certificate exists.ļ»æļ»æļ»æ 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 Quote Link to comment Share on other sites More sharing options...
DennyS Posted March 13, 2019 Share Posted March 13, 2019 WoW thanks @ju5t ! I had collation errors, red everywhere. My I added the $mysql_charset to configuration.php and reran the cron below and no errors this time. However still red locks everywhere? Ā php -q crons/cron.php do --SslSync -vvv WHMCS Automation Task Utility: do ================================= Queuing Tasks ------------- Force run any tasks: ignore "in progress" and "is due" Task queues ready Executing Application Queue --------------------------- 0/1 [āāāāāāāāāāāāāāāāāāāāāāāāāāāā] 0% < 1 sec/< 1 sec 26.0 MiB SSL Sync 1/1 [āāāāāāāāāāāāāāāāāāāāāāāāāāāā] 100% 4 mins/4 mins 26.0 MiB Executing System Queue ---------------------- No tasks to execute in queue [OK] Completed Ā Ā 0 Quote Link to comment Share on other sites More sharing options...
malfunction Posted March 13, 2019 Share Posted March 13, 2019 ^^^ Great postĀ 0 Quote Link to comment Share on other sites More sharing options...
bear Posted March 14, 2019 Share Posted March 14, 2019 (edited) 4 hours ago, ju5t said: @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. Absolutely, and not for the first time.Ā This should be *optional*, and not enabled by default.Ā Edited March 14, 2019 by bear 0 Quote Link to comment Share on other sites More sharing options...
ju5t Posted March 14, 2019 Share Posted March 14, 2019 9 hours ago, DennyS said: However still red locks everywhere? The cron only updates 100 domains at a time. If a domain wasn't updated by the cron, it should be updated when you look at the list of domains as a customer or when you open it in the admin area. If that doesn't help there may cached results that you want to get rid off. Results are stored in the `tblsslstatus` table. You can empty it to clear the cache. This is all I know, I hope it helps. 0 Quote Link to comment Share on other sites More sharing options...
DennyS Posted March 14, 2019 Share Posted March 14, 2019 8 hours ago, ju5t said: The cron only updates 100 domains at a time. If a domain wasn't updated by the cron, it should be updated when you look at the list of domains as a customer or when you open it in the admin area. If that doesn't help there may cached results that you want to get rid off. Results are stored in the `tblsslstatus` table. You can empty it to clear the cache. This is all I know, I hope it helps. Thanks for the info on clearing the cache in db, however everything seems to be working this morning! green locks! After i made changes yesterday and re-ran the cron job a few times i was still seeing red locks. Perhaps the normal cron run updated the cache in db? I solved my issue by Installing Curl 7.64.0 and recompiled Apache. In the curl section of PHP info page im now seeing correct version of Curl withĀ OpenSSL/1.0.2k ! Also i did update my configuration.php with ; $mysql_charset = 'utf8'; Ā since without it, the cron command below was throwing all kinds of errors about db collation being latin1. Did the db collation for those tables change somewhere between 7.1 to 7.7 ? i was previously on 7.1 php -q crons/cron.php do --SslSync -vvv have a good one! Ā 0 Quote Link to comment Share on other sites More sharing options...
WHMCS Support Manager WHMCS John Posted March 14, 2019 WHMCS Support Manager Share Posted March 14, 2019 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. Ā Ā -1 Quote Link to comment Share on other sites More sharing options...
malfunction Posted March 14, 2019 Share Posted March 14, 2019 There you go then, official confirmation from the Head of Support that WHMCS is awesome and everything is fine. Except that it isn't š. Ā The clue is right there where he says "This works best in EasyApache environments.", which translated means that they couldn't care less about non-cPanel environments and make little or no effort to test for them. Ā They say "As yet we've been unable to reproduce on stock CentOS7 repos we set up for testing this". Ā Must have been some pretty thorough testing I'm sure, but it took me all of ten minutes to place the test file thatĀ @ju5tĀ kindly providedĀ on a handful of production CentOS & CloudLinux servers (both dedicated and virtualized)Ā and every one produced an empty array. Ā Peversely, it works well on Windows Server, but WHMCS don't support that any more. PHP version Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā 5.6 throughĀ 7.3 OS Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā CentOS 7.6 & CloudLinux 7.6 (both dedicated and virtualized instances) OS Version Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā 1810 / Vladimir Lyakhov CURL Version Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā 7.29 because that's the latest version in the CentOS 7 repo, deal with it Output from Test Script Ā Ā Empty array They say "The `mysql_charset =utf8` line is standard on all installations since v5.3 (released in 2013) so most people should have it." Ā OK, screw those guys that don't have it. Ā My primary install is older than that. I supposed we should be pleased that "Case CORE-13267 has been opened to investigate how this error could be negated for installations with an latin1 charset." (like mine) because it looks like they didn't test for that either. 0 Quote Link to comment Share on other sites More sharing options...
ju5t Posted March 14, 2019 Share Posted March 14, 2019 (edited) 2 hours ago, WHMCS John said: The Collation error now being discussed is unrelated to certificate validation; It is and isn't. As it can have pretty devastating side effects. If the cron isn't working and a customer with ~100 domains opens his/her domain overview, WHMCS will silently launch a DDOS on your server. Most likely consuming all database connections while it runs. 2 hours ago, WHMCS John said: The Help > System Health Check status page has a version check to advise on the appropriate version of cURL to return this data. A version check isn't sufficient. You need to run an actual check to test this. 7.19.1 was the first version of cURL to includeĀ CURLINFO_CERTINFO, yet 7.29 on CentOS doesn't include it. 2 hours ago, WHMCS John said: 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 If this is really true your testing processes fail and you need to get people on board who have even the most basic sysadmin skills. To put things to the test I have started a new VM with CentOS 7. Its versions are: 5.4 -- yes, that's the default on CentOS 7. CentOSĀ 7.6.1810 cURL 7.29.0 Output below: # php -q test.php ... Array ( ) An empty array indicates that theĀ CURLINFO_CERTINFO isn't installed. If you want to have a reproducible test, use Docker. I wrote you a simple bash script that will install PHP and runs the test script. If you have Docker running on any machine, this will launch a bare CentOS 7 container, installs PHP and runs the test script all in one go. docker run -it --rm centos:7 bash -c 'curl https://gist.githubusercontent.com/ju5t/e84f7ca83d3e0adc97134ca05ec1c4ca/raw/b9db6a14c5e1055ac97cb0d8b8393c5414375813/whmcs-test-ssl.sh | bash' @WHMCS JohnĀ it is disappointing how WHMCS handles this. I don't understand why you comeĀ up with arguments illustrating that you've done a good job. You really haven't. As I said before, it's time to be honest and open in your communication. But more importantly: start listening to your customers! Edited March 14, 2019 by ju5t 0 Quote Link to comment Share on other sites More sharing options...
wp4all Posted March 14, 2019 Author Share Posted March 14, 2019 Hi, also under curl 7.29 a proper query is possible: [root@vps02 ~]# cat /etc/centos-release CentOS Linux release 7.6.1810 (Core) [root@vps02 ~]# curl --version curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets [root@vps02 ~]# curl --insecure -v https://whmcs.com 2>&1 | awk 'BEGIN { cert=0 } /^\* SSL connection/ { cert=1 } /^\*/ { if (cert) print }' * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=*.whmcs.com * start date: Jun 25 00:00:00 2018 GMT * expire date: Jun 25 12:00:00 2019 GMT * common name: *.whmcs.com * issuer: CN=RapidSSL RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US * Connection #0 to host whmcs.com left intact [root@vps02 ~]# Curl is not mandatory use openssl php comands to pars the URL:Ā openssl-x509 <?php $url = "https://whmcs.com"; $orignal_parse = parse_url($url, PHP_URL_HOST); $get = stream_context_create(array("ssl" => array("capture_peer_cert" => TRUE))); $read = stream_socket_client("ssl://".$orignal_parse.":443", $errno, $errstr, 30, STREAM_CLIENT_CONNECT, $get); $cert = stream_context_get_params($read); $certinfo = openssl_x509_parse($cert['options']['ssl']['peer_certificate']); echo print_r($certinfo); and you get : [root@vps02 ~]# php ssl Array ( [name] => /CN=*.whmcs.com [subject] => Array ( [CN] => *.whmcs.com ) [hash] => 87529681 [issuer] => Array ( [C] => US [O] => DigiCert Inc [OU] => www.digicert.com [CN] => RapidSSL RSA CA 2018 ) [version] => 2 [serialNumber] => 4341417971671710519045517846942791534 [validFrom] => 180625000000Z [validTo] => 190625120000Z [validFrom_time_t] => 1529884800 [validTo_time_t] => 1561464000 [signatureTypeSN] => RSA-SHA256 [signatureTypeLN] => sha256WithRSAEncryption [signatureTypeNID] => 668 [purposes] => Array ( [1] => Array ( [0] => 1 [1] => [2] => sslclient ) [2] => Array ( [0] => 1 [1] => [2] => sslserver ) [3] => Array ( [0] => 1 [1] => [2] => nssslserver ) [4] => Array ( [0] => [1] => [2] => smimesign ) [5] => Array ( [0] => [1] => [2] => smimeencrypt ) [6] => Array ( [0] => [1] => [2] => crlsign ) [7] => Array ( [0] => 1 [1] => 1 [2] => any ) [8] => Array ( [0] => 1 [1] => [2] => ocsphelper ) [9] => Array ( [0] => [1] => [2] => timestampsign ) ) [extensions] => Array ( [authorityKeyIdentifier] => keyid:53:CA:17:59:FC:6B:C0:03:21:2F:1A:AE:E4:AA:A8:1C:82:56:DA:75 [subjectKeyIdentifier] => 69:F7:99:E1:73:D7:23:5B:33:7F:13:EC:38:89:6E:6E:08:A9:FA:58 [subjectAltName] => DNS:*.whmcs.com, DNS:whmcs.com [keyUsage] => Digital Signature, Key Encipherment [extendedKeyUsage] => TLS Web Server Authentication, TLS Web Client Authentication [crlDistributionPoints] => Full Name: URI:http://cdp.rapidssl.com/RapidSSLRSACA2018.crl [certificatePolicies] => Policy: 2.16.840.1.114412.1.2 CPS: https://www.digicert.com/CPS Policy: 2.23.140.1.2.1 [authorityInfoAccess] => OCSP - URI:http://status.rapidssl.com CA Issuers - URI:http://cacerts.rapidssl.com/RapidSSLRSACA2018.crt [basicConstraints] => CA:FALSE [ct_precert_scts] => Signed Certificate Timestamp: Version : v1(0) Log ID : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A: 3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10 Timestamp : Jun 25 14:17:07.633 2018 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:21:00:D7:A8:52:B2:E4:45:A4:97:E0:A2:10: BF:54:AF:42:D5:67:23:B8:52:A0:AC:C6:05:E5:F0:BA: 2A:F4:02:75:F8:02:20:56:F3:B2:D4:DB:39:FF:C1:F8: 33:CC:94:E6:8A:77:F5:5A:CF:44:75:4B:55:AD:E7:5F: FA:CB:37:5E:D5:70:AC Signed Certificate Timestamp: Version : v1(0) Log ID : 87:75:BF:E7:59:7C:F8:8C:43:99:5F:BD:F3:6E:FF:56: 8D:47:56:36:FF:4A:B5:60:C1:B4:EA:FF:5E:A0:83:0F Timestamp : Jun 25 14:17:07.823 2018 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:21:00:C4:B5:D7:D3:10:2D:3E:D6:56:0B:96: 0B:EF:66:A2:45:24:3D:02:00:D5:EB:EB:70:77:68:3C: 4C:E4:4E:8E:B8:02:20:1F:5B:0B:60:DC:48:B2:BD:E0: 59:ED:D1:1C:A9:35:1D:29:91:2C:B5:05:67:BC:49:B9: B2:9C:F6:1E:D6:BC:D1 ) ) 1[root@vps02 ~]# Many roads lead to Rome But this doesn't change the fact that hundreds to thousands of queries may be made in the background for a query that make it superfluous with services like Let's encrypt. Fact is we have this feature only to push the whmcs market . But I guess your main product is WHMCS as Software and not this 10ct profit from selling an ssl certificate. Greetings Christian Ā 0 Quote Link to comment Share on other sites More sharing options...
plusplushosting Posted May 24, 2019 Share Posted May 24, 2019 On 3/13/2019 at 9:17 AM, Vox said: I will explain what a HUGE car-crash this is at the moment... I have a client who has transferred their domain registration to me. However, his site is currently hosted elsewhere but also subsequently redirected to another site. In his client area it is showing a Green Padlock for the domain. His final destination site does not support https and there is no SSL installed (which he wants). It would seem from doing an SSL check that you are picking up the server SSL of where the redirect is in place. He is asking me now why he is getting a Green padlock but cannot access his site via https Now I'm getting drawn in to a whole load of support issues that are not my making, I do not have the time or effort to waste on this! Are WHMCS now going to provide support direct to this client for me because I do not have the time or the inclination. WHAT AN ABSOLUTE FARCE. AMEN to this! Lets add some pepper to the discussion...why we are using CURL to detect this? Based in the quoted explanation from, Vox above is completely useless.....why WHMCS which already has access to the server and know where the domain is hosted (in the case of the padlocks in the Services section) is not checking if the SSL is installed for that domain in the server exist and is valid or not? (through cpanel API). The detailed situation by Vox above make sense, clients are being confused....even more clients who have domains half hosted (i mean when clients have managed the DNS to point A records somewhere else, MX locally or the inverse) keep alone those padlocks showing green when the cert is not valid for the domain (curl Error 51) which is returning with a green padlock. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.