Jump to content
wp4all

SSL Check under /clientarea.php?action=services

Recommended Posts

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 by jas8522

Share this post


Link to post
Share on other sites

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 by jas8522

Share this post


Link to post
Share on other sites

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
#
#
#

image.thumb.png.4cca6c22c122ce1bd6db0458c0b4a15a.png

 

Greetings Christian

Edited by wp4all

Share this post


Link to post
Share on other sites
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
#
#
#

image.thumb.png.4cca6c22c122ce1bd6db0458c0b4a15a.png

 

Greetings Christian

What, you mean the community thread where the guy from Plesk says "don't do this"?

  • Like 1
  • Sad 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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....

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

image.thumb.png.bafea4e8df525ec052ec87b47d0f2ae7.png

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

 

 

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 18/02/2019 at 6:02 PM, WHMCS John 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.

 

Share this post


Link to post
Share on other sites

Hi @WHMCS John,

On 2/18/2019 at 11:02 PM, WHMCS John 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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

 

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

 

 

Share this post


Link to post
Share on other sites

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>#

 

Share this post


Link to post
Share on other sites

@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.

  • Thanks 3

Share this post


Link to post
Share on other sites

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                                                                                                         
                                                                                                                        

 

 

Share this post


Link to post
Share on other sites
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 by bear

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

 

Share this post


Link to post
Share on other sites

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.

 

 

  • Disappointing 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by ju5t

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use & Guidelines