curl still at curl 7.19.7 ?

[Metro2]

While checking on another (possibly related) issue overnight, I happened to notice that curl -V shows 7.19.7 , which seems far behind. I'm running CloudLinux 6.1.0 , WHM/cPanel 84.0.19 , Apache 2.4.41 , MySQL 5.7 , EA4 , PDNS

[~]# curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.44 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

[~]# rpm -qa|grep php-curl
ea-php70-php-curl-7.0.33-10.el6.cloudlinux.3.x86_64
ea-php73-php-curl-7.3.11-1.el6.cloudlinux.x86_64
ea-php72-php-curl-7.2.24-1.el6.cloudlinux.x86_64
ea-php71-php-curl-7.1.33-1.el6.cloudlinux.x86_64
ea-php56-php-curl-5.6.40-9.el6.cloudlinux.3.x86_64

As a aside, what lead m to even start looking around at things like curl is the fact that a domaintools lookup of any site I host the report has a line in the results that says "Website Title 500 SSL negotiation failed" even though SSL/AutoSSL is working and my servers are HTTP2 enabled with mod_http2 in EA4. The following is an example of what returns from curl -s -I SSH command on a random site/domain I host...

[~]# curl -s -I https://(examplesite).com
HTTP/1.1 200 OK
Date: Mon, 13 Jan 2020 15:08:05 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade
Last-Modified: Sun, 14 Jul 2019 19:58:19 GMT
Accept-Ranges: bytes
Content-Length: 16361
Strict-Transport-Security: max-age=31536000
Content-Type: text/html

Anyway, grasping at straws trying to figure out why the domaintools.com website report for any site I host shows "Website Title 500 SSL negotiation failed" in one of the many lines of the report, and yet a SSL Server Test (Powered by Qualys SSL Labs) shows an A+

Things seem to be functioning fine and lot of my customers are conducting e-commerce sites with no problems, AutoSSL loads them https:// just fine, but dive down this rabbit-hole all started when a customer recently raised concerns of the domaintools report thinking that "Website Title 500 SSL negotiation failed" might be why he's not getting much traffic, and while I don't believe that's got anything to do with his traffic I'm just trying to sort out why that notice appears in domaintools reports (although I have a feeling it's because my nameservers end in .net and most sites I host are .com , and I know I'm rambling from sleep deprivation, ultimately I'm now curious about the curl version showing as ancient 7.19.7 despite me running yum update regularly.

Sound normal? Anyone been down this road? I've done a ton of searching / reading on this all night and can't seem to find anyone with the same concerns (except for some threads about CloudFlare out on the web, and I don't use CloudFlare).

Hoping this thread rings a bell with someone / turns up something.

Thanks for any replies.

 

[Metro2]

OK def too tired... instead of running command "curl -V" I just tried:

[~]# /opt/curlssl/bin/curl --version
curl 7.38.0 (x86_64-unknown-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1e zlib/1.2.3 libidn/1.18
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz

So... I guess technically I'm running 7.38.0 but still... that's like 5 years old or so...

 

[cPanelLauren]

Hello,

We use the version of curl that is offered with the CentOS base repository - anything higher than that would have to originate from a 3rd party repository and that wouldn't be something that we'd be able to provide support for.

 

[Metro2]

Thank you @cPanelLauren for your response and confirmation on that.

If anyone who reads this happens to have installed newer version of curl from 3rd party repository could share their experience that would be fantastic.

I'm wondering if it is safe to do / recommended / not recommended / potential repercussions.