curl still at curl 7.19.7 ?

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

January 13, 2020 14:37

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

January 14, 2020 20:13

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.

January 25, 2020 22:18

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.

curl still at curl 7.19.7 ?

Comments

Didn't find what you were looking for?